Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8 9 10      [все]
 QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Доброе время суток!

Я пишу СУБД для очень быстрой обработки данных, как реляционных так и time series. Система доступна через SQL и так же напрямую из java. SQL работает одновременно по PostgreSQL протоколу, HTTP и также через Influx line protocol.

Остальное описание и документация находится на GitHub (на английском)

https://github.com/questdb/questdb

Хотелось бы услышать ваше мнение и так же помочь нам поддержать вас в решении разнообразных проблем.


Спасибо!
28 ноя 19, 18:16    [22028057]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
какие преимущества перед InfluxDB и другими распространенными TS DB?
28 ноя 19, 19:20    [22028127]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
На много быстрее чем influx и timescale.
по сравнению с influx человеческий SQL, нормально ошибки репортятся, транзакционность данных, отказоустойчивость, поддержка реляционной модели, те неограниченные joins. Можно залить по influx протоколу а вытащить по postgres

По сравнению с timescale, просто быстрее, нагружает сервер меньше, например запрос в questdb выполняется быстрее на одном потоке чем timescale на шести

PostgreSQL инфраструктура конечно хорошая, но мы быстрыми темпами догоняем. Можем фич добавить быстро и без бюрократии

Залив данных из файлов упрощён - questdb заливает гораздо быстрее и автоматом создаёт таблицу и определяет типы полей. Также размер транзакции не ограничен при этом транзакция остаётся атомичной


Мы скоро накрутим incremental запросы, по производительности уничтожим все базы. Раз в 10-100 быстрее будет в зависимости от запроса
28 ноя 19, 19:35    [22028139]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
bluestreak

PostgreSQL инфраструктура конечно хорошая, но мы быстрыми темпами догоняем. Можем фич добавить быстро и без бюрократии

как вы её быстрыми темпами обгоните, если у вас один контрибьютор, судя по github

bluestreak

Мы скоро накрутим incremental запросы, по производительности уничтожим все базы. Раз в 10-100 быстрее будет в зависимости от запроса

Что такое incremental запросы?
28 ноя 19, 19:42    [22028142]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Инвестиции почти готовы, получаем деньги в январе и погнали. Я и есть этот контрибутор :)

Инкрементальные запросы вытекают из предположения что данные на изменяются. За исходный результат берётся не 0 а результат предидущего запроса.

Например ‘select location, avg(temp) where timestamp = ‘2019-12’

Считает среднюю температуру в каждом месте за декабрь. Первый раз обходит весь декабрь. Запускаем еще раз. Запрос берет готовый hashmap из предидущего запуска и дорабатывает дельтой данных между сейчас и предидущим временем
28 ноя 19, 19:59    [22028151]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
Сейчас кэширование в том или ином виде есть в любой DB. Некоторые DB, в том числе timeseries, полностью хранят в inmemory последние периоды time series, которыми в основном и пользуютя пользователи. Поэтому там в 10-100 раз особо некуда уже обгонять.
28 ноя 19, 20:59    [22028178]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Ну это наверное в теории. Если вы запустите запрос в influx чтобы просуммировать одно поле по ключу значений другого, то 10м записей он обработает за 100мс, запустите его ещё раз то будет опять 100мс и вы так же увидите подпрыгивание всех ядер процессора. Запрос который возвращает закешированные 20 записей возвращает данные за 3мс а не 100.

По этому если они кэшируют то далеко не столько как говорят.
28 ноя 19, 21:09    [22028186]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Запрос который возвращает закешированные 20 записей возвращает данные за 3мс а не 100.

Осталось только найти странное приложение, которое раз за разом одним и тем же запросом
запрашивает одни и те же данные. Это разве что к пых-пыховцам и прочим уэб-кодерам.

Posted via ActualForum NNTP Server 1.5

28 ноя 19, 22:28    [22028229]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Таких приложений может быть не очевидное количество но их полно. В моём примере может быть текущий месяц, который не меняется от понедельника до пятницы. В зависимости от скорости поступления данных результат запроса меняется. Это применимо к отчетности, в реальном времени, консолям всяким которые не обязательно запрашивают данные в инкрементах и собирают картину на клиенте.

Пых-пыховцам тоже инструменты нужны.
28 ноя 19, 23:04    [22028257]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
кстати, я так же могу ответить на конструктивные вопросы. Не зря же 5 лет эту СУБД пишу.

Например, как сделать .....? Я думаю что существующие СУБД не идеальны :)

Сообщение было отредактировано: 28 ноя 19, 23:13
28 ноя 19, 23:07    [22028258]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
я так же могу ответить на конструктивные вопросы. Не зря же 5 лет эту СУБД пишу.

Хочешь потягаться с теми, кто делает это 20?..

Posted via ActualForum NNTP Server 1.5

28 ноя 19, 23:17    [22028268]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3810
bluestreak,

название хорошее, что означает?
работа с с данной СУБД - это перманентный Quest?
28 ноя 19, 23:37    [22028276]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
я так же могу ответить на конструктивные вопросы. Не зря же 5 лет эту СУБД пишу.

Хочешь потягаться с теми, кто делает это 20?..


Дело не в том чтобы тягаться (я пишу софт с 1994г). QuestDB это apache 2.0 проект. Есть возможность сделать вещи, которые в существующих СУБД делаются через задницу, прямо в СУБД и по человечески, как всем было бы удобно, быстро, и не дорого в смысле вычислительных ресурсов в облаках.
29 ноя 19, 00:15    [22028288]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Дмитрий Мух
bluestreak,

название хорошее, что означает?
работа с с данной СУБД - это перманентный Quest?


Спасибо!

Quest это упорная разработка чтобы результат был удобный и быстрый. Например парка сервером, чтобы можно было 100Гб файл перетащить в браузер и он загрузился без проблем.

Ну и другие подобные вещи
29 ноя 19, 00:19    [22028290]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 2337
bluestreak,

Я пишу СУБД для очень быстрой обработки данных

java


Делаю столярный цех. Все работы будут выполняться топором и бензопилой.
29 ноя 19, 05:35    [22028320]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
crutchmaster
bluestreak,

Я пишу СУБД для очень быстрой обработки данных

java


Делаю столярный цех. Все работы будут выполняться топором и бензопилой.


Молоток

Изучил предмет дасканално
И ответил очень аригинално

Постгрес С, залив 500мб цсв - 47с
Questdb java, залив того же файла 4с GC = 0

Скачайте, попробуйте
29 ноя 19, 06:18    [22028325]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 2337
bluestreak,

Давай остальные метрики, время выборок, скорость join'ов и прочее. На базе в пару TB и работающих 100 подключениях.
29 ноя 19, 06:37    [22028327]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108

COPY Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8
TimescaleDB 44.776 0.275 0.187 0.55 0.733 0.285 0.195 0.448 0.079 all queries except ingestion are executed in parallel on 6 cores. Date format is rigid
QuestDB 4.2 0.005 0.182 0.22 0.41 0.27 0.22 0.327 0.07



Q1 select count(qty) from trades
Q2 select sum(qty) from trades
Q3 select instrument, sum(qty) from trades group by instrument
Q4 select instrument, side, sum(qty) from trades group by instrument, side
Q5 select sum(price), sum(qty) from trades where side='B' (makes no sense to sum(price) but we wanted to show how aggregate expressions scale)
Q6 select sum(price), sum(qty) from trades where side='B' and instrument='AC' (makes no sense to sum(price) but we wanted to show how aggregate expressions scale)
Q7 select instrument, sum(price), sum(qty), from trades where side='S' group by instrument
Q8 select sum(price), sum(qty) from trades in range (2019-10-17, 2019-10-29) where side='S' group by 1h


Здесь timescale/postgres выполняют каждый запрос в 6 потоков. Questdb в один поток.

Сообщение было отредактировано: 29 ноя 19, 07:01
29 ноя 19, 06:55    [22028331]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Залей свой датасет попробуй

Joins работают быстро, количество не ограничено. Размер базы ограничен системными ресурсами, диском и физической памятью. Для работы с данными используются memory mapped files.

Количество подключений не ограниченно, сервера не блокирующие с поддержкой flow control.
29 ноя 19, 06:59    [22028332]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 2337
bluestreak,

Ну что это за бенч? Где тестовые данные? Где версии софта? Где железо? Где IO? Что там по надёжности? Она у тебя inmemory? Как это всё сбрасывается на диск?
29 ноя 19, 07:07    [22028336]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Бенч синтетический датасет, 500мб 10м записей

Данные - ...

Версии недельной давности

Dell 9570 laptop i9 6 core , 32gb. 1tb nvme ssd

Надежность данных - транзакционность (acid) по одной таблице пока. Автоматическое восстановление при потере электропитания


Данные как я сказал пишутся и читаются через memory mapped files. ОС занимается управлением памятью. В прямую память попадают только промежуточные данные при выполнении запросов. При этом делается все возможное чтобы данные не копировать в память. Например результат ‘from a join b on(x)’ хранится в памяти как хэш ключа x и rowid (64bit) таблицы b


Данные на диск записываются ОС асинхронно. Будет возможность делать msync с коммитом в зависимости от задачи
29 ноя 19, 07:25    [22028341]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3810
bluestreak
Дмитрий Мух
bluestreak,

название хорошее, что означает?
работа с с данной СУБД - это перманентный Quest?


Спасибо!

Quest это упорная разработка чтобы результат был удобный и быстрый. Например парка сервером, чтобы можно было 100Гб файл перетащить в браузер и он загрузился без проблем.

Ну и другие подобные вещи

Ну нам такого не надо, у нас другие задачи.

А 100Гб файл - это что? Киношка какая что-ли? Так с этим вроде сейчас через браузер проблем нет.
29 ноя 19, 09:42    [22028426]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3810
bluestreak
Для работы с данными используются memory mapped files.

А с MongoDB MMAPv1 сравнивали? А с WiredTiger?
29 ноя 19, 09:46    [22028430]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 2337
bluestreak,

Как-то без огонька. Надо устроить спецолимпиаду, написать генератор входных данных, придумать задачи, наделать скриптов, чтобы кому надо могли у себя это запустить и потыкать.
29 ноя 19, 09:49    [22028435]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 828
Очередной полоумный гаражный убиватель сиквела и оракла.
Пойду за попкорном сгоняю...
29 ноя 19, 09:54    [22028440]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 2337
PsyMisha,

Утверждает, что ему даже денег на это дадут.
29 ноя 19, 09:56    [22028441]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 828
bluestreak,

А кстати - как у вас с:
- Версионность. Одновременно работающие читатели и писатели, конфликты, блокировки
- Отказоустойчивость. Кластерные ноды, агенты чтения журнала транзакций, репликация на зеркала-подписчики

Вы либо это успешно слелели, причем на такой гениальном уровне, что действительно поборет существующих вендоров, работавших над продуктами десятилетиями, ввалившими бесчисленное множество миллиардов человеко-часов и денег в совершенствование продукта, либо живете в
DATEADD(YEAR, -20, GETUTCDATE())
лет назад, когда еще не было кучи обязательных ныне фич.
29 ноя 19, 10:00    [22028446]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Ладно мужики, похоже кроме того что попкорн жевать вам ничего не надо. До свиданья.
29 ноя 19, 10:48    [22028505]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 2337
bluestreak,

Вы просто не понимаете основных принципов пиара. Да, тут будет срач и будут жрать попкорн, но главное, чтобы о вас говорили, причём не важно что, лишь бы побольше. А там глядишь бы и допилили свою субд до более-менее вменяемого состояния.

Сообщение было отредактировано: 29 ноя 19, 10:53
29 ноя 19, 10:52    [22028516]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 828
crutchmaster,

Ага, все верно, - пришел же Дидми к успеху через свой чернющщий пиар все же - родился же ДуДокс, какую-то сферу в итоге покрывает
29 ноя 19, 11:00    [22028526]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 828
bluestreak,

Возможно, - у вас очень узкоспециализированный продукт, который сильно нишевый и для очень определенного круга задач.
Вы продолжайте, пожалуйста, - действительно интересно

Просто понимаете, - суть в том, что местная общественность навидалась уже за долгие годы ТАКОЕ кол-во изобретателей с шокирующим продуктом, который вот-вот порвёт рынок - что ...
отсюда и скепсис по-дефолту
29 ноя 19, 11:03    [22028534]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
уровень обсуждения на реддите и тут, на форуме ВЕЛИКИХ РУССКИХ ИНЖЕНЕРОВ СКЛЬ,
https://www.reddit.com/r/programming/comments/e2gfpi/questdb_fast_time_series_database_zerogc_java/
разительно отличается

тут больше на фишки и пикабу похоже
29 ноя 19, 12:20    [22028670]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 828
Бумбараш,

На том форуме человек задает конкретные технические вопросы про низкие уровни в Джаве.

Здесь же - начинается все с фраз "по производительности уничтожим все базы. Раз в 10-100 быстрее будет в зависимости от запроса " - что еще можно ответить на такое? Только пёрлами, зубоскальством и прочими фишками.

Да, закономерный ответ - но ведь и здесь люди могли бы начать расспрашивать про многопоточность. Но ведь и автор так же тему в серьёзное не повел.
29 ноя 19, 13:21    [22028775]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

PsyMisha
но ведь и здесь люди могли бы начать расспрашивать про многопоточность.

Могли. Но опыт FwMAS мешает.

Posted via ActualForum NNTP Server 1.5

29 ноя 19, 14:00    [22028841]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29805
bluestreak
Постгрес С, залив 500мб цсв - 47с
Questdb java, залив того же файла 4с GC = 0

ну офигеть. То есть, мы прикидываемся, что чего-то там залили (4с - это, собственно, 125мб/сек, т.е. тупое чтение файла в память, без парсинга), потом начинаем парсить это дело в фоне, сливать в memory mapped file, а дальше пусть ОС с этим всем разбирается.
Ну чё, нормуль.
29 ноя 19, 14:06    [22028856]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29805
Бумбараш
уровень обсуждения на реддите и тут, на форуме ... разительно отличается

ну, там люди, наверное, разговаривают как с умалишённым, боясь спровоцировать обострение.
А тут чего церемониться? Человек же врёт не краснея. 500мб csv он читает за 4.5 сек - это примерно 125мб/сек, то есть, за столько можно только прочитать 500мб с hdd в память. И уж никак не распарсить весь этот файл, сформировать в памяти структуры для транзакционного хранения и многопользовательско доступа, и т.д.
Ну допустим он читает это дело с ssd. Ок, на чтение 500мб файла в память - пусть 1 сек. И 3.5 сек на всё остальное? Нобелевскую, срочно!
29 ноя 19, 14:12    [22028867]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
bluestreak,

куда бы вы поместили свою базу в этом бенчмарке?

https://tech.marksblogg.com/benchmarks.html
29 ноя 19, 16:10    [22029042]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Troglodit
Member

