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

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

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

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

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

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


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

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

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

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


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


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

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

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

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

Т.е. банальная идея например агрегировать минутки в СУБД, а дни собирать на уровне приложения - уже не очень хорошо выглядит. Для одного года потребуется уже 365 запросов. Тогда проще все вычитать одним запросом и все агрегировать на стороне приложения.

В 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) Разные датчики
Расходомер (скорость потока) + датчик температуры / давления. Нужно получить объем.
Датчики стоят на разных агрегатах и выдают данные с разной периодичностью

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

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

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

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

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