Как мы тестировали несколько баз данных временных рядов

[inv2004]

timescaledb забыли. Хотя она не отвечает одному требованию: компрессия. Хотя для решения этого ZFS используют.

[amarao]

TSDB, Victoria metrics? Что-то у вас не полный список кандидатов.

[4umak]

Не, именно пиарить кх ни у кого цели не было. Но отталкивались в своём обзоре в первую очередь именно от него, о чём в самом начале и написали:)

Цели покрыть весь-весь рынок не ставили, хотелось проверить самые популярные и поддерживаемые решения. Но с радостью ознакомимся и с вариантами, предложенными тут в комментариях, возможно и правда упустили какой-то неогранёный алмаз.

[Siemargl]

db-engines.com/en/ranking/time+series+dbms

Собственно, из вышеприведенных табличек с нерасписанными метриками совсем не очевидно, что Кликхаус, который еще и на 3х нодах лучше, чем МайСиквел.

[valyala]

Было бы интересно посмотреть на результаты VictoriaMetrics для ваших данных. Возможно, вам придется отключить кэширование ответов с помощью опции -search.disableCache на время тестирования, т.к. оно не очень дружит с добавлением данных из прошлого aka back-filling. Если ваш тест пишет данные с текущими timestamp'ами, тогда эта опция не нужна.

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

См. сравнение производительности на наборе данных из бенчмарка tsbs — https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae .

[Civil]

Еще интересно было бы рассмотреть ScyllaDB как альтернативу Cassandra.

[aleks_raiden]

еще бы SiriDB попробоватью.

Сам решаю сейчас похожую задачу (финансовые данные) — пока Victoriametrics рулит.

[mnv]

На чем в итоге остановились и какие впечатления от Victoriametrics?

[yoshka]

На InfluxDB народ жалуется на неожиданные проблемы производительности и возможность потерять данные на версии 1.х. При этом ведется разработка версии 2.0, но она еще альфа, такую в прод ставить страшно. ClickHouse в этом смысле предсказуемее.

[inv2004]

Не смотря, на то что мне нравится CH, но всё же очень смущают результаты тестирования:

1) ClickHouse на трёх нодах сравнивается с mysql (и influx) на одной?
2) При этом по выборке сливает mysql? — удивительно. Получается mysql имеет огромные скорости на timeseries? Неожиданно и странно, тем более что много тестов говорят об обратном. Но может быть я чего-то не понял в этом тесте.

[fessmage]

Может под OLAP данные не менялись, и в тот же кликхаус данные писались также как в mysql — в одной строке одна метрика.
По идее в этом случае нужно писать в одну строку — все метрики из одного источника за один timestamp, по колонкам.
eapotapov, как было?

[eapotapov]

Да, хороший подход, нативный, и для прометеуса, и для кликхауса.

Но у нас количество метрик с одного источника — от 4 штук до нескольких сотен, и большая часть индивидуальна для конкретного заказчика.
И поскольку мы тестировали, в первую очередь, для себя и условием было минимум переписывания (а тем более — перепроектирования), то таблицы делали совместимыми с нашей текущей архитектурой с одним столбцом значений.

[inv2004]

всё равно не очень понятно. Может быть такие показатели из-за того, что из mysql вытаскивались только последние значения? А какая-то аггрегация по бОльшему количеству данных имела бы другой результат.

[fessmage]

Вот видимо потому и цифры у mysql и clickhouse похожие, что не используется преимущества из OLAP модели.

[bocharovf]

Почему не рассматривали Elasticsearch?
Например oss версию, которая бесплатная и под Apache 2.0?