Откуда:
Сообщений: 505
Бенчмарки-это дело не благодарное.
PostgreSQL без упоминания железа, ОС, а главное конфига, разговор про сферического коня в вакууме.
Очень странно, что человек, который в одиночку написал убийцу современных СУБД не понимает этого.
Вы реально молодец, что в одиночку замахнулись на такое большое дело и даже если не будет результата, как
говорится огромный опыт идет бонусом.
30 ноя 19, 18:34    [22029503]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak

COPY Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8
TimescaleDB 44.776 0.275 0.187 0.55 0.733 0.285 0.195 0.448 0.079 all queries except ingestion are executed in parallel on 6 cores. Date format is rigid
QuestDB 4.2 0.005 0.182 0.22 0.41 0.27 0.22 0.327 0.07



Q1 select count(qty) from trades
Q2 select sum(qty) from trades
Q3 select instrument, sum(qty) from trades group by instrument
Q4 select instrument, side, sum(qty) from trades group by instrument, side
Q5 select sum(price), sum(qty) from trades where side='B' (makes no sense to sum(price) but we wanted to show how aggregate expressions scale)
Q6 select sum(price), sum(qty) from trades where side='B' and instrument='AC' (makes no sense to sum(price) but we wanted to show how aggregate expressions scale)
Q7 select instrument, sum(price), sum(qty), from trades where side='S' group by instrument
Q8 select sum(price), sum(qty) from trades in range (2019-10-17, 2019-10-29) where side='S' group by 1h


Интересуют более детально условия тестирования. Вы пишете что ваша Dbms тестировалась в 1 поток.
При таком подходе на БОЛЬШЕМ объеме конкуренты которые работают в несколько потоков или процессов
имеют преимущество в использовании многоканальной памяти при условии что данные лежат соотв. Образом.
Тоесть если вы сойдете с милисекунд на секунды и БОЛЬШИЕ выборки то ваша DBMS начнет отставать.

Здесь timescale/postgres выполняют каждый запрос в 6 потоков. Questdb в один поток.
30 ноя 19, 20:04    [22029540]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
PsyMisha,

Ну спасибо на добром слове. Может быть я не подробно рассказал о контексте «в 10—100 раз быстрее» но это не значит что цифры можно интерпретировать как угодно.

Повышение производительности в 10 или 100 раз вытекает из потенциально более эффективной интерпретации данных. Например в таблице имеются записи от 0 до 100 миллионов. Когда субд агрегирует данные по ключу Х и фильтру «Ф» часть данных по сути копируется в хэш таблицу. На это может уйти пару секунд. Допустим теперь в таблицу добавилось 1000 записей которые удовлетворяют фильтр «Ф». Практически все без исключения субд будут перечитывать 100м + 1000 записей. В QuestDB данные, за исключением удаления партиций, immutable. По этому QuestDB обработает только 1000 записей и добавит к предыдущему результату. То есть мы сравниваем пару секунд с одноциферными миллисекундами.
3 дек 19, 21:05    [22031594]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
kdv
Бумбараш
уровень обсуждения на реддите и тут, на форуме ... разительно отличается

ну, там люди, наверное, разговаривают как с умалишённым, боясь спровоцировать обострение.
А тут чего церемониться? Человек же врёт не краснея. 500мб csv он читает за 4.5 сек - это примерно 125мб/сек, то есть, за столько можно только прочитать 500мб с hdd в память. И уж никак не распарсить весь этот файл, сформировать в памяти структуры для транзакционного хранения и многопользовательско доступа, и т.д.
Ну допустим он читает это дело с ssd. Ок, на чтение 500мб файла в память - пусть 1 сек. И 3.5 сек на всё остальное? Нобелевскую, срочно!



Это полный бред. 4.1с это залив данных в реальном времени. Questdb сохраняет файл прямо в базу и при этом автоматически определяет количество полей, их типы, разделитель и отличат двоичный файл от текстового. Философия и высшая математика не уместна, скачай и сам проверь. Все открыто

Кстати KDB за тоже время зальёт файл — они наверно Нобелевскую обмыли уже
3 дек 19, 21:34    [22031605]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Troglodit
Бенчмарки-это дело не благодарное.
PostgreSQL без упоминания железа, ОС, а главное конфига, разговор про сферического коня в вакууме.
Очень странно, что человек, который в одиночку написал убийцу современных СУБД не понимает этого.
Вы реально молодец, что в одиночку замахнулись на такое большое дело и даже если не будет результата, как
говорится огромный опыт идет бонусом.


Описание железа на странице 1
3 дек 19, 21:36    [22031606]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Бумбараш
bluestreak,

куда бы вы поместили свою базу в этом бенчмарке?

https://tech.marksblogg.com/benchmarks.html


Мы на этих данных пока не тестировались. Скоро я думаю. По производительности мы похожи на KDB.
3 дек 19, 21:38    [22031607]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

Вы правы, многопоточная обработка данных гораздо предпочтительная если взять во внимание железо. Однопоточная обработка в QuestDB это оговорка для ясности, но она похоже запутала. Позвольте объяснить:

QuestDB сетевые сервисы являются многопоточными. Потоков фиксированое количество. Они работают с сокетами через epoll и позволяют работать в моногопользовательском режиме. Однако когда пользователь запускает запрос, этот запрос будет использовать одно ядро. Мы тестировали в такой среде по http

Данные сгенерили таким запросом



select timestamp_sequence(to_timestamp('2019.10.17T00:00:00.000000', 'yyyy.MM.ddTHH:mm:ss.SSSUUU'), 100000L) ts,
rnd_str(2,2,0) instrument,
abs(to_int(rnd_double(0)*100000)) price,
abs(to_int(rnd_double(0)*10000)) qty,
rnd_str('B', 'S') side
from long_sequence(10000000) x;


И потом скачали с сервера через web console, там есть кнопка «скачать»

Для influx исходные данные создавались таким запросом:



select
concat(
'trades,instrument=', rnd_str(2,2,0),
',side=', rnd_str('B', 'S'),
' price=', abs(to_int(rnd_double(0)*100000)),
',quantity=', abs(to_int(rnd_double(0)*10000)),
' ',
1571270400000 + (x-1) * 100
)
from long_sequence(10000000) x;


Параметр к long-sequence это количество записей, можно большое количество если нужно. Серверу предел это диск. Если номер записей сильно большой, добавьте L, т.е 10000000000000000L
3 дек 19, 21:52    [22031612]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Они работают с сокетами через epoll и позволяют работать в моногопользовательском режиме.

"Это ты круто задвинул!" (с)
"А унутре у нея неонка." (с)

Posted via ActualForum NNTP Server 1.5

3 дек 19, 22:34    [22031625]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
bluestreak,

Я так понимаю вы её в апач только сейчас выпустили.

Как думаете монетизироватЬ? Консалтингом вокруг апачевской базы?

Сообщение было отредактировано: 4 дек 19, 00:28
4 дек 19, 00:28    [22031675]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak, а вы с Apache-Orc не работали?
4 дек 19, 00:33    [22031680]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
bluestreak,

есть ли у базы какие-нибудь энтерпрайз или большие пользователи? Кто они?
Если их нет, как вы планируете продвигать базу?
Просто не знаю, как продвигается opensource продукт.

есть ли у неё какая-нибудь специализация, например, на трейдинге, как у kdb, или она general purpose?
4 дек 19, 00:43    [22031684]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Бумбараш,

Через open core бизнес модель. Мы пишем отдельный продукт, который использует QuestDB и предоставляет отказоустойчивость, масштабирование, интеграционные примочки, автоконфигурацию итд От консалтинга пытаемся держаться подальше, я хотел бы упростить эксплуатацию субд а не усложнять ради денег
4 дек 19, 00:49    [22031685]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton
bluestreak, а вы с Apache-Orc не работали?


Нет, к сожалению.
4 дек 19, 00:51    [22031686]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Бумбараш
bluestreak,

есть ли у базы какие-нибудь энтерпрайз или большие пользователи? Кто они?
Если их нет, как вы планируете продвигать базу?
Просто не знаю, как продвигается opensource продукт.

есть ли у неё какая-нибудь специализация, например, на трейдинге, как у kdb, или она general purpose?


У нас есть несколько пользователей из финансовой и криптовалютной торговли. В основном QuestDB используется как low latency хранилище в трейдинг системах где размещение заказа должно происходить за меньше чем 15 микросекунд.

Мы подвигаем через общение с разработчиками, помогаем им решать задачи в замен на внедрение QuestDB.
4 дек 19, 01:09    [22031691]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
В основном QuestDB используется как low latency хранилище в трейдинг системах где
размещение заказа должно происходить за меньше чем 15 микросекунд.

Забавный научный факт: за 15 микросекунд свет успевает пролететь чуть больше четырёх
километров.

Posted via ActualForum NNTP Server 1.5

4 дек 19, 01:16    [22031694]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
bluestreak
Бумбараш
bluestreak,

есть ли у базы какие-нибудь энтерпрайз или большие пользователи? Кто они?
Если их нет, как вы планируете продвигать базу?
Просто не знаю, как продвигается opensource продукт.

есть ли у неё какая-нибудь специализация, например, на трейдинге, как у kdb, или она general purpose?


У нас есть несколько пользователей из финансовой и криптовалютной торговли. В основном QuestDB используется как low latency хранилище в трейдинг системах где размещение заказа должно происходить за меньше чем 15 микросекунд.


она как транзакционная база используется в этом сценарии выставления ордеров? То есть какие-то апдейты происходят в самой базе?
Просто вроде обычно такие базы, Kdb, etc, используются для аналитики. Или она поставляет аналитику какому-то потребителю, который и выставляет ордер на основе сигнала questdb.
4 дек 19, 17:14    [22032344]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Dimitry Sibiryakov

bluestreak
В основном QuestDB используется как low latency хранилище в трейдинг системах где
размещение заказа должно происходить за меньше чем 15 микросекунд.

Забавный научный факт: за 15 микросекунд свет успевает пролететь чуть больше четырёх
километров.

Несколько лет назад один господин кодил DBMS с наносекундным откликом.

Чото мне заранее поплохело.... Дайте валерьянки.
4 дек 19, 17:31    [22032371]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Бумбараш,

QuestDB используется в имплементации движка OUCH, похожего на FIX, только производительнее. В неё сохраняются все входные и исходящие сообщения. Когда нарушается связь между клиентом и торговой системы из QuestDB достаются ответы (execution reports) по номерам последовательностей. QuestDB встроенная в такой ситуации.

Дополнительно из QuestDB используются библиотеки доступа к сети, вместо Java NIO, логирования и обмена сообщениями между потоками.

В других приложениях QuestDB используется как основание lossless multicast шины сообщений, все те же библиотеки как для ouch движка и ещё библиотека, которая заворачивает epoll/kqueue/select и работает быстрее чем Java/netty и позволяет конфигурировать несимметричное количество пользователей и потоков.

Аналитика потом делается из данных которые консолидируются по сети через эту multicast шину.

KDB тоже используется как в торговых системах, в конфигурации ticker—plant как система сообщений и генерации алгоритмических заказов, так и для аналитики естественно.

Сообщение было отредактировано: 4 дек 19, 20:59
4 дек 19, 20:57    [22032538]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
QuestDB используется как основание lossless multicast шины сообщений, все те же библиотеки
как для ouch движка и ещё библиотека, которая заворачивает epoll/kqueue/select и работает
быстрее чем Java/netty и позволяет конфигурировать несимметричное количество пользователей
и потоков.

Так вот откуда в ней возникает синекдоха отвечания...

Posted via ActualForum NNTP Server 1.5

4 дек 19, 22:21    [22032584]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Нессимметричное число пользователей? Я впервые слышу такую комбинацию слов!
4 дек 19, 22:25    [22032590]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton
Нессимметричное число пользователей? Я впервые слышу такую комбинацию слов!


Один поток может одновременно общаться с несколькими сокетами. Парсеры протоколов написаны так что они работают с сокетами на уровне скорости процессора а не на уровне модема с другой стороны. Отсюда несеммитричность числа подключений и серверных потоков.

Постгрес форкает процесс для каждого accept() и все уважают и не гы—гыкают.

Сообщение было отредактировано: 4 дек 19, 23:14
4 дек 19, 23:13    [22032611]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Один поток может одновременно общаться с несколькими сокетами.

Собственно это и есть основная (а точнее единственная) задача epoll/select.

bluestreak
Парсеры протоколов написаны так что они работают с сокетами на уровне
скорости процессора а не на уровне модема с другой стороны.

Для 15 микросекунд вам подойдёт только локалхост, да и то со спидхаком, а в его случае
бутылочным горлышком как раз является процессор.

bluestreak
Отсюда несеммитричность числа подключений и серверных потоков.

То есть ваше мега-хау-ноу это пул потоков и паттерн producer-consumer в действии.

Н-е-о-н-к-а.

Posted via ActualForum NNTP Server 1.5

4 дек 19, 23:22    [22032617]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov,

Это не только epoll это еще все парсеры написаны как state—machine и оттестироаны с невменяемым количеством комбинаций когда парсер прерывается из-за инертного сокета и восстанавливается по сигналам epoll. Я здесь говорю о рабочем продукте а не заявке на патент или Нобелевскую премию.

Говорить а блин это же epoll это очень упрощённый взгляд на вещи.
4 дек 19, 23:33    [22032619]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
парсеры написаны как state—machine

А бывают в живой природе другие?

Posted via ActualForum NNTP Server 1.5

4 дек 19, 23:41    [22032622]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov,

15 микросекунд это не теоретический полёт света, это разбор протокола, валидация, проверка риска и ограничений, конвертация протоколов, два сохранения, четыре сетевых хопа и поиск в order book. Вот это все между двумя серверами и 300м интерконнектом. Не на локалхосте а на solarflare картах и mellanox layer 3 свич. Все это 10микро 99.99 percentile
4 дек 19, 23:41    [22032623]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov,

Бывают, большенство ленивые, чтобы им в рот все сразу мама положила
4 дек 19, 23:42    [22032624]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Господа.

Я придерживаюсь такой точки зрения.
Что "дорога ложка к обеду", и "у каждой вещи - свое предназначение".

Автор создаёт вещь которая ему нужна.
У него - юзкейс такой. И условия.

Кстати. Расскажите мне как вы коллеги понимаете термин - таймсерия.
5 дек 19, 09:12    [22032752]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 828
mayton

Расскажите мне как вы коллеги понимаете термин - таймсерия


Вот-вот, - поддерживаю.
Какой-то жутко оптимизированный сиквенс?
5 дек 19, 09:17    [22032760]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6360
bluestreak
Dimitry Sibiryakov,

Это не только epoll это еще все парсеры написаны как state—machine и оттестироаны с невменяемым количеством комбинаций когда парсер прерывается из-за инертного сокета и восстанавливается по сигналам epoll. Я здесь говорю о рабочем продукте а не заявке на патент или Нобелевскую премию.

Говорить а блин это же epoll это очень упрощённый взгляд на вещи.
что-то я не вижу генератора, вручную что ли?
5 дек 19, 09:36    [22032785]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
mayton


Кстати. Расскажите мне как вы коллеги понимаете термин - таймсерия.

Меня вполне устраивает классическое определение

https://en.m.wikipedia.org/wiki/Time_series
5 дек 19, 10:55    [22032868]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3810
Бумбараш
mayton


Кстати. Расскажите мне как вы коллеги понимаете термин - таймсерия.

Меня вполне устраивает классическое определение

https://en.m.wikipedia.org/wiki/Time_series

+1
5 дек 19, 11:12    [22032884]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Бумбараш
mayton


Кстати. Расскажите мне как вы коллеги понимаете термин - таймсерия.

Меня вполне устраивает классическое определение

https://en.m.wikipedia.org/wiki/Time_series

Меня не устраивает. Мы не сможем судить или оценивать систему которую создал автор до
тех пор пока не формализуем API который работает (и работает оптимально) с ней.

Протокол этого API будет определять структуру данных в которой должна лежать тайм-серия.
Не всегда это массив. Если вы хотите быстро искать точечные значения - то данные надо
хранить в деревьях. Диапазоны (короткие) - тоже в деревьях. Более длинные последовательности
- в блоках дерева. И очень длинные - в stripes наподобие apache orc.
Кстати дисковое хранение тут тоже важно. Если мы полностью полагаемся на memory-mapped
от операционки - то это значит что мы полностью доверяем ей механику кеширования
которая не всегда оптимальна по алгоритму (дервянный LRU) или по размеру блока
1k? 1M? или по приоритезации? Что вытеснять когда нехватка?
5 дек 19, 11:54    [22032977]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Ну и по обновлениям. Будут ли данные принимать updates? BigData в классическом понимании этого
термина предполагает что данные только исторические.
5 дек 19, 12:01    [22032993]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
kealon(Ruslan),

Да, все парсеры вручную :(
5 дек 19, 13:16    [22033100]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

Спасибо за конструктивные вопросы.

Я себе представляю таймсерию как журнал событий, в котором как было бы удобно человеку, данные хранятся в столбик. Как вы понимаете в таком способе представления есть преимущества и недостатки.

Из преимуществ:

— Данные очень легко добавлять — записываем всегда в конец, отсюда огромная скорость добавления и так же очень недорогая атомичность.
— данные всегда выбираются в той же последовательности в которой они добавлены, либо в строго противоположной если нужно.
— данные не мутируют, отсюда возможна реализация инкрементальных запросов о которых я уже говорил
— новые данные всегда в конце журнала
— время хранится в порядке возрастания, отсюда сложность хранения О(1) и временная сложность O(log n). Дерево по сравнению O(log n) хранение и поиск, плюс место на диске

Из недостатков:

— сложность удаления индивидуальных записей, в случае QuestDB — невозможность, данные удаляютя удаляются через партиции
— невозможность физического изменения записей; изменения виртуальные и реализуются через select

По поводу доступа, он действительно только через memory mapped file. Здесь предположение что ва сервере субд достаточно памяти. Со своей стороны QuestDB выполняет запись и чтение через отдельные страницы. При записи таблицы используется одна страница, которая двигается вниз по мере поступления данных. При чтении, страницы мапятся лениво, по мере необходимости. Также группы таких страниц помещаются во внутренний LRU кэш. QuestDB старается быть эффективной с памятью.
5 дек 19, 13:53    [22033146]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
По поводу доступа, он действительно только через memory mapped file.

То есть Durability отсутствует как класс. Isolation, похоже, тоже. Как и собственно
транзакции. То есть это FwMAS с поддержкой сети.

Posted via ActualForum NNTP Server 1.5

5 дек 19, 14:06    [22033167]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Dimitry Sibiryakov

bluestreak
По поводу доступа, он действительно только через memory mapped file.

То есть Durability отсутствует как класс. Isolation, похоже, тоже. Как и собственно
транзакции. То есть это FwMAS с поддержкой сети.

Это ближе к Hadoop. Один раз сохранил - и 3.14дец.
5 дек 19, 14:22    [22033191]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov,

Вы прямо мировой чемпион по прыжкам к умозаключениям?

Неленивый человек может найти «commit» в репо ра минуту. Durability будет конфигурируемый — msync() синхронный, асинхронный и отсутствующий. Данные полностью атомичны и все чтения полностью изолированы. Причём размер транзакции не ограничен.
5 дек 19, 14:32    [22033201]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

mayton
Это ближе к Hadoop.

Хадуп не знаю, не ел. Но кучку лет назад тут уже был топик о забавной СУБД в которой был
только лог. Исключительно последовательные запись и чтение. "Пони бегает по кругу."

Posted via ActualForum NNTP Server 1.5

5 дек 19, 14:37    [22033204]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

Как я сказал, данные можно удалять по партициям — например удалить устаревшие данные. Можно физически изменять через копирование.

А так же для систем которым нужно «изменение» данных это можно делать через добавление истории изменений. В QuestDB sql присутствует “latest by” фраза, которая позволяет сжать историю до одной записи в один запрос.

В моём опыте все более менее серьезные системы не позволяют изменять или удалять данные без истории изменений.
В этом случае QuestDB может быть решением чтобы иметь версии без запарок.
5 дек 19, 14:40    [22033207]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak
mayton,

Как я сказал, данные можно удалять по партициям — например удалить устаревшие данные. Можно физически изменять через копирование.

А так же для систем которым нужно «изменение» данных это можно делать через добавление истории изменений. В QuestDB sql присутствует “latest by” фраза, которая позволяет сжать историю до одной записи в один запрос.

В моём опыте все более менее серьезные системы не позволяют изменять или удалять данные без истории изменений.
В этом случае QuestDB может быть решением чтобы иметь версии без запарок.

В Хадуп можно добавлять. Но добавление относится к исстории. Например к данным о торговых индексах
за 2018 год добавился еще один файл - данные за 2019 год. Вот в таком вот аспекте. Но править 1 строчку - это
вряд-ли. Тем более что файлы много раз индексируются для текстовых и прочих разных умных поисков.

Если вам нужно данные изменять оперативно - то это другой класс систем. Ближе к OLTP. Или совсем-совсем OLTP.

Тоесть вам надо детальнее описать юзкейсы вашей системы. От этого мы сможем ее классифицировать.
Причем с ограничителями. Можно ли за 1 операцию залить триллион строк? Что будет при конкурентной
агрегации сразу по двум тайм-сериям которые в общем объеме превышают оперативку. Вы должны
все эти маргинальные случаи рассмотреть. Иначе окажется что ваша система в ответ на такую
операцию просто падает в kernel panic.
5 дек 19, 14:51    [22033220]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Dimitry Sibiryakov

mayton
Это ближе к Hadoop.

Хадуп не знаю, не ел. Но кучку лет назад тут уже был топик о забавной СУБД в которой был
только лог. Исключительно последовательные запись и чтение. "Пони бегает по кругу."

EventStore наверное.
5 дек 19, 15:02    [22033241]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
mayton,

time series database это уже и так строго классифицированный тип СУБД

https://en.wikipedia.org/wiki/Time_series_database

со своими областями применения и данными. Можно сказать, что это типа OLAP, в котором хранится только один, специальный тип данных - time series.

А вы пытаетесь начать сравнивать со всем, что бывает на свете.
5 дек 19, 15:04    [22033244]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
Бумбараш
mayton,
time series database
...
А вы пытаетесь начать сравнивать со всем, что бывает на свете.

вроде это сам автор своей СУБД стал сравнивать ее с PostgreSQL
5 дек 19, 15:07    [22033250]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Бумбараш
mayton,

time series database это уже и так строго классифицированный тип СУБД

https://en.wikipedia.org/wiki/Time_series_database

со своими областями применения и данными. Можно сказать, что это типа OLAP, в котором хранится только один, специальный тип данных - time series.

А вы пытаетесь начать сравнивать со всем, что бывает на свете.

Я пытаюсь понять ограничители. Потому-что это - риски.
5 дек 19, 15:10    [22033254]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
Leonid Kudryavtsev
Бумбараш
mayton,
time series database
...
А вы пытаетесь начать сравнивать со всем, что бывает на свете.

вроде это сам автор своей СУБД стал сравнивать ее с PostgreSQL

Он скорее сравнивал с TimescaleDB - это time series вариант Postgre.

Я о том, что было бы странно, если тема о какой-нибудь OLAP системе, например, и предъявлять ей, что она не выполняет какие-то узкие требования выполняемые супер-OLTP системой.

потому что и так понятно, что она их не будет и не собиралась выполнять

ну ладно, это я так. Автор, видимо, всё равно расположен обсуждать все варианты, так что давайте обсуждать

Сообщение было отредактировано: 5 дек 19, 15:21
5 дек 19, 15:19    [22033268]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Troglodit
Member

Откуда:
Сообщений: 505
mayton
Это ближе к Hadoop. Один раз сохранил - и 3.14дец.

Мне кажется или автор переизобрел велосипед с Kafk'ой?

Сообщение было отредактировано: 5 дек 19, 18:01
5 дек 19, 18:00    [22033444]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
При чем тут Kafka. Это мессенджинговая система. А топик про Dbms.
5 дек 19, 18:10    [22033454]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Troglodit
Member

Откуда:
Сообщений: 505
mayton
При чем тут Kafka. Это мессенджинговая система. А топик про Dbms.

Сейчас некоторые ее позиционируют как замену субд. как раз все что выше автор описал отлично ложиться под kafk'у.
Да и кафка это не только ценный мех лог, но еше и 3-4 KSQL :), да и ACID требования выполняются.
5 дек 19, 18:35    [22033477]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Пускай автор сам скажет.

Кстати у него должен быть бенчмарк который доказывает что его система эффективнее аналогов.

Иначе... зачем вообще что-то создавать?
5 дек 19, 19:05    [22033512]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

QuestDB это не хадуп — хадуп это даже анти—герой.


В QuestDB можно добавить одну строчку и огромный батч, триллион запросто. Заточка на оба сценария:

Insert
Insert
...
Insert
Commit

И так же:

Insert
Commit
Insert
Commit
...

Конкурентная агрегация в случае нехватки памяти будет ворошить диск. Если результаты агрегации не помещается с память то конечно может произойти OutOfMemory. Kernel panic не будет так как страницы прикреплены к readonly файлам. Они выталкиваются из памяти безболезненно и перегружаются из файлов в случаи необходимости.


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

OLTP это не основная задача, но как сказал update делается через insert с тем же первичным ключом и последующем схлопыванием версий через



select * from table latest by id

5 дек 19, 21:52    [22033587]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

mayton
зачем вообще что-то создавать?

Ну как же, лохокриптотрон требует сохранения за 15 микросекунд. Через 16 уже будет
поздно и курс упадёт.

Posted via ActualForum NNTP Server 1.5

5 дек 19, 21:59    [22033588]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

Бенчмарк я сделал, результаты на первой или второй странице. Железо тоже описал — ноутбук пока

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

1. Сгенерировать csv - QuestDB такое легко умеет
2. Залить этот файл в базу — делали одну таблицу для простоты
3. Погонять запросы — какие запросы я гонял тоже привёл.


Было бы конечно интересно получить независимую поддержку в этом деле, чтобы я свои цифры не приукрашивал.

Насчёт use-cases, пока стремление заменить influxdb на более производительную базу с человеческим лицом. Это для сбора метрик и данных с сенсоров и рынков. Новые юзкеисы по мере адаптации. Наша задача поддержать вас — разработчиков всем необходимым для решения новых задач
5 дек 19, 22:02    [22033591]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 2022
bluestreak
Было бы конечно интересно получить независимую поддержку в этом деле, чтобы я свои цифры не приукрашивал.

Для этого вам надо предоставить легко воспроизводимый пример, чтобы можно было в несколько команд (в идеале одной) запустить бенчнмарк и получить готовый результат. Есть у вас такое? Не важно как это будет оформлено скрипты или контейнеры, важно чтобы потенциально интересующийся мог быстро проверить это в своем окружении, важно чтобы все видели с какими настройками запускаются конкуренты. Тогда и доверия к результатам будет больше.
6 дек 19, 07:15    [22033734]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6360
bluestreak
mayton,

Бенчмарк я сделал, результаты на первой или второй странице. Железо тоже описал — ноутбук пока
надо менять
ноут и серверное железо, да и серверные ОС очень отличаются по настройкам
6 дек 19, 09:37    [22033777]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak

1. Сгенерировать csv - QuestDB такое легко умеет

Как это? Сгенерировать?
6 дек 19, 12:18    [22034030]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Дегтярев Евгений
bluestreak
Было бы конечно интересно получить независимую поддержку в этом деле, чтобы я свои цифры не приукрашивал.

Для этого вам надо предоставить легко воспроизводимый пример, чтобы можно было в несколько команд (в идеале одной) запустить бенчнмарк и получить готовый результат. Есть у вас такое? Не важно как это будет оформлено скрипты или контейнеры, важно чтобы потенциально интересующийся мог быстро проверить это в своем окружении, важно чтобы все видели с какими настройками запускаются конкуренты. Тогда и доверия к результатам будет больше.


Я согласен вполне. Вот здесь ребята напилили, https://github.com/timescale/tsbs вам в таком формате подошло бы?
6 дек 19, 15:09    [22034308]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
kealon(Ruslan)
bluestreak
mayton,

Бенчмарк я сделал, результаты на первой или второй странице. Железо тоже описал — ноутбук пока
надо менять
ноут и серверное железо, да и серверные ОС очень отличаются по настройкам


Тоже согласен, лаптоп ещё постоянно процессор зажимает из-за температуры, но я сравнивал целую неделю, с холодным лаптопом, тёплым, кучу раз одно и тоже запускал чтобы понять jitter. Дело в том у нас разница со всеми кроме KDB просто в разы. Может конечно наше железо любит нашу базу больше — но я сомневаюсь.

Попробуем на облачном железе конечно.
6 дек 19, 15:15    [22034317]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

Я же вам на этот вопрос ранее ответил. Запросы внизу, запускаем QuestDB открываем вэб консоль на порту 9000 и запускаем запрос. Это псевдо—рандомный генератор, можно сгенерировать все поддерживаемые типы данных и невменяемое количество записей если нужно. Можно это прям из браузера скачать сколько вам угодно данных

bluestreak
mayton,

Вы правы, многопоточная обработка данных гораздо предпочтительная если взять во внимание железо. Однопоточная обработка в QuestDB это оговорка для ясности, но она похоже запутала. Позвольте объяснить:

QuestDB сетевые сервисы являются многопоточными. Потоков фиксированое количество. Они работают с сокетами через epoll и позволяют работать в моногопользовательском режиме. Однако когда пользователь запускает запрос, этот запрос будет использовать одно ядро. Мы тестировали в такой среде по http

Данные сгенерили таким запросом



select timestamp_sequence(to_timestamp('2019.10.17T00:00:00.000000', 'yyyy.MM.ddTHH:mm:ss.SSSUUU'), 100000L) ts,
rnd_str(2,2,0) instrument,
abs(to_int(rnd_double(0)*100000)) price,
abs(to_int(rnd_double(0)*10000)) qty,
rnd_str('B', 'S') side
from long_sequence(10000000) x;


