|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
bluestreak, Код: sql 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 23:45 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
Мне кажется данный предикат Код: sql 1.
вместо точечного соединения вернет нам некий "треугольник" ячеек матрицы на сторонах которой разложены ключи A.Fk, B.Pk. Это КМК опасное соединение и чреватое ... скажем избыточной выборкой. Не уверен в том что это то что мы ищем. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 23:49 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
mayton Это КМК опасное соединение и чреватое ... скажем избыточной выборкой. Опасное.. хм.. опасность в любом соединении ровно одна: сформулировать одно, когда хочешь получить другое. А примеры типа ваших элементарно разруливаются через сочетание lag-а и соединения по between. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 00:20 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
Мне кажется тут LAG/LEAD не подходит. Фактически нам нужен UNION/MERGE двух тайм-серий с последующей группировкой или сжатием по символу. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 00:26 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
softwarer mayton Это КМК опасное соединение и чреватое ... скажем избыточной выборкой. Опасное.. хм.. опасность в любом соединении ровно одна: сформулировать одно, когда хочешь получить другое. А примеры типа ваших элементарно разруливаются через сочетание lag-а и соединения по between. Ну соединения через >= это вариант бесконтрольного cross join со сложностью O(n^2) А про lag — давайте я вам две таблицы по 100м записей подкину а вы их лагом чпокните? А я asof join со своей стороны на моем некудышнем лаптопе? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 00:29 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
mayton Мне кажется тут LAG/LEAD не подходит Мне кажется, Вы поспешили ответить, не дочитав. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 00:31 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
Чпокнуть ... - это не инженерная терминология ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 00:46 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
mayton, коллега вообще разговаривает как И. В. Бунша. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 00:49 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
bluestreak А про lag — давайте я вам две таблицы по 100м записей подкину а вы их лагом чпокните? А я asof join со своей стороны на моем некудышнем лаптопе? Давай подкидывай. Пиши задание что надо сделать. И я подозреваю что 100м записей мы качать не захотим. Нужен генератор. Желательно на каком-то демократичном скрипе (Python) чтоб все желающие могли быстро сгенерить тестовую выборку. И давай твой волшебный скрипт который все это сделает на Quest. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 00:55 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
softwarer mayton, коллега вообще разговаривает как И. В. Бунша. Простите, это филологический форум? Вы может ответите на техническое предложение прежде чем на личности переходить? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 00:57 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
mayton, Завтра подкину, на QuestDB, чтоб ты на конец скачал сегодня фикшу баги и вот русский язык у коллег учу (в словарь за «неонкой» заглядывал) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 01:02 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
bluestreak, это Стругацкие - Сказка о Тройке. Классика. Читать надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 01:08 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
mayton, Можно генерить данные в такой последовательности: — скачай QuestDB 4.0.3 и запусти (есть докер, .sh и .exe) — браузер на HTTP://localhost:9000 Запусти запросы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29.
Содержимое этих таблиц можно скачать выделив название таблицы и нажав иконку «скачать» В QuestDB join выглядит следующим образом: Код: plaintext 1. 2.
Можно select * from в начале приписать но не обязательно. Этот запрос с моей стороны выполняется за 4.6с на лаптопе, возвращает 100 Лимонов записей. Интересно как у тебя получится с лагом ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 21:14 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
Вот более оптимизированный джоин, 0.05с. Разница состоит в том что сервер тратил время на проход до конца курсора (100лимонов) для подсчета записей. В оптимизированном коде число записей берётся из левой таблицы и не вычисляется. В консоли грид виртуализированый, по сути 0.05с это получить первые 1000 записей джоина на клиент. Скачать весь результат это все же 4.6с + сеть. Ну все равно неплохо для интерактивного клиента. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2019, 00:51 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
bluestreak На много быстрее чем influx и timescale. по сравнению с influx человеческий SQL, нормально ошибки репортятся, транзакционность данных, отказоустойчивость, поддержка реляционной модели, те неограниченные joins. Можно залить по influx протоколу а вытащить по postgres По сравнению с timescale, просто быстрее, нагружает сервер меньше, например запрос в questdb выполняется быстрее на одном потоке чем timescale на шести PostgreSQL инфраструктура конечно хорошая, но мы быстрыми темпами догоняем. Можем фич добавить быстро и без бюрократии Залив данных из файлов упрощён - questdb заливает гораздо быстрее и автоматом создаёт таблицу и определяет типы полей. Также размер транзакции не ограничен при этом транзакция остаётся атомичной Мы скоро накрутим incremental запросы, по производительности уничтожим все базы. Раз в 10-100 быстрее будет в зависимости от запроса не, ну может необразованный школьник и хочет "по производительности уничтожить все базы" ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2019, 09:47 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
Ролг Хупин не, ну хочет необразованный школьник и может ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2019, 11:49 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
Насколько эффективно Ваша система будет обрабатывать запросы след. видов Таблички 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.12.2019, 13:35 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
в синтаксисе SELECT ошибся, но суть думаю ясна. JOIN нужен по двум полям: timestamp + key При этом распределение перекошено в сторону key. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2019, 13:37 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
bluestreak/хочет/ необразованный школьник и /может/ Ещё на заре появления in-memory я шутил о БД в регистрах процессора. Миллиарды транзакций в секунду не превзойти никак. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2019, 13:44 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov bluestreak/хочет/ необразованный школьник и /может/ Ещё на заре появления in-memory я шутил о БД в регистрах процессора. Миллиарды транзакций в секунду не превзойти никак. Это все оправдания уважаемый, я объяснял как это работает. Вы после вышеприведённых шагов можете компьютер обесточить и когда включите увидите те же данные и ту же скорость выполнения запросов. Покажите неграмотному школьнику как что вы сделали лучше и правильнее? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2019, 13:54 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
bluestreakВы после вышеприведённых шагов можете компьютер обесточить и когда включите увидите те же данные и ту же скорость выполнения запросов. А ты пробовал? По твоим же словам синхронный сброс буферов ещё не реализован. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2019, 14:03 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
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.12.2019, 14:06 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov bluestreakВы после вышеприведённых шагов можете компьютер обесточить и когда включите увидите те же данные и ту же скорость выполнения запросов. А ты пробовал? По твоим же словам синхронный сброс буферов ещё не реализован. Пробовал. Я не трещу о том что я не делал. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2019, 14:06 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
bluestreakПробовал. Сколько раз? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2019, 14:11 |
|
QuestDB - новая СУБД для хранения time series данных
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov bluestreakПробовал. Сколько раз? Запись на диск ведётся через 16мб страницы. Когда страница заканчивается она демонтируется, что приводит к асинхронному msync(), и создаётся новая страница итд. Дело в том что на ссд 16мб записываются довольно быстро. Данные будут на диске перед тем как вам вэб консоль done напишет. В любом случае если вы не дождавшись завершения insert провод из розетки выдерните то будет либо 0 либо 100м записей, поскольку при открытии QuestDB чинит файлы и отматывает побитые транзакции. Достаточное количество пробовал, е даже несколько HDD убил такими экспериментами. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2019, 14:20 |
|
|
start [/forum/topic.php?fid=35&msg=39899698&tid=1552167]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
27ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 144ms |
0 / 0 |