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