И потом скачали с сервера через web console, там есть кнопка «скачать»

Для influx исходные данные создавались таким запросом:



select
concat(
'trades,instrument=', rnd_str(2,2,0),
',side=', rnd_str('B', 'S'),
' price=', abs(to_int(rnd_double(0)*100000)),
',quantity=', abs(to_int(rnd_double(0)*10000)),
' ',
1571270400000 + (x-1) * 100
)
from long_sequence(10000000) x;


Параметр к long-sequence это количество записей, можно большое количество если нужно. Серверу предел это диск. Если номер записей сильно большой, добавьте L, т.е 10000000000000000L
6 дек 19, 15:21    [22034325]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak, я надеюсь ты понимаешь что синтетические данные будут не очень представлять интерес.

Вообще, данные нужны приближённые к реальным. Например если на этих данных будут искать аномалии,
регрессии или тренировать нейронные сети, то и генерация их соотвественно должна иметь какой-то паттерн
или пресет. Например таймсерия меряет курс показания 100 датчиков темпператур по предприятию.
Разве они будут давать random? Нет. Они будут давать некий Гауссов колокольчик. Или нечто более сложное.
Если таймсерия меряет курс валюты в течение 10 лет - то она не может скакать как random с минимума на максимум.

Ну вобщем ты понимаешь. Нельзя на основе ситетического датасета доказать правду применительно к реальным
данным. Если ты и генеришь данные то ты должен хотя-бы подумать о том как эти данные выглядят на графике?
Как я могу сделать выборку окна где валюта превышала какую-то величину. Как я могу на твоей БД померять
корреляцию одного температурного датчика от другого.
6 дек 19, 15:34    [22034342]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
курс одной котировки за 15+ лет в "минутках" = 15*365*24*60 = 7 884 000 записей на один символ
возьмем, от балды, 50 тыс. символов = 7 884 000 * 50 000 = 394 200 000 000 записей

IMHO примерно с такого объема данных можно начинать тестить и заканчивая где-то на 250-500 тыс символов

если мы говорим о котировках

AFAIK

p.s. сотни тысяч символов получалось на каких-то специализированных рынках (вроде облигации или что-то такое), почему так много, в свое время объясняли, но я уже не помню. Но там символов было много, а данных, соответвтенно, в столько же раз меньше.
6 дек 19, 16:01    [22034376]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
смысла поколоночника для котировок особой не вижу
в реальной системе били на чанки по времени

также, не очень понятно, можно ли запросный движок обучать "хитрым" агригациям. Как я помню, вроде дневные и недельные котировки могут считаться хитрым образом, в зависимости от времени и графика работы биржи
6 дек 19, 16:05    [22034383]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton
bluestreak, я надеюсь ты понимаешь что синтетические данные будут не очень представлять интерес.

Вообще, данные нужны приближённые к реальным. Например если на этих данных будут искать аномалии,
регрессии или тренировать нейронные сети, то и генерация их соотвественно должна иметь какой-то паттерн
или пресет. Например таймсерия меряет курс показания 100 датчиков темпператур по предприятию.
Разве они будут давать random? Нет. Они будут давать некий Гауссов колокольчик. Или нечто более сложное.
Если таймсерия меряет курс валюты в течение 10 лет - то она не может скакать как random с минимума на максимум.

Ну вобщем ты понимаешь. Нельзя на основе ситетического датасета доказать правду применительно к реальным
данным. Если ты и генеришь данные то ты должен хотя-бы подумать о том как эти данные выглядят на графике?
Как я могу сделать выборку окна где валюта превышала какую-то величину. Как я могу на твоей БД померять
корреляцию одного температурного датчика от другого.



Я прекрасно понимаю что пример не универсальный. Эти данные вполне подходили для запросов для которых я сравнивал производительность.

Для колокольчиков можно другие рандомные данные нагенерить. long_sequence() имеет монотонно возрастающую колонку «x» которую можно поставить в формула распределения Гаусса
6 дек 19, 16:09    [22034390]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Leonid Kudryavtsev
курс одной котировки за 15+ лет в "минутках" = 15*365*24*60 = 7 884 000 записей на один символ
возьмем, от балды, 50 тыс. символов = 7 884 000 * 50 000 = 394 200 000 000 записей

IMHO примерно с такого объема данных можно начинать тестить и заканчивая где-то на 250-500 тыс символов

если мы говорим о котировках

AFAIK

p.s. сотни тысяч символов получалось на каких-то специализированных рынках (вроде облигации или что-то такое), почему так много, в свое время объясняли, но я уже не помню. Но там символов было много, а данных, соответвтенно, в столько же раз меньше.


Отлично, подобная задача может решаться полностью паралллельно. Можно например залить столько символов в одну базу сколько ядер на процессоре и выполнять запросы для каждого символа параллельно. 7.5 записей это фигня для одного потока. Вопрос только что с этими записями делать? Составлять volume based order book и считать wvap?
6 дек 19, 16:23    [22034415]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Помните о чем я говорил. Параллелизм линейно наращивается на вычислительных задачах типа майнинга.
Там где у процессов shared nothing. Получили задачу. Отработали и отдали результат.

У вас - интенсивная интеракция с памятью. Тут старик Амдал злобно хохочет над нами. Первый поток загузит
канал памяти вычитками. Второй поток поднимет общую производительность на 20-30% наверное. А третий
еще добавить 3-5% и так далее.

Вот здесь хадуп - герой. Дада дорогой товарищ. Имеено та таком кейсе.
6 дек 19, 16:28    [22034418]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Leonid Kudryavtsev
смысла поколоночника для котировок особой не вижу
в реальной системе били на чанки по времени

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


Если все данные всегда обрабатываются вместе то поколонник конечно проблемы не решают. В то же время расходы на наш поколонник супер маленькие.

Для произвольных поисков или даже диапазон дат искать — есть преимущества.

Хитрая агрегация не для всего, согласен.
6 дек 19, 16:28    [22034419]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton
Помните о чем я говорил. Параллелизм линейно наращивается на вычислительных задачах типа майнинга.
Там где у процессов shared nothing. Получили задачу. Отработали и отдали результат.

У вас - интенсивная интеракция с памятью. Тут старик Амдал злобно хохочет над нами. Первый поток загузит
канал памяти вычитками. Второй поток поднимет общую производительность на 20-30% наверное. А третий
еще добавить 3-5% и так далее.

Вот здесь хадуп - герой. Дада дорогой товарищ. Имеено та таком кейсе.


Это теория, давайте может попробуем на практике?
6 дек 19, 16:30    [22034422]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
mayton
Помните о чем я говорил. Параллелизм линейно наращивается на вычислительных задачах типа майнинга.
Там где у процессов shared nothing. Получили задачу. Отработали и отдали результат.

У вас - интенсивная интеракция с памятью. Тут старик Амдал злобно хохочет над нами. Первый поток загузит
канал памяти вычитками. Второй поток поднимет общую производительность на 20-30% наверное. А третий
еще добавить 3-5% и так далее.

Вот здесь хадуп - герой. Дада дорогой товарищ. Имеено та таком кейсе.

хадуп и low latency - это перпендикулярные понятия
там полчаса вставка одной записи, полчаса выборка
6 дек 19, 16:34    [22034430]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Бумбараш
mayton
Помните о чем я говорил. Параллелизм линейно наращивается на вычислительных задачах типа майнинга.
Там где у процессов shared nothing. Получили задачу. Отработали и отдали результат.

У вас - интенсивная интеракция с памятью. Тут старик Амдал злобно хохочет над нами. Первый поток загузит
канал памяти вычитками. Второй поток поднимет общую производительность на 20-30% наверное. А третий
еще добавить 3-5% и так далее.

Вот здесь хадуп - герой. Дада дорогой товарищ. Имеено та таком кейсе.

хадуп и low latency - это перпендикулярные понятия
там полчаса вставка одной записи, полчаса выборка

Справедливое замечание. Согласен. Но мой тезис был-бы неполный если-бы мы обсуждали только
системы на базе 1 физического сервера. Надо было еще рассмотреть вычислительный grid.
6 дек 19, 16:51    [22034442]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak
mayton
Помните о чем я говорил. Параллелизм линейно наращивается на вычислительных задачах типа майнинга.
Там где у процессов shared nothing. Получили задачу. Отработали и отдали результат.

У вас - интенсивная интеракция с памятью. Тут старик Амдал злобно хохочет над нами. Первый поток загузит
канал памяти вычитками. Второй поток поднимет общую производительность на 20-30% наверное. А третий
еще добавить 3-5% и так далее.

Вот здесь хадуп - герой. Дада дорогой товарищ. Имеено та таком кейсе.


Это теория, давайте может попробуем на практике?

Дай бог. Попробуем.

Я пока не нашел практического применения для вашей системы. Но как только найду - затещу на своих данных.
Если вы не против. И на своих запросах.
6 дек 19, 16:52    [22034444]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
bluestreak

Вопрос только что с этими записями делать?

х.з. я не специалист,
https://ru.tradingview.com/

на вход online поток данных (минутки, пятиминутки) с рынка
на выходе история + агрегация
онлайн объединения истории + новые данных и онлайн агрегация

Но опять таки, нужно помнить, что агрегация это не тупое суммирование, а должна подчиняться правилам. Вроде из минуток дни собираются уже хитрым образом. Аналогично недели. Сплиты акций и пр. и пр.

т.е. СУБД должна допускать возможность написания своих правил агрегации

если дни, недели и всякие сплиты акций обрабатываются уровнем выше, чем БД, то тогда на уровне БД останется только хранение, а с этим любая база справится (данные хранятся не в виде записей, а просто chunk'ами в blob в сериализованном виде)

ACID/надежность не сильно важна, т.к. потеря данных за текущей день вполне допустима (можно заново запросить у биржи)

bluestreak

Можно например залить столько символов в одну базу сколько ядер на процессоре и выполнять запросы для каждого символа параллельно

50 тысяч символов
Возможно у Пентагона компьютеры с 50 тыс. ядер и существуют, но это как-то перебор )))

Сам присутствовал, когда "агрегатор" сломался при попытке залить за одну операцию >150 тысяч символов, банально одни только акторы для символов сожрали 2Gb heap.

Какой-то хитрый рынок, где символов безумно много, но они маленькие

Поэтому даже идея наплодить столько файлов, сколько символов - и то выглядит немного нетрадиционно, а уж сколько символов = столько ядер - утопия.

bluestreak

Если все данные всегда обрабатываются вместе то поколонник конечно проблемы не решают. В то же время расходы на наш поколонник супер маленькие.

bar'ы котировок
расходы на поколочник супер маленькие - не сильно верится
расходы должны быть прямо пропорциональны кол-ву колонок

mayton
Первый поток загузит канал памяти вычитками. Второй поток поднимет общую производительность на 20-30% наверное

не преувеличивайте
у серверных процессоров кэш по 2-16 Mb на ядро
перегрузить канал памяти вычитками, надо сильно постараться

тут скорее важнее скорость общения с другими системами + переключение потоков операционкой

у клиентов автора меланох и, подозреваю, если админы старались время выжимать, прерывания и обработчики к конкретным ядрам прибиты гвоздями

Но честно говоря, узок круг людей, которые приложения на таких серверах готовы разворачивать. У обычных людей Ethernet и виртуалки, и хорошо если в одной стойке, а не в разных серверных и на разных континентах. А тут уже latency запроса будет значимо.

Т.е. банальная идея например агрегировать минутки в СУБД, а дни собирать на уровне приложения - уже не очень хорошо выглядит. Для одного года потребуется уже 365 запросов. Тогда проще все вычитать одним запросом и все агрегировать на стороне приложения.
6 дек 19, 17:40    [22034487]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

Отлично! Если есть время и настроение давайте что нибудь сообразим. Вы мне подкиньте структуры и типы запросов, а я туда подходящих данных на генерю и попробуем туда—сюда
6 дек 19, 17:41    [22034489]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak
mayton,

Отлично! Если есть время и настроение давайте что нибудь сообразим. Вы мне подкиньте структуры и типы запросов, а я туда подходящих данных на генерю и попробуем туда—сюда

Кстати. Ты материализованные представления создаёшь? Вот посчитал я арифметическое среднее и средне-квадрат отклонение
для целой сериии. Жаль терять результат. Куда его сохранить?
6 дек 19, 17:59    [22034500]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

Пока нет, но можно сделать легко.

Есть вот это пока:


create table tab as select ...
truncate table ...
insert into tab (select ...)
6 дек 19, 18:04    [22034502]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Leonid Kudryavtsev,

автор

х.з. я не специалист,
https://ru.tradingview.com/

на вход online поток данных (минутки, пятиминутки) с рынка
на выходе история + агрегация
онлайн объединения истории + новые данных и онлайн агрегация

Но опять таки, нужно помнить, что агрегация это не тупое суммирование, а должна подчиняться правилам. Вроде из минуток дни собираются уже хитрым образом. Аналогично недели. Сплиты акций и пр. и пр.


Ну обычно собирается ордер бук на каждый чих с размеры по вертикали и цены по горизонтали и на это считают VWap.

В QuestDB я как раз сделал все функции как плагины, свою написать довольно просто на Java или другом JVM языке. Даже можно код функции оставить в своём проекте


автор

50 тысяч символов
Возможно у Пентагона компьютеры с 50 тыс. ядер и существуют, но это как-то перебор )))

Сам присутствовал, когда "агрегатор" сломался при попытке залить за одну операцию >150 тысяч символов, банально одни только акторы для символов сожрали 2Gb heap.

Какой-то хитрый рынок, где символов безумно много, но они маленькие

Поэтому даже идея наплодить столько файлов, сколько символов - и то выглядит немного нетрадиционно, а уж сколько символов = столько ядер - утопия.




Я не это имел ввиду. Если есть 10 серверов к примеру с 36 ядрами каждый, то можно допустить что одновременно можно считать 360 символов без всякой координации между этими вычислениями.

Затем 360 символов в следущей группе итд, 139 груп.

Интересно посмотреть сколько времени один символ займёт (7.5м это очень мало, для примера на моем перегретом лаптопе 10м «агрегируются» за 0.22с, ок, более сложная формула добавит что-то но я думаю воткнуть символ в секунду это вполне реалистично)

Затем посмотреть что система может выполнить запрос по двум символам одновременно за время одного.

Из этого вытекает 139с :)

Неплохо для 139 триллионов записей :Р
6 дек 19, 18:27    [22034516]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
В timeseries не силен, т.ч. мнение полного дилетанта. Возможно пишу бред.

1. Документации типа reference не нашел. Tutorial бегло просмотрел, но мало чего понял. Даже описание синтаксиса SELECT'а не увидел

2. Для реальных приложений, явно стандартного набора SUM, AVG, COUNT хватать не должно.
Т.е. на мой взгляд, с учетом того, что система Open Source и написана на Java (?), должна быть документация (чего вообще не увидел) насколько легко можно реализовывать и встраивать свои функции
УЖЕ ОТВЕТИЛИ. СПАСИБО

