InfluxDB, Prometheus, OpenTSDB. Что выбрать для хранения и анализа метрик?

Максимальная точность по timeseries нужна 1h.
Много фильтров (около 20-30), и очень много различных значений (~1000 набирается суммарно у этих фильтров).
Сейчас все это работает на MongoDB, но количество фильтров растет и количество значений в них, поэтому любые предрасчеты уже не очень спасают.
База с сырыми данными ~ 2ТБ, предрассчитанные(суммируются значения с одними и теми же фильтрами) ~ 100Гб.
Сейчас где-то секунд 30 занимает каждый запрос по фильтрам, работать аналитикам с такими задержками крайне неудобно.
Реалтайм не нужен(для большинства метрик хватит актуальности "за вчера").

Вопрос больше к тем, кто пользуются одной из БД - какие проблемы? Как шустро работает?.
  • Вопрос задан
  • 4697 просмотров
Решения вопроса 1
Не очень понял задачу, попробую объяснить разницу, как я это понимаю из своего опыта:

OpenTSDB:
* работает поверх HBase/Hadoop, для тестов можно запустить в standalone режиме, но будет работать _крайне_ медленно
* timeseries вида timestamp, metricname=val, (tag=val)+ , может хранить только числа (есть batch mode, если нужно несколько пачкой писать)
* объем данных хорошо масштабируется за счет HBase
* сообщество сообщает о тормозах при очень большом количестве (десятки тысяч+) идентификаторов серий -- это имя серии + сочетание тегов
* скорость записи и выборки хорошая: в HBase данные партицируются почасово и читаются только те серии за те периоды, которые нужны
* для масштабирования ставим доп.ноды OpenTSDB за прокси (если упираемся в агрегации), либо ноды HBase (если упираемся в IO)
* процессинг метрик только самый базовый -- downsample, вычисление rate из счетчиков (т.е. производная), аггрегация по тегам (например, среднее "os.cpu" для всех метрик, у которых тег "role=webserver")
* сам язык запросов немного вырвиглазный
* недавно появился https://bosun.org/, который садится перед OpenTSDB и позволяет еще какие-то операции делать
* апстрим разработку ведет довольно неторопливо

InfluxDB:
* ставится в тестовом режиме очень легко (один бинарник)
* пока нестабилен -- за последний год сменилось 2 HTTP API и штук пять вариантов бинарного формата на диске -- это моя самая большая претензия к нему
* timeseries вида db, timestamp, metricname=val, (tag=val)+, т.е. можно логически группировать разные данные. Кажется, можно было хранить текстовые значения.
* язык запросов SQL-подобный
* ребята из Coub говорили, что на запись он качает хорошо, а на чтение тормозит (не знаю, впрочем про какую из версий)
* у них много коннекторов к разным входным форматам (графит, opentsdb, collectd и т.п.)
* довольно динамично развивается

Из известных TSDB есть еще Graphite:
* старый хорошо известный вариант
* питон с модулями, поэтому сложнее в установке, чем influxdb, но проще чем хадуп
* база RRD, т.е. может хранить только данные "за последний год, за последний месяц и за последний час" со своей точностью для каждого периода
* за счет этого данные занимают хорошо предсказуемое и постоянное место на диске
* гигантское количество документации и всяких обвязок в интернете
* серии вида timestamp, metric=val -- тегов и т.п. нет. поэтому группировать, например, одинаковые серии для разных хостов придется под разными именами
* довольно большое (по сравнению с OpenTSDB) количество функций при выборке -- насколько помню, были всякие перцентили, forecastы и т.д.
* с дефолтным хранилищем при большом количестве серий начинает упираться в диск
* масштабируется неважно (подробностей не знаю)
* периодически из сообщества появляются разнообразные хранилища, которые улучшают ситуацию со скоростью и масштабированием

Prometheus не видел.
Еще что-то слышал про druid.io, но тоже ничего о нем не знаю.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы