[quot kealon(Ruslan)#22095712]

Ну это одно и тоже с точки зрения вычислений. Так же? Необходим заранее вычисленный агрегат чтобы делать вычисления для каждого значения «х». Можно ещё более наглядно сделать: sum(( x-avg(x))*(x-avg(x))) . Это variance. avg(x) это проход 1 остальное проход 2.

Ещё всякие vwap и тд

Спасибо!

Это зависит от системы. Если задача системы это не терять метрики, то нужно конечно использовать надежный протокол. Можно TCP - это просто, надежно но медленно. Можно сохранять метрики у источника и использовать UDP с NACK. При сбалансированных pub-sub может ретрансмиссий либо не быть либо очень мало. И таким образом нагрузка на сеть и cpu будет меньше.

В системах у которых метрики не основной вид деятельности UDP и потери вполне приемлемы. Например вы хотите отменить теряющий деньги заказ а торговая система ожидает подтверждения получения метрики от системы которая строит графики на которые никто не смотрит. В таком случае наверно лучше перестать терять деньги чем пропустить пиксель на графике.

Слышал и поверхностно изучал. О применениях не слышал, КДБ засела во всех банках и версию 4 недавно сделала, вариантов мало. Если честно то я смысла в шакти особого не вижу. Все проблемы с распространением КДБ перенесли вербатим в шакти. Впечатление такое что Артуру Уитли от скуки делать нечего — в first derivative засела бюрократия от которой он хочет освободить от неё свой любимый язык.

Они говорят что SIMD использует, но КДБ тоже как и другие проекты и наш в том числе. Ничего нового. Закрытый код тоже, красота, даже туториал закрыли.

https://news.ycombinator.com/item?id=19418570

sannysannof подсуммировал

Сегодня мы выпустили ещё одно обновление:

QuestDB 4.2.0 — текст на английском https://github.com/questdb/questdb/releases/tag/4.2.0

Это первая версия в которой появилась возможность выполнять запросы с помощью SIMD и параллельных вычислений. Мы начали с простецких запросов, таких как агрегация без ключей

.

Данные разбиваются на сегменты, которые обрабатываются SIMD инструкциям одновременно. Так же несколько функций выполняются параллельно, в таких запросах как

.

Производительность таких вычислений достаточно высокая. Например миллиард double значений агрегируется за 290мс на прочессорах с двумя каналами памяти и 100мс с шестью каналами. Один канал памяти полностью утилизируется двумя тредами.

По сравнению с нашим самым быстрым конкурентом — KDB, QuestDB в два раза быстрее на вышеописанной агрегации. Агрегация сравнима по скорости с параллельным суммированием простого массива в языках Julia и rust.

QuestDB доступна бесплатно и по Apache 2.0 лицензии, так что скачивайте пробуйте и комментируйте.

kealon(Ruslan),

Объясните пожалуйста?

Я спросонья пытаюсь понять что вы имели ввиду 😀 Производительность точно такая же на 64 бит целых числах.

Складывать double значения действительно не точно. могут быть отличия в районе 9 знака после запятой если сравнить параллельную агрегацию с суммированием по одному. Что же делать? Это такой IEEE формат

Различия конечно есть, но существенно меньше чем 20%. Вот например сумма 1.6 миллиардов на моем ноуте (2 канала):

Параллельно:



Последовательно:



Разница 242 с копейками, те 0.000001%

Я согласен, можно посчитать и сохранить. Но смысл не в этом. Мы делаем большой объём данных интерактивными. Конечно постепенно. Польза от суммирования всей таблицу не велика, но это демонстрирует потенциальные возможности которыми могут обладать будущие субд. Это поможет сократить необходимость в индексах, материальных въю и других костылей, которые нужно постоянно поддерживать. Дальше векторные и параллельные поиски, сравнения, копирование, индексы и тд. И вообще все что захочешь.

Да, пожалуйста. Свои аргументы нужно подкреплять фактами.

Почему же так кисло? Вы меня совершенно не знаете.

Я поделился новостями давненько и в первую очередь с соотечественниками. Но видно не очень интересно...

Вот всему остальному миру интересно:

https://www.reddit.com/r/programming/comments/fwlk0k/questdb_using_simd_to_aggregate_billions_of/

Ну и в ХН на главной странице:

https://news.ycombinator.com/news

Хорошо, спасибо за информацию. Это все похоже сводится к https://en.m.wikipedia.org/wiki/Kahan_summation_algorithm мне вот не сложно за 0 поделится если я нужной информацией владею.