3. Поддержка TimeZone. Для Time Series СУБД на мой взгляд, нормальная (отсутствующая в обычных базах) поддержка такого понятие как time, быть должно

Подозреваю, "обычные" СУБД даже с задачей посчитать avg/min/max по дню в таймзоне биржи на которой листинг уже справятся через одно место.

А если день считать с момента открытия и до момента закрытия биржи, то и подавно. При этом за 15 лет время работы биржи могло и поменяться

Аналогично понятие неделя, год, месяц.... Не всегда год начинается 1 января в 0:00, он может начаться и 11 января в 9:00 (первый рабочий день). При этом, если мы говорим об интервале времени в десятки лет, данные правила могли и меняться со временем

Есть ли какая поддержка для такой работы с датами/временем в Вашей СУБД ?

4.
Не очень понятно, как работают(должны работать) JOIN двух и более time series.

Вообще, отличает ли СУБД join'ы:
1) time series с не time series (пример из туториала соединение справочника датчиков и измерений)
2) join time series с time series одинаковой размерности
3) join двух time series с разными размерностями, приводить размерность одних тайм серий к другим

Например есть тайм серия минутных баров, есть времени работы биржи, есть сплит акций

Мы хотим выбрать данные за 2015 год и получить максимальную цену на каждый день, на момент закрытия биржи, при этом с учетом сплита который произошел 01.03.2015 9:00.
(т.е. цену до 01.03.2015 9:00 нужно умножить в два раза)

Как должны выглядеть таблицы и какой должен быть запрос?

Техническое убрал под спойлер
+

1. Хранение информации по котировках. Масштабируемость решения (СУБД все же должна уметь масштабироваться).

Если хранить каждый символ в отдельном файле (да еще отдельные колонки bat'а тоже в отдельных файлах!)
Кол-во символов в несколько десятков тысяч - мне кажется совершенно нормально даже для уровня одной биржи
Т.е. как минимум должна быть проверка и доказательство, что система нормально работает при таком кол-ве файлов-партиций и/или существует какой-то механизм автоматического закрытия/открытия файлов

2. Обновление.
Я так понимаю, в лучших традициях FvMas ))), данные хранятся в виде банального массива
Для time seriaes баров котировок, это скорее хорошо, чем плохо. Но встает вопрос накладных расходов.
Как я понимаю, каждый "активный" символ будет требовать 4 K памяти (страница) * кол_во_колонок_в_баре

пусть 50 000 символов * 8 колонок на бар (произвольно) * 8 байт на double * 4 000 байт = всего 12 800 MB для in-memory буферов для активного изменения. Как бы не много, я ожидал большего )))
6 дек 19, 19:48    [22034564]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
На самом деле представляю объем работы, что бы сделать свою СУБД..... офигеть
6 дек 19, 19:51    [22034566]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Leonid Kudryavtsev

Не очень понятно, как работают(должны работать) JOIN двух и более time series.

Скорее всего - никак. Это не юзкейс таймсерии. В смысловой нагрузке таймсерия это некая ось
координат вдоль которой рисуется график измеряемой величины. Как можно джойнить график - непонятно.
6 дек 19, 19:57    [22034568]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

Leonid Kudryavtsev
На самом деле представляю объем работы, что бы сделать свою СУБД..... офигеть

Если специализированную, как у автора, без поддержки UPDATE и DELETE, без транзакций и без
полного синтаксиса SQL - не слишком много.

Posted via ActualForum NNTP Server 1.5

6 дек 19, 20:03    [22034576]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

Leonid Kudryavtsev
На самом деле представляю объем работы, что бы сделать свою СУБД..... офигеть

Если специализированную, как у автора, без поддержки UPDATE и DELETE, без транзакций и без
полного синтаксиса SQL - не слишком много.



Удивительный человек, писать может а читать нет. Я вам уже два раза про транзакции и update сказал. Ну ладно, продолжай троллить.
6 дек 19, 20:07    [22034577]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Я вам уже два раза про транзакции и update сказал.

Ну так и я о том же:
bluestreak
— сложность удаления индивидуальных записей, в случае QuestDB —
невозможность, данные удаляютя удаляются через партиции
— невозможность физического изменения записей; изменения виртуальные и реализуются через
select

То есть ни DELETE, ни UPDATE - нет.

bluestreak
Данные полностью атомичны и все чтения полностью изолированы. Причём
размер транзакции не ограничен.

То есть вся транзакционность сводится к dirty read с полной блокировкой таблицы.

Posted via ActualForum NNTP Server 1.5

6 дек 19, 20:20    [22034584]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Leonid Kudryavtsev
На самом деле представляю объем работы, что бы сделать свою СУБД..... офигеть

Я думаю что большинство "самодельных" СУБД представляют собой вариации на тему Redis.
Key-Value. In-Memory. No ACID. Just atomic. С легкого старта - работает но куда-то улучшить... практически
невозможно безе пересмотра всей механики сразу.

Я тоже частенько рассеянно думаю над двумя СУБД. Хранилище фактов. Где каждый dataRow будет занимать 1 бит.
И колончатое древовидное хранилище где все строки всегда отсортированы. Грубо говоря нет разницы между таблицей
и индексом. Думаю я над этими СУБД по 2-3 минуты в день на сон грядущий. И написал я по ним ровно 1 файл
README.md
6 дек 19, 20:21    [22034585]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Dimitry Sibiryakov

То есть ни DELETE, ни UPDATE - нет.

Яж говорю. Хадуп-Хадупище Только в бедной memory.
6 дек 19, 20:23    [22034586]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

То есть вся транзакционность сводится к dirty read с полной блокировкой таблицы.


Бред. Чтение и запись QuestDB это share nothing система. Чтение никогда и ни кем не блокируется.


Новый персональный рекорд по прыжкам к умозаключениям.
6 дек 19, 20:28    [22034589]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
mayton
Leonid Kudryavtsev

Не очень понятно, как работают(должны работать) JOIN двух и более time series.

Скорее всего - никак. Это не юзкейс таймсерии. В смысловой нагрузке таймсерия это некая ось
координат вдоль которой рисуется график измеряемой величины. Как можно джойнить график - непонятно.

Как раз таки юзкейс.

1) Разные датчики
Расходомер (скорость потока) + датчик температуры / давления. Нужно получить объем.
Датчики стоят на разных агрегатах и выдают данные с разной периодичностью

2) Как минимум технологический юзкейс. Банальные bitmap index'ы в обычных СУБД. Для Time Series должны работать просто превосходно.

Т.ч. например сделать генератор (итератор), который из обычной не time series таблички с датами вида (start_date, end_date) сделает time series нужной размерности (пусть даже минутку), а дальше.... все условия сведутся просто к одновременному проходу по 2(или более) time series с передачей в ф-цию обработчик значения из всех time series или банальный filter.

Иначе запросы объединения интервальных/историчных данных на SQL - "мать, мать, мать.... привычно ответило эхо"

Даже чисто такой движок, просто был бы не заменим для любой системы, где приходится работать с историческими данными. (только не понятно, как его встроить/использовать в существующих экосистемах)

Бизнес-кейсов просто миллион можно придумать.
6 дек 19, 20:30    [22034591]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Чтение и запись QuestDB это share nothing система. Чтение никогда и ни кем не блокируется.

От такого определения "shared nothing" моя челюсть упала на пол.

Ок, чтение не блокируется. Как у тебя взаимодействуют два коннекта, один из которых
добавляет миллион записей, а второй читает тысячу последних?

Posted via ActualForum NNTP Server 1.5

6 дек 19, 20:41    [22034602]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Leonid Kudryavtsev
В timeseries не силен, т.ч. мнение полного дилетанта. Возможно пишу бред.

1. Документации типа reference не нашел. Tutorial бегло просмотрел, но мало чего понял. Даже описание синтаксиса SELECT'а не увидел



Не бред. Мы только недавно начали документацию писать, доделаем. Вы на это смотрели?

https://www.questdb.io/docs/select

И joins:

https://www.questdb.io/docs/join



3. Поддержка TimeZone. Для Time Series СУБД на мой взгляд, нормальная (отсутствующая в обычных базах) поддержка такого понятие как time, быть должно




Поддержка времени заключается в двух типах, Date и Timestamp. Date это на самом деле время до миллисекунды а Timestamp до микросекунды. Все хранится в UTC. Внутри системы есть база данных с зонами, есть функция to_timestamp(), конвертирует строку в данном формате. Формат поддерживает тайм зоны.

Искать диапазоны можно так


tab where ts = ‘2015-03’

Найдёт все за март, ... но, этот синтакс не поддерживает зоны.. нужно исправить :(


Подозреваю, "обычные" СУБД даже с задачей посчитать avg/min/max по дню в таймзоне биржи на которой листинг уже справятся через одно место.

А если день считать с момента открытия и до момента закрытия биржи, то и подавно. При этом за 15 лет время работы биржи могло и поменяться

Аналогично понятие неделя, год, месяц.... Не всегда год начинается 1 января в 0:00, он может начаться и 11 января в 9:00 (первый рабочий день). При этом, если мы говорим об интервале времени в десятки лет, данные правила могли и меняться со временем

Есть ли какая поддержка для такой работы с датами/временем в Вашей СУБД ?



Это по сути пользовательский календарь? Прямой поддержки нет, но можно функцию сделать, например это существующая группировка:


select avg(price) from quotes sample by 1d where ts = ‘2015’

Это по дням в григорианском календаре и UTC. 1d это встроенная функция округления, но можно попробовать


select avg(price) from quotes sample by calendar(‘1d’) where ts = ‘2015’

?

обязательно отвечу на последний вопрос!
6 дек 19, 21:12    [22034610]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
Чтение и запись QuestDB это share nothing система. Чтение никогда и ни кем не блокируется.

От такого определения "shared nothing" моя челюсть упала на пол.

Ок, чтение не блокируется. Как у тебя взаимодействуют два коннекта, один из которых
добавляет миллион записей, а второй читает тысячу последних?



Чтение последних 1000 записей выглядит так:


tab limit -1000


Если запрос начал выполняться до того как писатель вызвал commit() то вернутся 1000 записей до начала писания первой записи этого миллиона. В независимости от текущего положения и состояния писателя.

Если запрос после commit() — сами понимаете, последняя 1000 от добавленного миллиона.

Сообщение было отредактировано: 6 дек 19, 21:18
6 дек 19, 21:17    [22034612]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Если запрос начал выполняться до того как писатель вызвал commit() то вернутся 1000
записей до начала писания первой записи этого миллиона. В независимости от текущего
положения и состояния писателя.

Ок. Задачка номер 2. Два коннекта одновременно добавляют по миллиарду записей. Как будут
расположены эти записи в базе:
а) Сначала миллиард первого, потом миллиард второго.
б) Вперемешку.

Каково поведение твоей базы?

Posted via ActualForum NNTP Server 1.5

6 дек 19, 22:11    [22034628]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
Если запрос начал выполняться до того как писатель вызвал commit() то вернутся 1000
записей до начала писания первой записи этого миллиона. В независимости от текущего
положения и состояния писателя.

Ок. Задачка номер 2. Два коннекта одновременно добавляют по миллиарду записей. Как будут
расположены эти записи в базе:
а) Сначала миллиард первого, потом миллиард второго.
б) Вперемешку.

Каково поведение твоей базы?


Если оба миллиарда содержат один commit() в конце - то сначала первый потом второй.

Если в таблице не определён timestamp, то обе транзакции войдут без проблем. Если timestamp определён, то база проверяет что данные в хронологическом порядке. Если нет - второй коннект получит ошибку.
6 дек 19, 23:33    [22034664]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Если оба миллиарда содержат один commit() в конце - то сначала первый потом второй.

То есть полная сериализация: пока одна транзакция не завершилась - вторая не стартует?

Posted via ActualForum NNTP Server 1.5

6 дек 19, 23:44    [22034669]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
Если оба миллиарда содержат один commit() в конце - то сначала первый потом второй.

То есть полная сериализация: пока одна транзакция не завершилась - вторая не стартует?


Если по одной таблице - да. Таблицы разные - заливаются полностью параллельно.
6 дек 19, 23:53    [22034672]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
mayton

Скорее всего - никак. Это не юзкейс таймсерии....

Не угадал.
В базе даже специальное понятие ASOF JOIN ввели.

В общем, интересная штука. Если реально работает и к ней приделать удобную возможность DB LInk к "обычным" базам (Oracle), то в целом можно придумать более-менее осмысленные применения "в быту". Начина от бухгалтерии и биллинга ЖКХ.

Использовать в качестве основной базы данных никто не будет, но почему бы не использовать отдельно для работы/анализа/расчетов
7 дек 19, 00:19    [22034679]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Если по одной таблице - да.

И если первый клиент впал в кому или тихо скончался от электрической недостаточности на
100500-й записи из миллиона, вторая транзакция будет ждать... сколько?

Posted via ActualForum NNTP Server 1.5

7 дек 19, 00:34    [22034683]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
Если по одной таблице - да.

И если первый клиент впал в кому или тихо скончался от электрической недостаточности на
100500-й записи из миллиона, вторая транзакция будет ждать... сколько?


Это кстати интересно. Сейчас транзакция откатывается если сокет отконнектился. Если впал в кому, то есть idle timeout, т.е. сервер закроет сокет со своей стороны и транзакцию с миллиардом откатит. Можно ещё ввести ограничения снизу на скорость заливки и длину открытой транзакции - это по запросам если необходимо.
7 дек 19, 00:45    [22034685]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Если timestamp определён, то база проверяет что данные в хронологическом порядке.

То есть если мы вставили в такую таблицу (2019-12-05, 666), а потом решили, что это
ошибка, то изменить вставить (2019-12-05, 777) уже не получится? Надо будет убить
всю таблицу, а потом вставить её заново, с правильными данными.

bluestreak
Таблицы разные - заливаются полностью параллельно.

Я так понимаю, ключи и прочая ссылочная целостность отсутствует как класс?

Posted via ActualForum NNTP Server 1.5

7 дек 19, 01:27    [22034692]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Leonid Kudryavtsev
mayton

Скорее всего - никак. Это не юзкейс таймсерии....

Не угадал.
В базе даже специальное понятие ASOF JOIN ввели.

В общем, интересная штука. Если реально работает и к ней приделать удобную возможность DB LInk к "обычным" базам (Oracle), то в целом можно придумать более-менее осмысленные применения "в быту". Начина от бухгалтерии и биллинга ЖКХ.

Использовать в качестве основной базы данных никто не будет, но почему бы не использовать отдельно для работы/анализа/расчетов

Не могу найти ничего внятного по AS OF. Мы используем этот термин на производстве но смысл его несколько другой.
Больше относится би-темпоральному снимку мета-данных по состоянию на сейчас.

Можете привести пример ASOF JOIN. Обычно JOIN делают по ключам. В таймсериях ключи - обычно timestamp.
Достаточно уникальный и вещественный ключ. Каким образом мы можем его джойнить и какой физический
смысл на выходе мы получим.

