Информация

Дата основания
Местоположение
Россия
Сайт
www.itsumma.ru
Численность
101–200 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 16
timescaledb забыли. Хотя она не отвечает одному требованию: компрессия. Хотя для решения этого ZFS используют.
TSDB, Victoria metrics? Что-то у вас не полный список кандидатов.
Создается впечатление, что статья заказная для ClickHouse. Ну, если не заказная, то с явной симпатией
Не, именно пиарить кх ни у кого цели не было. Но отталкивались в своём обзоре в первую очередь именно от него, о чём в самом начале и написали:)

Цели покрыть весь-весь рынок не ставили, хотелось проверить самые популярные и поддерживаемые решения. Но с радостью ознакомимся и с вариантами, предложенными тут в комментариях, возможно и правда упустили какой-то неогранёный алмаз.
db-engines.com/en/ranking/time+series+dbms

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

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


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


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

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

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

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

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

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

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

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

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

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

Почему не рассматривали Elasticsearch?
Например oss версию, которая бесплатная и под Apache 2.0?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.