Я слышал, что пару раз люди говорили о сделке KDB с миллионами строк почти мгновенно. почему так быстро? заключается только в том, что все данные организованы в памяти?
Другое дело, что есть альтернативы для этого? любые крупные поставщики баз данных предоставляют в памяти базы данных?
Быстрый поиск Google вызвал ответ:
Многие операции более эффективны с помощью подхода, ориентированного на столбцы. В частности, операции, требующие доступа к последовательности значений из определенного столбца, намного быстрее. Если все значения в столбце имеют одинаковый размер (что верно, по дизайну, в kdb), все становится еще лучше. Этот тип шаблона доступа типичен для приложений, для которых используются q и kdb.
Чтобы сделать это конкретным, рассмотрим столбец из 64-битных чисел с плавающей запятой:
q).Q.w[] `used
108464j
q)t: ([] f: 1000000 ? 1.0)
q).Q.w[] `used
8497328j
q)
Как вы можете видеть, память, необходимая для хранения одного миллиона 8-байтовых значений, составляет чуть более 8 МБ. Это потому, что данные хранятся последовательно в массиве. Чтобы уточнить, создайте другую таблицу:
q)u: update g: 1000000 ? 5.0 from t
q).Q.w[] `used
16885952j
q)
Оба t и u разделяют столбец f. Если q упорядочил свои данные в строках, использование памяти увеличилось бы на 8 МБ. Другой способ подтвердить это - взглянуть на k.h.
Теперь посмотрим, что произойдет, когда мы напишем таблицу на диск:
q)`:t/ set t
`:t/
q)\ls -l t
"total 15632"
"-rw-r--r-- 1 kdbfaq staff 8000016 May 29 19:57 f"
q)
16 байт служебных данных. Очевидно, что все числа сохраняются последовательно на диске. Эффективность заключается в том, чтобы избежать ненужной работы, и здесь мы видим, что q делает именно то, что нужно делать при чтении и записи столбца - не более, не менее.
ОК, поэтому этот подход является пространственно эффективным. Как эта компоновка данных преобразуется в скорость?
Если мы попросим q суммировать все 1 миллион номеров, имея весь список, упакованный плотно в памяти, является огромным преимуществом перед строковой организацией, потому что мы будем сталкиваться с меньшим количеством промахов на каждом этапе иерархии памяти. Избежание промахов в кеше и сбоев страниц имеет важное значение для обеспечения производительности вашей машины.
Кроме того, выполнение математики в длинном списке чисел, все вместе в памяти, является проблемой, с которой современные наборы инструкций процессора имеют специальные функции для обработки, включая инструкции по предварительной выборке элементов массива, которые понадобятся в ближайшем будущем. Хотя эти функции были первоначально созданы для улучшения производительности ПК, они оказались отличными и для статистики. Кроме того, такая же синергия локальности и функций ЦП позволяет системам, ориентированным на столбцы, выполнять линейные поиски (например, в тех случаях, когда кластеры на неиндексированных столбцах) быстрее, чем индексированные поисковые запросы (с их сопутствующими ошибками предсказания ветвлений) до удивительного количества строк.
Источники (S): http://www.kdbfaq.com/kdb-faq/tag/why-kdb-fast
как и для скорости, память играет важную роль, но есть несколько других вещей, быстрое чтение с диска для hdb, splaying и т.д. Из личного опыта я могу сказать, что вы можете получить довольно хорошие скорости от С++, если хотите написать много кода. С kdb вы получаете все это и еще несколько.
Еще одна вещь о скорости - это также скорость кодирования. Крутая кривая обучения, но как только вы ее получите, сложные проблемы могут быть закодированы за считанные минуты. альтернативы, которые вы можете посмотреть в onetick или google в базах памяти
KDB быстро, но очень дорого. Плюс, учиться очень трудно. Есть несколько альтернатив, таких как DolphinDB, Quasardb и т.д.