Прошу вас не кидайте мне ссылки в литературу. У меня ее полно. Мне интересена ваша интерпретация этого смысла.
7 дек 19, 01:40    [22034693]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov


То есть если мы вставили в такую таблицу (2019-12-05, 666), а потом решили, что это
ошибка, то изменить вставить (2019-12-05, 777) уже не получится? Надо будет убить
всю таблицу, а потом вставить её заново, с правильными данными.


Если на ваш вопрос ответить коротко, то — получится, потому как время должно быть больше или равно... Убивать не надо.

Если по длиннее, то мы говорим о разных вещах. В OLTP системах когда данные вводятся в рукопашную, происходят ой и ай, время может быть просто системным а ключ записи органическим. В таких условиях поменять все ой и ай можно будет без проблем. Повторяйте ключ при вставке, задавайте новые значения полей, время шагает вперёд и все вставляется.

Dimitry Sibiryakov

Я так понимаю, ключи и прочая ссылочная целостность отсутствует как класс?



Понимаете правильно. Здесь проблема идеологического характера. Отторгать данные это плохая идея. Данные нужно собирать все что идут. Даже плохие данные могут быть полезно использованы. Я придерживаюсь мнения что ссылочная целостность с субд — устаревшее понятие. По этому в QuestDB отсутствует как класс
7 дек 19, 02:54    [22034698]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

Представьте что у вас есть таймсерия событий которые побуждают механизм, организм, устройство к действию. Так же у вас есть таймсерия действий этого устройства.

As of join позволяет соединить в одну запись действия устройства с событиями которые непосредственно предшествовали этим действиям.

Финансовый пример это котировки — события; и сделки — действия
7 дек 19, 03:00    [22034703]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Leonid Kudryavtsev,

4.
Не очень понятно, как работают(должны работать) JOIN двух и более time series.

Вообще, отличает ли СУБД join'ы:
1) time series с не time series (пример из туториала соединение справочника датчиков и измерений)
2) join time series с time series одинаковой размерности
3) join двух time series с разными размерностями, приводить размерность одних тайм серий к другим


Я надеюсь с join достаточно было ссылки на доку? Сообщите если нет...
7 дек 19, 03:13    [22034707]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Leonid Kudryavtsev,


Например есть тайм серия минутных баров, есть времени работы биржи, есть сплит акций

Мы хотим выбрать данные за 2015 год и получить максимальную цену на каждый день, на момент закрытия биржи, при этом с учетом сплита который произошел 01.03.2015 9:00.
(т.е. цену до 01.03.2015 9:00 нужно умножить в два раза)

Как должны выглядеть таблицы и какой должен быть запрос?



Если цены top of book, то таблица могла бы выглядеть так:


create table quotes (ts timestamp, sym symbol, bid long, ask long, src symbol) timestamp(ts) partition by month

Если мы предположим что QuestDB может использовать произвольный календарь, то запрос был бы:


select
ts,
sym,
case
when ts < to_timestamp(‘did.mm.yyyy H:mm z’, ‘01.03.2015 9:00 MSK’)
then bid*2
else bid
end bid,

case
when ts < to_timestamp(‘did.mm.yyyy H:mm z’, ‘01.03.2015 9:00 MSK’)
then ask*2
else ask
end ask

from (
select ts, , max(bid) bid, min(ask) ask from quotes sample by calendar(‘my fancy calendar’, ‘1d’)
)


Но поскольку calendar(‘my fancy calendar’, ‘1d’) пока нет, замените на 1d
7 дек 19, 03:42    [22034709]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
По этому в QuestDB отсутствует как класс

Вот об этом я и говорил: полное отсутствие фич, которые делают другие СУБД сложными,
упрощает разработку узкоспециализированного решения до тривиальности.

Опять же к вопросу о транзакциях:
одна делает insert into a, inset into b, commit;
вторая делает insert into b, insert into a, commit;
получаем полный дедлок?..

Posted via ActualForum NNTP Server 1.5

7 дек 19, 16:39    [22034853]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak
mayton,

Представьте что у вас есть таймсерия событий которые побуждают механизм, организм, устройство к действию. Так же у вас есть таймсерия действий этого устройства.

As of join позволяет соединить в одну запись действия устройства с событиями которые непосредственно предшествовали этим действиям.

Финансовый пример это котировки — события; и сделки — действия

На уровне определений я все равно не могу себе представить событие и действие как сущность.

Можете расписать какие поля есть в event, и action? И на основании какого алгоритма одно из них переходит в другое.
7 дек 19, 17:41    [22034878]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
По этому в QuestDB отсутствует как класс

Вот об этом я и говорил: полное отсутствие фич, которые делают другие СУБД сложными,
упрощает разработку узкоспециализированного решения до тривиальности.

Опять же к вопросу о транзакциях:
одна делает insert into a, inset into b, commit;
вторая делает insert into b, insert into a, commit;
получаем полный дедлок?..


Фичи по проверке целостности данных заключаются в построении деревьев и беганьем по ним туда сюда. Если говорить о сложности то я согласен, традиционные базы O(log n) как минимум по вставкам, QuestDB — O(1)

По поводу дедлок — блокировки, включая бесконечные, в questdb тоже отсутствуют как класс. Ваш пример вернёт ошибку даже без тайм-аута.

Вы сделали вывод о дедлоке потому что я сказал транзакции по одной таблице сериализованы?
7 дек 19, 18:11    [22034887]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

Давайте попробую, например событие это цена инструмента на рынке:



Quotes

sym, qbid, qask, qtime
USDCNY, 7.031, 7.029, 15:03
USDCNY, 7.029, 7.027, 15:04
USDCNY, 7.030, 7.028, 15:05

У вас есть электронная система которая формирует свои цены на основе рыночных. Задача такой системы не зевать и менять цены как только рынок изменился.

Например ваша система опубликовала:



Coreprice

sym, bid, ask, time
USDCNY, 7.030, 7.028, 15:05



coreprice asof join quotes on (sym)

sym, bid, ask, time, qbid, qask, qtime
USDCNY, 7.030, 7.028, 15:05, 7.029, 7.027, 15:04



Т.е на момент публикации цены вашей системой мы получаем самую свежую котировку (15:04)
7 дек 19, 18:46    [22034897]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak, а зачем нужно поле символа?

Мы такое - нормализуем к названию сущности.
типа

create table USDCNY(
 qbid decimal, 
 qask decimal, 
 qtime timestamp
);


Под каждый символ - своя таймсерия.
7 дек 19, 19:29    [22034912]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
традиционные базы O(log n) как минимум по вставкам, QuestDB — O(1)

Традиционные базы способны быть O(log N) и по выборкам, а QuestDB - фиксированное O(N).

bluestreak
Вы сделали вывод о дедлоке потому что я сказал транзакции по одной таблице сериализованы?

Да. Но какую именно ошибку получит транзакция, пытающаяся вставить данные в две разные
таблицы и почему?

Posted via ActualForum NNTP Server 1.5

7 дек 19, 20:20    [22034934]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

Это как удобно, некоторые организации хранят все символы в одной таблице. Суть джоина не меняется (‘on’ не нужен в вашем случае)
7 дек 19, 20:42    [22034946]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov,

QuestDB поддерживает индексы и оптимизатор вырулит правильный план если они есть...

Логика работы с таблицами такая: есть один writer и неограниченное количество reader‘ов, мы их оставим в покое, они никогда не блокируются.

Контекст, который получает writer для транзакции от engine хранит его у себя в списке, если контексту нужен ещё один writer то он опять лезет в engine с запросом. Engine может сказать «writer занят», в этом случае у контекста есть два варианта. Первый — жаловаться пользователю, второй — ждать.


Ожидание


1. Хотим добавить имя writer в список ожидания
2. Проверим что все writers которые у контекста уже есть не находятся в списке ожидания.
3. Не находятся — добавим наш writer в этот список
4. Какой-то «наш» writer в списке ожидания — ошибка, откат всего на свете
7 дек 19, 21:55    [22034968]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Допустим у меня были такие таблички

QuotesUSDCNY

qbid, qask, qtime
7.031, 7.029, 15:03
7.029, 7.027, 15:04
7.030, 7.028, 15:05


CorepriceUSDCNY

bid, ask, time
7.030, 7.028, 15:06


Time, qtime - вещественная величина. Она может быть любой. Timestamp например может
фиксировать время прохождения IP пакета через сетевой интерфейс с точностью до микросекунд.

Как это джойнить? Какова вероятность что time/qtime совпадёт? Или там должно быть искусственное округление?

Преобразование ключа??
7 дек 19, 23:06    [22034994]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

В отличий от реляционных join “asof” не использует равенство «=« для объединения. Совпадать ни количество записей ни значения времени в обоих таблицах не должно (необязательно). Так же нет округления времени.

Представьте что мы движемся по таблице corepriceUSDCNY в направлении возрастания времени и присоединяем первую запись из quotesUSDCNY время которой строго меньше времени текущей записи из corepriceUSDCNY
7 дек 19, 23:58    [22035003]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 65894
Блог
bluestreak
В отличий от реляционных join “asof” не использует равенство «=« для объединения

Похоже, для Вас будет новостью, что реляционные джойны тоже не используют. И внезапно окажется, что писать новую базу было совершенно незачем
8 дек 19, 13:45    [22035107]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
softwarer

Похоже, для Вас будет новостью, что реляционные джойны тоже не используют. И внезапно окажется, что писать новую базу было совершенно незачем


