LINUX.ORG.RU

time series database / база данных для временных рядов

 , , , ,


0

0

У кого есть практический опыт использования баз данных для временных рядов? Задача - обрабатывать финансовые данные, которые хранятся в формате ohlc + теги на каждый timestamp, временные интервалы произвольные и не обязательно регулярные. Рассматриваю несколько вариантов.

TimescaleDB (расширение PostgreSQL), InfluxDB (язык выглядит неплохо, хоть не-SQL и несколько другая модель обработки запросов, есть уже какие-то написанные батарейки, но и самому их написать на SQL не большая проблема), OpenTSDB (пишут, что скоростуха сумасшедшая для вставки данных, хотя для меня это не является критичным) - данные будут относительно редко добавляться и не в сумасшедших масштабах (раз в секунду несколько тысяч записей, стартовый размер самой базы пару сотен гиг), в основном предполагается выборка и фильтрация для последующего анализа и построения графиков.

Пока что база будет находиться на vps, но в дальнейшем, возможно, необходимо будет перенести в облако, не уверен, что в облаке для PostgreSQL можно будет поставить свои расширения :) Как я понимаю, у первых двух баз есть платные версии с расширенной ф-циональностью и возможностью размещения в облаке. На сайте прайсов не увидел, надо отправлять запрос. OpenTSDB вроде как полностью бесплатная (GPL-v3), можно запускаться в облаках с Hadoop / HBase?

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

Если консистентность и транзакции тебе не нужны, то я бы посмотрел еще в сторону кассандры, хотя там и жаба

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)

Если что, джойнов там тоже нет.

dave ★★★★★
()

скоростуха сумасшедшая для вставки данных, хотя для меня это не является критичным

Вся эта петрушка с time series db затевается исключительно для того, чтобы не тупить на вставке и успевать всасывать толстый поток данных с датчиков и т.п. реал-тайм ситуаций. Если вставка тебе не критична, то совершенно пофиг, бери что хочешь. Обычный sql без всяких прибамбасов вполне будет норм и даже удобнее во всех смыслах.

no-such-file ★★★★★
()

Задача - обрабатывать финансовые данные, которые хранятся в формате ohlc + теги на каждый timestamp, временные интервалы произвольные и не обязательно регулярные.

Сколько в секунду?

AnDoR ★★★★★
()
Ответ на: комментарий от no-such-file

Вся эта петрушка с time series db затевается исключительно для того, чтобы не тупить на вставке

Не только, есть много удобств на уровне движка, спецфункции, возможность делать или не делать JOIN, поддержка / неподдержка SQL. К примеру для моих задач за сутки можно вставить полляма записей, первичный датасет куда вставлять пусть будет ~200 млн записей уже. На мой вкус даже на таких объемах оно может прилично подтормаживать на вставку. Ну и хотелось бы каких-то удобных искоробочных методов и оптимизаций.

alienclaster ★★★
() автор топика
Ответ на: комментарий от no-such-file

Мне пока вот эта штука кажется наиболее симпатичной:

TimescaleDB (расширение PostgreSQL)

alienclaster ★★★
() автор топика
Ответ на: комментарий от maxcom

Тоже рассматриваю, как вариант. Есть опыт работы с ней?

alienclaster ★★★
() автор топика
Ответ на: комментарий от alienclaster

много удобств на уровне движка

Например что там есть такое, что нельзя сделать в SQL? Наоборот там по сравнению с SQL много неудобств.

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

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

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от AnDoR

ClickHouse уже советовали?

Третьим будешь? :) Советовали, но никто так и не рассказал свои впечатления от реальной работы с ним. Какие там, например, преимущества перед перечисленными в стартовом посте системами?

alienclaster ★★★
() автор топика
Ответ на: комментарий от alienclaster

Какие там, например, преимущества перед перечисленными в стартовом посте системами?

По сравнению с PostgreSQL: 1) Жрет меньше места на диске 2) Быстрее делает запросы с group by 3) Имеет набор встроенных функций для «приблизительных» вычислений group by, но за меньшее время 4) Хуже с разными UI для копания в базе.

Norgat ★★★★★
()
Ответ на: комментарий от AnDoR

Я его тыкал в праздники. Ну такое, та же Metabase лучше на мой вкус.

Графана да, неплоха, согласен.

Norgat ★★★★★
()
Последнее исправление: Norgat (всего исправлений: 1)

Ещё для полноты коллекции: Prometheus ©.

quickquest ★★★★★
()
Ответ на: комментарий от alienclaster

Это при селекте функция считает не по всем значения которые в селекте есть, а только по некоторой выборке из него. Выборка строится не наобум, на сколько я помню, а по таким правилам, чтобы с точки зрения тервера, полученное значение было близко к тому, что будет при полном подсчете. Почитай документацию CH для подробностей.

Norgat ★★★★★
()
Ответ на: комментарий от alienclaster

КХ самый быстрый и самый простой относительно перечисленного. Особенно если не надо репликации таблиц (потому что она слегка через ж..кипер делается).

Ну и транзакционности нет. Если не жалко потерять что-то, вполне.

stave ★★★★★
()
Ответ на: комментарий от stave

И пара тысяч в секунду - это вполне для него. Мы пытались около больше миллиона, вот там было так себе. Хотя оно так у всех.

stave ★★★★★
()

В итоге остановился на том, что … попробую все 4 озвученные в топике базы :) Может, потом как-нибудь бенчи выкачу.

alienclaster ★★★
() автор топика

В ТС ничего не сказана про предполагаемый характер запросов.

В качестве «аналитической БД», для произвольных запросов с аналитическим уклоном, лучше всех подойдет ClickHouse. На более-менее серьезном объеме данных клик «порвет» всех остальных.

Если же предполагаются только запросы определенного вида, то нужно смотреть на эти запросы. SQL (с b+tree внутри) тут может выиграть.

Смотреть на кассандру смысла не вижу. Если уж сильно хочется, то Scylla DB.

Deleted
()
Ответ на: комментарий от Deleted

В ТС ничего не сказана про предполагаемый характер запросов. В качестве «аналитической БД», для произвольных запросов с аналитическим уклоном

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

alienclaster ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.