Комментарии
16
timescaledb забыли. Хотя она не отвечает одному требованию: компрессия. Хотя для решения этого ZFS используют.
TSDB, Victoria metrics? Что-то у вас не полный список кандидатов.
Создается впечатление, что статья заказная для ClickHouse. Ну, если не заказная, то с явной симпатией
Не, именно пиарить кх ни у кого цели не было. Но отталкивались в своём обзоре в первую очередь именно от него, о чём в самом начале и написали:)
Цели покрыть весь-весь рынок не ставили, хотелось проверить самые популярные и поддерживаемые решения. Но с радостью ознакомимся и с вариантами, предложенными тут в комментариях, возможно и правда упустили какой-то неогранёный алмаз.
Цели покрыть весь-весь рынок не ставили, хотелось проверить самые популярные и поддерживаемые решения. Но с радостью ознакомимся и с вариантами, предложенными тут в комментариях, возможно и правда упустили какой-то неогранёный алмаз.
db-engines.com/en/ranking/time+series+dbms
Собственно, из вышеприведенных табличек с нерасписанными метриками совсем не очевидно, что Кликхаус, который еще и на 3х нодах лучше, чем МайСиквел.
Собственно, из вышеприведенных табличек с нерасписанными метриками совсем не очевидно, что Кликхаус, который еще и на 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 рулит.
На чем в итоге остановились и какие впечатления от Victoriametrics?
На InfluxDB народ жалуется на неожиданные проблемы производительности и возможность потерять данные на версии 1.х. При этом ведется разработка версии 2.0, но она еще альфа, такую в прод ставить страшно. ClickHouse в этом смысле предсказуемее.
Не смотря, на то что мне нравится CH, но всё же очень смущают результаты тестирования:
1) ClickHouse на трёх нодах сравнивается с mysql (и influx) на одной?
2) При этом по выборке сливает mysql? — удивительно. Получается mysql имеет огромные скорости на timeseries? Неожиданно и странно, тем более что много тестов говорят об обратном. Но может быть я чего-то не понял в этом тесте.
1) ClickHouse на трёх нодах сравнивается с mysql (и influx) на одной?
2) При этом по выборке сливает mysql? — удивительно. Получается mysql имеет огромные скорости на timeseries? Неожиданно и странно, тем более что много тестов говорят об обратном. Но может быть я чего-то не понял в этом тесте.
Может под OLAP данные не менялись, и в тот же кликхаус данные писались также как в mysql — в одной строке одна метрика.
По идее в этом случае нужно писать в одну строку — все метрики из одного источника за один timestamp, по колонкам.
eapotapov, как было?
Да, хороший подход, нативный, и для прометеуса, и для кликхауса.
Но у нас количество метрик с одного источника — от 4 штук до нескольких сотен, и большая часть индивидуальна для конкретного заказчика.
И поскольку мы тестировали, в первую очередь, для себя и условием было минимум переписывания (а тем более — перепроектирования), то таблицы делали совместимыми с нашей текущей архитектурой с одним столбцом значений.
Но у нас количество метрик с одного источника — от 4 штук до нескольких сотен, и большая часть индивидуальна для конкретного заказчика.
И поскольку мы тестировали, в первую очередь, для себя и условием было минимум переписывания (а тем более — перепроектирования), то таблицы делали совместимыми с нашей текущей архитектурой с одним столбцом значений.
всё равно не очень понятно. Может быть такие показатели из-за того, что из mysql вытаскивались только последние значения? А какая-то аггрегация по бОльшему количеству данных имела бы другой результат.
Вот видимо потому и цифры у mysql и clickhouse похожие, что не используется преимущества из OLAP модели.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Как мы тестировали несколько баз данных временных рядов