Вы разрушили мой стеклянный мир :( приведите пример пожалуйста
8 дек 19, 14:18    [22035122]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Изопропил
Member

Откуда:
Сообщений: 31570
bluestreak,

Select *
 FROM Table1 A INNER JOIN Table2 B On A.Pk <= B.Fk;
8 дек 19, 23:45    [22035317]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Мне кажется данный предикат

A.Pk <= B.Fk;


вместо точечного соединения вернет нам некий "треугольник" ячеек матрицы
на сторонах которой разложены ключи A.Fk, B.Pk. Это КМК опасное соединение
и чреватое ... скажем избыточной выборкой. Не уверен в том что это
то что мы ищем.
8 дек 19, 23:49    [22035321]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 65894
Блог
mayton
Это КМК опасное соединение и чреватое ... скажем избыточной выборкой.

Опасное.. хм.. опасность в любом соединении ровно одна: сформулировать одно, когда хочешь получить другое. А примеры типа ваших элементарно разруливаются через сочетание lag-а и соединения по between.
9 дек 19, 00:20    [22035330]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Мне кажется тут LAG/LEAD не подходит. Фактически нам нужен UNION/MERGE двух тайм-серий
с последующей группировкой или сжатием по символу.
9 дек 19, 00:26    [22035332]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
softwarer
mayton
Это КМК опасное соединение и чреватое ... скажем избыточной выборкой.

Опасное.. хм.. опасность в любом соединении ровно одна: сформулировать одно, когда хочешь получить другое. А примеры типа ваших элементарно разруливаются через сочетание lag-а и соединения по between.


Ну соединения через >= это вариант бесконтрольного cross join со сложностью O(n^2)

А про lag — давайте я вам две таблицы по 100м записей подкину а вы их лагом чпокните? А я asof join со своей стороны на моем некудышнем лаптопе?
9 дек 19, 00:29    [22035333]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 65894
Блог
mayton
Мне кажется тут LAG/LEAD не подходит

Мне кажется, Вы поспешили ответить, не дочитав.
9 дек 19, 00:31    [22035335]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Чпокнуть ... - это не инженерная терминология
9 дек 19, 00:46    [22035339]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 65894
Блог
mayton,

коллега вообще разговаривает как И. В. Бунша.
9 дек 19, 00:49    [22035340]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak

А про lag — давайте я вам две таблицы по 100м записей подкину а вы их лагом чпокните? А я asof join со своей стороны на моем некудышнем лаптопе?

Давай подкидывай. Пиши задание что надо сделать.

И я подозреваю что 100м записей мы качать не захотим. Нужен генератор.
Желательно на каком-то демократичном скрипе (Python) чтоб все желающие
могли быстро сгенерить тестовую выборку.

И давай твой волшебный скрипт который все это сделает на Quest.
9 дек 19, 00:55    [22035341]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
softwarer
mayton,

коллега вообще разговаривает как И. В. Бунша.


Простите, это филологический форум? Вы может ответите на техническое предложение прежде чем на личности переходить?
9 дек 19, 00:57    [22035342]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

Завтра подкину, на QuestDB, чтоб ты на конец скачал сегодня фикшу баги и вот русский язык у коллег учу (в словарь за «неонкой» заглядывал)
9 дек 19, 01:02    [22035344]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak, это Стругацкие - Сказка о Тройке. Классика. Читать надо.
9 дек 19, 01:08    [22035348]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton,

Можно генерить данные в такой последовательности:

— скачай QuestDB 4.0.3 и запусти (есть докер, .sh и .exe)
— браузер на HTTP://localhost:9000


Запусти запросы:


—— пустые таблицы
CREATE TABLE trades_aapl (ts TIMESTAMP, px INT, qty int, side STRING) TIMESTAMP(ts);

CREATE TABLE quotes_aapl (ts TIMESTAMP, bidq INT, bid INT, ask INT, askq INT) TIMESTAMP(ts);

—— 100 Лимонов заказов, где-то 2.8Гб
INSERT INTO trades_aapl SELECT * FROM (
SELECT
timestamp_sequence(to_timestamp('2019-10-17T00:00:00', 'yyyy-MM-ddTHH:mm:ss'), rnd_short(1, 10) * 100000L) ts,
abs(to_int(rnd_double(0)*50+10000)) price,
abs(to_int(rnd_double(0)*1000)) qty,
rnd_str('B', 'S') side
FROM
long_sequence(100000000) x
) TIMESTAMP(ts);

—— 200 Лимонов котировок, где-то 4.5Гб

INSERT into quotes_aapl SELECT * FROM (
SELECT
timestamp_sequence(to_timestamp('2019-10-17T00:00:00', 'yyyy-MM-ddTHH:mm:ss'), rnd_short(1, 4) * 100000L) ts,
abs(to_int(rnd_double(0)*1000)) bidq,
abs(to_int(rnd_double(0)*-50+10000)) bid,
abs(to_int(rnd_double(0)*50+10000)) ask,
abs(to_int(rnd_double(0)*1000)) askiq
FROM
long_sequence(200000000) x
) TIMESTAMP(ts);


Содержимое этих таблиц можно скачать выделив название таблицы и нажав иконку «скачать»

В QuestDB join выглядит следующим образом:



trades_aapl asof join quotes_aapl


Можно select * from в начале приписать но не обязательно.

Этот запрос с моей стороны выполняется за 4.6с на лаптопе, возвращает 100 Лимонов записей.

Интересно как у тебя получится с лагом
9 дек 19, 21:14    [22036300]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Вот более оптимизированный джоин, 0.05с. Разница состоит в том что сервер тратил время на проход до конца курсора (100лимонов) для подсчета записей. В оптимизированном коде число записей берётся из левой таблицы и не вычисляется.

В консоли грид виртуализированый, по сути 0.05с это получить первые 1000 записей джоина на клиент. Скачать весь результат это все же 4.6с + сеть. Ну все равно неплохо для интерактивного клиента.

К сообщению приложен файл. Размер - 126Kb
10 дек 19, 00:51    [22036402]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4155
bluestreak
На много быстрее чем influx и timescale.
по сравнению с influx человеческий SQL, нормально ошибки репортятся, транзакционность данных, отказоустойчивость, поддержка реляционной модели, те неограниченные joins. Можно залить по influx протоколу а вытащить по postgres

По сравнению с timescale, просто быстрее, нагружает сервер меньше, например запрос в questdb выполняется быстрее на одном потоке чем timescale на шести

PostgreSQL инфраструктура конечно хорошая, но мы быстрыми темпами догоняем. Можем фич добавить быстро и без бюрократии

Залив данных из файлов упрощён - questdb заливает гораздо быстрее и автоматом создаёт таблицу и определяет типы полей. Также размер транзакции не ограничен при этом транзакция остаётся атомичной


Мы скоро накрутим incremental запросы, по производительности уничтожим все базы. Раз в 10-100 быстрее будет в зависимости от запроса


не, ну может необразованный школьник и хочет "по производительности уничтожить все базы"
10 дек 19, 09:47    [22036536]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Ролг Хупин

не, ну хочет необразованный школьник и может
10 дек 19, 11:49    [22036691]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
Насколько эффективно Ваша система будет обрабатывать запросы след. видов

Таблички homogeneous time chunks с по-дневные данными вида:
day timestamp
key number
value number

И запросы вида:
SELECT ... FROM t1, t2, t3... t100500
ASOF JOIN t1.day = t2.day ON ( t1.key = t2.key )
...
ASOF JOIN t1.day = t100500.day ON ( t1.key = t100500.key )

При этом распределение данных:
day - около 180 значений (пол года)
key - скажем от 50 00 до 500 000.

В принципе, даже требование на изначальную упорядоченность данных при заливке вполне допустимо (однократный расчет).

Но есть как-то у меня сомнения, что такой паттерн данных это не для Вашей системы (((

В принципе, могу приготовить реальные данные (расчет ЖКХ) и можно будет сравнить тяжеловеса типа Oracle и вашего бегуну.

Идея использования time series (расчет ЖКХ) как-то мне кажется все меньше и меньше бредовой, увеличение кол-ва данных не такое уж и большое (в десятки-сотню раз), зато почти все расчеты начинают нормально представляться в виде SELECT'ов, что крайне круто.
10 дек 19, 13:35    [22036844]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
в синтаксисе SELECT ошибся, но суть думаю ясна. JOIN нужен по двум полям: timestamp + key
При этом распределение перекошено в сторону key.
10 дек 19, 13:37    [22036850]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
/хочет/ необразованный школьник и /может/

Ещё на заре появления in-memory я шутил о БД в регистрах процессора. Миллиарды транзакций
в секунду не превзойти никак.

Posted via ActualForum NNTP Server 1.5

10 дек 19, 13:44    [22036864]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
/хочет/ необразованный школьник и /может/

Ещё на заре появления in-memory я шутил о БД в регистрах процессора. Миллиарды транзакций
в секунду не превзойти никак.


Это все оправдания уважаемый, я объяснял как это работает. Вы после вышеприведённых шагов можете компьютер обесточить и когда включите увидите те же данные и ту же скорость выполнения запросов.

Покажите неграмотному школьнику как что вы сделали лучше и правильнее?
10 дек 19, 13:54    [22036880]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Вы после вышеприведённых шагов можете компьютер обесточить и когда включите увидите те же
данные и ту же скорость выполнения запросов.

А ты пробовал? По твоим же словам синхронный сброс буферов ещё не реализован.

Posted via ActualForum NNTP Server 1.5

10 дек 19, 14:03    [22036893]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Leonid Kudryavtsev
Насколько эффективно Ваша система будет обрабатывать запросы след. видов

Таблички homogeneous time chunks с по-дневные данными вида:
day timestamp
key number
value number

И запросы вида:
SELECT ... FROM t1, t2, t3... t100500
ASOF JOIN t1.day = t2.day ON ( t1.key = t2.key )
...
ASOF JOIN t1.day = t100500.day ON ( t1.key = t100500.key )

При этом распределение данных:
day - около 180 значений (пол года)
key - скажем от 50 00 до 500 000.

В принципе, даже требование на изначальную упорядоченность данных при заливке вполне допустимо (однократный расчет).

Но есть как-то у меня сомнения, что такой паттерн данных это не для Вашей системы (((

В принципе, могу приготовить реальные данные (расчет ЖКХ) и можно будет сравнить тяжеловеса типа Oracle и вашего бегуну.

Идея использования time series (расчет ЖКХ) как-то мне кажется все меньше и меньше бредовой, увеличение кол-ва данных не такое уж и большое (в десятки-сотню раз), зато почти все расчеты начинают нормально представляться в виде SELECT'ов, что крайне круто.


Join будет спокойно работать с «on» фразой, те время + ваши поля, 50000 значений это вполне в диапазоне в котором мы тестируем. Технически количество join не ограничено, но если честно, я не тестировал на 100,000 таблицах. Join выполняется как цепочка пар — нагрузка на память только. Есть ещё и конфигурирований предел размеру SQL текста...

От чего зависит количество таблиц в вашем примере?
10 дек 19, 14:06    [22036902]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
Вы после вышеприведённых шагов можете компьютер обесточить и когда включите увидите те же
данные и ту же скорость выполнения запросов.

А ты пробовал? По твоим же словам синхронный сброс буферов ещё не реализован.


Пробовал. Я не трещу о том что я не делал.
10 дек 19, 14:06    [22036903]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Пробовал.

Сколько раз?

Posted via ActualForum NNTP Server 1.5

10 дек 19, 14:11    [22036914]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
Пробовал.

Сколько раз?


Запись на диск ведётся через 16мб страницы. Когда страница заканчивается она демонтируется, что приводит к асинхронному msync(), и создаётся новая страница итд.

Дело в том что на ссд 16мб записываются довольно быстро. Данные будут на диске перед тем как вам вэб консоль done напишет. В любом случае если вы не дождавшись завершения insert провод из розетки выдерните то будет либо 0 либо 100м записей, поскольку при открытии QuestDB чинит файлы и отматывает побитые транзакции.

Достаточное количество пробовал, е даже несколько HDD убил такими экспериментами.
10 дек 19, 14:20    [22036926]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Запись на диск ведётся через 16мб страницы. Когда страница заканчивается она
демонтируется, что приводит к асинхронному msync(), и создаётся новая страница итд.

Значит, если транзакция маленькая и не достигла 16 мб, она не вызовет msync, несмотря на
то, что клиентская часть уже получила "ок" на commit?..

Posted via ActualForum NNTP Server 1.5

10 дек 19, 14:27    [22036940]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak, топик читаю. Все проверять не успеваю. Возможно ближе к пятнице.
10 дек 19, 14:29    [22036944]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
Запись на диск ведётся через 16мб страницы. Когда страница заканчивается она
демонтируется, что приводит к асинхронному msync(), и создаётся новая страница итд.

Значит, если транзакция маленькая и не достигла 16 мб, она не вызовет msync, несмотря на
то, что клиентская часть уже получила "ок" на commit?..


Пока да, в 4.0.4 будет полная поддержка msync()
10 дек 19, 14:45    [22036965]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton
bluestreak, топик читаю. Все проверять не успеваю. Возможно ближе к пятнице.


Отлично, не торопись!
10 дек 19, 15:15    [22036990]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
Запись на диск ведётся через 16мб страницы. Когда страница заканчивается она
демонтируется, что приводит к асинхронному msync(), и создаётся новая страница итд.

Значит, если транзакция маленькая и не достигла 16 мб, она не вызовет msync, несмотря на
то, что клиентская часть уже получила "ок" на commit?..


Ну вот добавил конфигурируемый msync(), теперь можно делать async/sync/nosync для индивидуального комита или использовать глобальное значение по умолчанию.
11 дек 19, 12:28    [22037663]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
Ну вот добавил конфигурируемый msync(), теперь можно делать async/sync/nosync для
индивидуального комита или использовать глобальное значение по умолчанию.

И при значении sync какая теперь скорость у вставки с коммитом после каждой записи?

Posted via ActualForum NNTP Server 1.5

11 дек 19, 13:45    [22037746]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
Ну вот добавил конфигурируемый msync(), теперь можно делать async/sync/nosync для
индивидуального комита или использовать глобальное значение по умолчанию.

И при значении sync какая теперь скорость у вставки с коммитом после каждой записи?


Здесь бенчмарк. Запись состоит из одной 64—битной колонки:

https://github.com/questdb/questdb/blob/master/benchmarks/src/main/java/org/questdb/TableWriteBenchmark.java

Результат — среднее значение в микросекундах.

Benchmark Mode Cnt Score Error Units
TableWriteBenchmark.testRnd avgt 5 0.002 ± 0.001 us/op
TableWriteBenchmark.testWriteAsync avgt 5 0.769 ± 0.044 us/op
TableWriteBenchmark.testWriteNoCommit avgt 5 0.019 ± 0.003 us/op
TableWriteBenchmark.testWriteNoSync avgt 5 0.023 ± 0.004 us/op
TableWriteBenchmark.testWriteSync avgt 5 2852.849 ± 61.804 us/op

Я опять запустил это на лаптопе, все тесты один за другим. Под конец лаптоп начал перегреваться и nocommit тест опустился с 13нс до 19нс. Похожая картина и в nosync. Sync это на таком устройстве:

3d:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961
11 дек 19, 14:29    [22037798]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Забыл сказать, nocommit тест комитит в конце всего теста и не измеряет скорость комита. Все остальные тесты комитят каждую запись. Все вместе они создали более 10 миллиардов записей.
11 дек 19, 14:36    [22037807]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Как дела? Получается что-то похожее с oracle и его другом Lag’ом сделать?
12 дек 19, 22:39    [22039209]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Мужики, если не получается в оракл либо залить 300м записей, либо отсортировать либо джонить — не беда, давайте этот момент пропустим и продолжим общение. Я же базу пишу чтобы легче жизнь была а не тяжелее.

Мы будем скоро выкатывать поддержку залива данных их influx line protocol. Это популярная тема у Devops. QuestDB имеет UDP ресивер для этого. Тут недавно кто-то спрашивал как поймать 9000 пакетов на Делфи ... Мы тестировали influx и QuestDB, отправляем 50м записей по UDP unicast за 20—23с, influx ловит 2м, QuestDB — 21м это с nosync понятное дело ну и на лаптопе через loopback :)

Это интересно будет если мы ещё графану прикрутим к QuestDB?
15 дек 19, 07:27    [22040565]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
В UDP пакеты имеют свойство загадочным образом "терятся" .

Уверены что оно вам надо?
15 дек 19, 10:51    [22040587]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 65894
Блог
bluestreak
не беда, давайте этот момент пропустим и продолжим общение

Чувак, общаться есть смысл с теми, кто хоть что-то соображает. А над тобой можно только поприкалываться.
15 дек 19, 11:32    [22040598]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
И при чем тут графана - вообще непонятно. С таким-же успехом можно было сказать - а давайте прикрутим
кофе-машину или холодильник. Можно конешно. К любому источнику данных. Но зачем здесь и сейчас?
15 дек 19, 12:35    [22040632]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton
В UDP пакеты имеют свойство загадочным образом "терятся" .

Уверены что оно вам надо?


Пока не уверен. Начинаем с UDP, потом легко и TCP сделать и даже за HTTP поставить — основная сложность в парзере.

UDP полезен в сборе метрик. Простая отправка и отправляющая система не замедляется базой. Время покажет надо или нет :)

графана это очень простая, с точки зрения настройки, визуализация. Легко начальству показать чем занимаешься :)
15 дек 19, 13:06    [22040640]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton
И при чем тут графана - вообще непонятно. С таким-же успехом можно было сказать - а давайте прикрутим
кофе-машину или холодильник. Можно конешно. К любому источнику данных. Но зачем здесь и сейчас?


Это одна из жизненно необходимых фич для devops
15 дек 19, 13:18    [22040647]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
графана это очень простая, с точки зрения настройки, визуализация. Легко начальству
показать чем занимаешься :)

Обычно для этого служит Эксель. ODBC драйвер чтобы к QuestDB можно было из него цепляться
вы выкатывать собираетесь?

Posted via ActualForum NNTP Server 1.5

15 дек 19, 13:42    [22040656]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov

bluestreak
графана это очень простая, с точки зрения настройки, визуализация. Легко начальству
показать чем занимаешься :)

Обычно для этого служит Эксель. ODBC драйвер чтобы к QuestDB можно было из него цепляться
вы выкатывать собираетесь?


Конечно! К QuestDB уже можно по постгрес протоколу цепляться. Через постгрес ODBC! Так же можно через HTTP и VBA, но потом нужно ответы на бэйсике парзить — это на любителя :)
15 дек 19, 14:17    [22040669]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394

bluestreak
К QuestDB уже можно по постгрес протоколу цепляться. Через постгрес ODBC!

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

Posted via ActualForum NNTP Server 1.5

15 дек 19, 14:30    [22040670]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Dimitry Sibiryakov,

Я предполагаю что influx и графана не сильно популярны на этом форуме? У графаны свои прелести — дашборд, графики живые, алертинг это немного другое. Excel конечно вещь хорошая и нужная но одно другого по моему не исключает.

Интересно чем вы мониторите нагрузку на базы, приложения, ОС?
15 дек 19, 15:24    [22040687]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Спокойнее коллеги.

Нормальный топик. Зачем вы его готовите к закрытию?
15 дек 19, 22:19    [22040805]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Можете наши не по топику комментарии удалить?
15 дек 19, 22:32    [22040808]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Нет оснований пока.
15 дек 19, 23:02    [22040811]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Выпустили обновление:

https://github.com/questdb/questdb/releases/tag/4.0.4

Здесь обсуждаемая durability и также разнообразные ускорения, в частности REST точки.
20 дек 19, 10:37    [22044985]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Добрый день,

Ещё несколько новостей. Мы получили инвестиции и собрали команду из очень толковых инженеров. На следущей неделе начинаем развиваться одновременно в нескольких направлениях:

— открыто доступный демо—сервер с данными о такси Нью-Йорка. 1.6 миллиардная основная таблица и дополнительные данные, такие как погода для анализа совпадений событий. Мы переписываем агрегацию с использованием simd и параллелизацией. Подобные запросы будут выполняться менее чем за 1 секунду.

— двухфазовый комит и поддержка распределённых данных

— материализованные запросы


Есть так же идея добавления поддержки многопроходных формул в SQL, например:


select avg(x — sum(y)) from tab

Что вы об этом думаете?

PS: новый сайт https://www.questdb.io/ упростили навигацию по доке, так же добавляем деталей
7 мар 20, 17:20    [22095197]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6360
bluestreak
Есть так же идея добавления поддержки многопроходных формул в SQL, например:


select avg(x — sum(y)) from tab

Что вы об этом думаете?

PS: новый сайт https://www.questdb.io/ упростили навигацию по доке, так же добавляем деталей
это однопроходная формула
если имелась ввиду avg(x — avg(y))

Сообщение было отредактировано: 9 мар 20, 19:34
9 мар 20, 19:33    [22095712]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
[quot kealon(Ruslan)#22095712]
bluestreak
это однопроходная формула
если имелась ввиду avg(x — avg(y))


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

Ещё всякие vwap и тд
9 мар 20, 21:47    [22095739]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
ъъъъъ
Member

Откуда:
Сообщений: 2114
bluestreak
UDP полезен в сборе метрик. Простая отправка и отправляющая система не замедляется базой.

Можно ещё данные отправлять не после каждого "изменения метрик", а лишь каждый 10й раз. Какая разница, по какой причине данные потерялись, зато отправляющая система не замедляется.
9 мар 20, 22:40    [22095749]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Думаю что топик тематически связан с https://www.sql.ru/forum/1323115/proektirovanie-sistemy-sbora-geolokacionnyh-dannyh

Попробуйте автору предложить этот продукт. Заодно потренируетесь в обсуждении практических вопросов.

Сообщение было отредактировано: 9 мар 20, 23:23
9 мар 20, 23:23    [22095762]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton
Думаю что топик тематически связан с https://www.sql.ru/forum/1323115/proektirovanie-sistemy-sbora-geolokacionnyh-dannyh

Попробуйте автору предложить этот продукт. Заодно потренируетесь в обсуждении практических вопросов.


Спасибо!
10 мар 20, 01:32    [22095783]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
ъъъъъ
bluestreak
UDP полезен в сборе метрик. Простая отправка и отправляющая система не замедляется базой.

Можно ещё данные отправлять не после каждого "изменения метрик", а лишь каждый 10й раз. Какая разница, по какой причине данные потерялись, зато отправляющая система не замедляется.


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

В системах у которых метрики не основной вид деятельности UDP и потери вполне приемлемы. Например вы хотите отменить теряющий деньги заказ а торговая система ожидает подтверждения получения метрики от системы которая строит графики на которые никто не смотрит. В таком случае наверно лучше перестать терять деньги чем пропустить пиксель на графике.
10 мар 20, 01:47    [22095789]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
bluestreak,

знаешь что-нибудь про shakti database?
https://shakti.com

её делают создатели kdb, замутили новую контору. Что-нибудь слышно об их внедрениях в индустрии, есть ли успехи?
может у тебя есть инфа какая
30 мар 20, 01:39    [22107851]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Бумбараш
bluestreak,

знаешь что-нибудь про shakti database?
https://shakti.com

её делают создатели kdb, замутили новую контору. Что-нибудь слышно об их внедрениях в индустрии, есть ли успехи?
может у тебя есть инфа какая



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

Они говорят что SIMD использует, но КДБ тоже как и другие проекты и наш в том числе. Ничего нового. Закрытый код тоже, красота, даже туториал закрыли.
30 мар 20, 23:37    [22108447]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
https://news.ycombinator.com/item?id=19418570

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

Сообщение было отредактировано: 30 мар 20, 23:41
30 мар 20, 23:42    [22108449]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
увидел там, что с ними работает некто Саня Белопольский, который написал pyq

не в курсах про pyq, но он сам интересный дядя оказался

https://observer.com/2009/05/alexander-belopolsky-billionaire-jim-simons-old-foe-gets-5-m-condo/

прямо Серёжей Олейниковым повеяло
31 мар 20, 04:08    [22108494]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Бумбараш
bluestreak,

знаешь что-нибудь про shakti database?
https://shakti.com

её делают создатели kdb, замутили новую контору. Что-нибудь слышно об их внедрениях в индустрии, есть ли успехи?
может у тебя есть инфа какая

Если это - космический корабль - то и обсуждаеть его невозможно просто в топике Сравнения СУБД.
(система по сложности близка к операционке) Мы - что-то потеряем или не учтём. Если обсуждать
ЕГО СУБД то ее надо вычленить и проанализировать.

Вобщем. Не вижу смысла я здесь равивать идею шакти.
31 мар 20, 11:18    [22108627]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

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

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

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

select avg(x) from tab
.

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

select sum(a), avg(b), min(c) from tab
.

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

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

QuestDB доступна бесплатно и по Apache 2.0 лицензии, так что скачивайте пробуйте и комментируйте.
3 апр 20, 01:25    [22110241]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6360
bluestreak

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

select sum(a), avg(b), min(c) from tab
.

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

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

Сообщение было отредактировано: 3 апр 20, 09:19
3 апр 20, 09:18    [22110298]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
kealon(Ruslan),

Объясните пожалуйста?
3 апр 20, 11:26    [22110367]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

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

Складывать double значения действительно не точно. могут быть отличия в районе 9 знака после запятой если сравнить параллельную агрегацию с суммированием по одному. Что же делать? Это такой IEEE формат
3 апр 20, 11:37    [22110383]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak

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

Смотри. Системы на базе in-memory имеют узкое применение. В общем случае продуктовые данные
не помещаются в память. Поэтому преимущества загрузки 2х каналов памяти - это не очень полезный
кейс для DBMS как таковой. Что ты собрался так много процессить? Методы сеток?

Обычно пользователю интересна какая-то узкая часть данных. Которую легко индексировать
или материализовывать. Или следуя лучшим традициям CQRS - трекать отдельно вообще от
основного хранилища фактов.

Вот эта штука

select sum(a), avg(b), min(c) from tab


это вообще не OLTP. Это дата-аналитическая кверя. Ее исполняют 1 раз для исторического периода.
Для 2019 года например и кладут ее в отдельную табличку или OLAP кубик навсегда. Там она и лежит
и никогда не меняется. Вот это правильный паттерн.
3 апр 20, 11:49    [22110397]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6360
bluestreak
Я спросонья пытаюсь понять что вы имели ввиду 😀 Производительность точно такая же на 64 бит целых числах.

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

выход только один - "правильно считать агрегаты по таким типам", в учебниках по расчётам есть описания как это делать
3 апр 20, 13:34    [22110498]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

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

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

Картинка с другого сайта.

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

Картинка с другого сайта.

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

К сообщению приложен файл. Размер - 20Kb
3 апр 20, 15:37    [22110564]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton
bluestreak

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

Смотри. Системы на базе in-memory имеют узкое применение. В общем случае продуктовые данные
не помещаются в память. Поэтому преимущества загрузки 2х каналов памяти - это не очень полезный
кейс для DBMS как таковой. Что ты собрался так много процессить? Методы сеток?

Обычно пользователю интересна какая-то узкая часть данных. Которую легко индексировать
или материализовывать. Или следуя лучшим традициям CQRS - трекать отдельно вообще от
основного хранилища фактов.

Вот эта штука

select sum(a), avg(b), min(c) from tab


это вообще не OLTP. Это дата-аналитическая кверя. Ее исполняют 1 раз для исторического периода.
Для 2019 года например и кладут ее в отдельную табличку или OLAP кубик навсегда. Там она и лежит
и никогда не меняется. Вот это правильный паттерн.


Я согласен, можно посчитать и сохранить. Но смысл не в этом. Мы делаем большой объём данных интерактивными. Конечно постепенно. Польза от суммирования всей таблицу не велика, но это демонстрирует потенциальные возможности которыми могут обладать будущие субд. Это поможет сократить необходимость в индексах, материальных въю и других костылей, которые нужно постоянно поддерживать. Дальше векторные и параллельные поиски, сравнения, копирование, индексы и тд. И вообще все что захочешь.
3 апр 20, 15:56    [22110572]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6360
bluestreak,

а вот теорию почитать? или я вам должен данные предоставить где будет 20% как за здрасти?
3 апр 20, 16:20    [22110591]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
kealon(Ruslan)
bluestreak,

а вот теорию почитать? или я вам должен данные предоставить где будет 20% как за здрасти?


Да, пожалуйста. Свои аргументы нужно подкреплять фактами.
3 апр 20, 16:24    [22110592]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6360
bluestreak,

для ленивых ;-), я не занимаюсь благотворительностью

Сообщение было отредактировано: 3 апр 20, 16:30
3 апр 20, 16:30    [22110600]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
kealon(Ruslan)
bluestreak,

для ленивых ;-), я не занимаюсь благотворительностью


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

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

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

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

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

https://news.ycombinator.com/news
8 апр 20, 00:50    [22112585]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6360
bluestreak,

Лирика меня мало интересует, я уже давно обрёл защитный уровень цинизма. Тем более, я знаю как высасывают такие новости.
Выискивать вам что-то конкретное - это труд, профит от которого приближается к 0, так как даже чего-то нового я не узнаю, я уж не говорю о каком-то материальном выхлопе.

Логических оптимизаций в вашем продукте я особо не вижу, лопатить машинные оптимизации не самый большой скил, один человек на этом поле не воин.
Советую кстати посмотреть в либы того же интела и использовать их по возмоности, там много что сделано для машинных оптимизаций. Если вы хапните их внимание это уже будет очень большой профит вам.

PS:
avg(( x-avg(x))*(x-avg(x))) = avg( x^2 -2 x * avg(x) + avg(x)^2) = avg(x^2) - 2 avg(x)^2 + avg(x)^2 = avg(x^2) - avg(x)^2
8 апр 20, 09:18    [22112637]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
kealon(Ruslan)
bluestreak,

Лирика меня мало интересует, я уже давно обрёл защитный уровень цинизма. Тем более, я знаю как высасывают такие новости.
Выискивать вам что-то конкретное - это труд, профит от которого приближается к 0, так как даже чего-то нового я не узнаю, я уж не говорю о каком-то материальном выхлопе.

Логических оптимизаций в вашем продукте я особо не вижу, лопатить машинные оптимизации не самый большой скил, один человек на этом поле не воин.
Советую кстати посмотреть в либы того же интела и использовать их по возмоности, там много что сделано для машинных оптимизаций. Если вы хапните их внимание это уже будет очень большой профит вам.

PS:
avg(( x-avg(x))*(x-avg(x))) = avg( x^2 -2 x * avg(x) + avg(x)^2) = avg(x^2) - 2 avg(x)^2 + avg(x)^2 = avg(x^2) - avg(x)^2



Хорошо, спасибо за информацию. Это все похоже сводится к https://en.m.wikipedia.org/wiki/Kahan_summation_algorithm мне вот не сложно за 0 поделится если я нужной информацией владею.
8 апр 20, 19:42    [22113059]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
kealon(Ruslan)
bluestreak,

для ленивых ;-), я не занимаюсь благотворительностью


kealon(Ruslan)
bluestreak,

Лирика меня мало интересует, я уже давно обрёл защитный уровень цинизма. Тем более, я знаю как высасывают такие новости.
Выискивать вам что-то конкретное - это труд, профит от которого приближается к 0, так как даже чего-то нового я не узнаю, я уж не говорю о каком-то материальном выхлопе.

ты такой крутой парень

кек
8 апр 20, 19:48    [22113062]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6360
Бумбараш
ты такой крутой парень

кек
скажем так, я не настолько крут что бы заниматься благотворительностью
т.е. мне есть на что потратить и деньги и время

Сообщение было отредактировано: 8 апр 20, 20:20
8 апр 20, 20:20    [22113081]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Руслан это ты так хитро дисперсию посчитал?
8 апр 20, 21:22    [22113143]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6360
mayton,

она самая
идея не моя, известная формула из методичек
8 апр 20, 23:56    [22113239]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Красиво.

avg(x^2) - avg(x)^2


Это по сути ответ на вопрос как в map-reduce считать всякие центральные моменты.

Надо-б себе записать чтоб не забыть.
9 апр 20, 00:13    [22113245]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6360
mayton,

зачем её запоминать, она ж элементарно выводится для многих агрегатов, главное принцип запомнить

вот это 22110498 только напрягает очень сильно, полученная формула менее устойчива к накоплению ошибок на fpu, чем исходная
9 апр 20, 09:36    [22113309]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
А если резать выборку на под-выборки? И применять кусочно?
9 апр 20, 10:49    [22113347]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Время поделиться новой информацией:

Добавил две дополнительные функции: ksum() — kahan и nsum() — neumaier. Последняя более точная сумма. Все три суммы, sum(), ksum() и nsum() выполняются с примерно одинаковой скоростью: 409мс, 411мс и 414мс на 1.6 миллиардов 64бит double значениях.(dell xps15 7590 ноут)

Это все на master пока, можно попробовать если есть желание. https://github.com/questdb/questdb

Проблема остаётся все той же: пропускная способность памяти.

Сообщение было отредактировано: 30 апр 20, 00:17
30 апр 20, 00:16    [22125452]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
bluestreak
Проблема остаётся все той же: пропускная способность памяти.

30 апр 20, 13:45    [22125703]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
mayton
bluestreak
Проблема остаётся все той же: пропускная способность памяти.



Это не аксиома конечно. Я думаю по этому Руслан был настроен крайне скептически.

Мы прогнали clickhouse на миллиарде. У них тоже есть Кахан. Там наивная сумма 275мс, кахан — 850мс. То есть не в память упёрся. У нас 245мс наивно и 250мс - кахан.


Постгрес — 2 минуты 🧐
30 апр 20, 23:57    [22126019]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Ну вы даёте блин. Это ж системы разного класса. Postgres - классическая дисковая.
С полным набором фич ACID. И даже если вы ее поставите поверх SSD - она по прежнему
будет применять весь стек технологий для работы с tuples, 8k-pages e.t.c. И data-rows
будет писать с атрибутами версионности и хрен выключишь эту механику.

Нельзя так сравнивать. А-то побегут выбрасывать свой PG и заменять его на ваш "ФВМяс".
4 май 20, 16:09    [22127270]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Добрый вечер, мы вот запустили сервер, на котором можно попробовать QuestDB. Там таблица на 1.6 миллиард записей и примеры запросов. Вы так же можете написать произвольные запросы. Не все конечно оптимально, но попробуйте и поделитесь предложениями


http://try.questdb.io:9000
26 июн 20, 18:00    [22157935]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
bluestreak
Member

Откуда:
Сообщений: 108
https://techcrunch.com/2020/07/02/questdb-nabs-2-3m-seed-to-build-open-source-time-series-database/
2 июл 20, 17:26    [22161082]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2913
bluestreak,

круто
2 июл 20, 18:58    [22161135]     Ответить | Цитировать Сообщить модератору
 Re: QuestDB - новая СУБД для хранения time series данных  [new]
ptr128
Member

Откуда: Moscow
Сообщений: 888
bluestreak

Инкрементальные запросы вытекают из предположения что данные на изменяются. За исходный результат берётся не 0 а результат предидущего запроса.

Например ‘select location, avg(temp) where timestamp = ‘2019-12’

А если нужна статистика? Например, тот же PostgreSQL PERCENTILE_CONT()?
5 янв 21, 13:14    [22258901]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8 9 10      [все]
Все форумы / Сравнение СУБД Ответить