Comments 41
Вывод у вас полностью верный.
От себя могу добавить — при работе с любой tsdb забудьте про запросы SELECT * FROM. Всегда используйте агрегирующие функции. Если вам нужны все данные по всем точкам с сортировкой не по времени — то вам не tsdb.
Еще лучше всегда указывать нужный промежуток времени в запросе — у инфлюкса ряды партиционируются по времени.
От себя могу добавить — при работе с любой tsdb забудьте про запросы SELECT * FROM. Всегда используйте агрегирующие функции. Если вам нужны все данные по всем точкам с сортировкой не по времени — то вам не tsdb.
Еще лучше всегда указывать нужный промежуток времени в запросе — у инфлюкса ряды партиционируются по времени.
Тем не менее, у инфлюкса есть и преимущества (перед тем же кликхаусом, например) — опыт показал, что при хранении большого количества (несколько сотен на таблицу) метрик InfluxDB выигрывает благодаря двум основным причинам:
- Пустые значения не хранятся. То есть, если одна метрика (например, данные по одному датчику) приходят условно 10 раз в секунду, а другая — раз в минуту, то во второй колонке в отсутствующие моменты времени ничего нет (даже NULL). Поэтому размер базы довольно сильно сокращается.
- Не нужно создавать схему базы данных. Это особенно хорошо, когда данные приходят в формате
<время> - <название метрики> - <значение метрики>, причем заранее может быть неизвестно, сколько всего метрик и как они называются (и какой у них тип данных). В Clickhouse в таких случаях нужно каждый раз создавать строку и заполнять все отсутствующие значения NULL-ами (а они там появились только сравнительно недавно), не говоря уже о том, что приходится лишний раз проходить по набору данных (хорошо еще, если они исторические, а не в реальном времени приходят), чтобы определить набор колонок и их типы.
1. Полностью согласен. Очень удобно для timeseries
2. Вы чуть лукавите. В Кликхаусе NULL при инсерте не обязательны. Но вручную поддерживать схему нужно и это очень муторно. Автоматические ALTER TABLE что бы добавить столбец или изменить индекс (((( — в инфлюксе схема очень гибкая.
Лично мое мнение influxdb — не production-ready для важных данных. Уже больше года использую как хранилище точек мониторинга. В нем только те данные которые можно потерять без особых проблем.
2. Вы чуть лукавите. В Кликхаусе NULL при инсерте не обязательны. Но вручную поддерживать схему нужно и это очень муторно. Автоматические ALTER TABLE что бы добавить столбец или изменить индекс (((( — в инфлюксе схема очень гибкая.
Лично мое мнение influxdb — не production-ready для важных данных. Уже больше года использую как хранилище точек мониторинга. В нем только те данные которые можно потерять без особых проблем.
1. В клике одинаковые значения в партах столбца по идее пожмутся в «почти ничего».
2. Если данные динамические, с документами проще конечно.
Самое простое, если <название метрики> немного, то можно насоздавать пачку столбцов.
Можно хитрее. Столбец для каждого типа данных и включить в ключ партиции <название метрики>, что бы хорошо пожалось и разложилось на диске.
2. Если данные динамические, с документами проще конечно.
Самое простое, если <название метрики> немного, то можно насоздавать пачку столбцов.
Можно хитрее. Столбец для каждого типа данных и включить в ключ партиции <название метрики>, что бы хорошо пожалось и разложилось на диске.
Clickhouse еще можно посмотреть
www.altinity.com/blog/clickhouse-for-time-series
www.altinity.com/blog/clickhouse-for-time-series
Это вы ещё мясцо не потрогали. А мясцо звучит так: комбинаторный взрыв в continious queries. Если вы используете их для классического rrd, то записи вида (из документации):
CREATE CONTINUOUS QUERY "cq_basic_br" ON "transportation"
BEGIN
SELECT mean(*) INTO "downsampled_transportation"."autogen".:MEASUREMENT FROM /.*/ GROUP BY time(30m),*
ENDто вас ждёт Ньютон со своим биномом и Декарт со своим произведением. Вам перемножат всех fields у всех measurement на все значения tags в базе. Если у вас десять measurement, в каждой из которых 5 полей и 3 тега с 100 значениями у каждого, то вас ждёт...
3*100*5*10 = 1500 пустых групп для каждого отсчёта. После чего пустое выкинут и оставшееся запишут. Если у вас хотя бы миллион точек, то ваши 1.5ккк групп за минуту может и переварят. А вот когда вам кто-то подпихнёт ещё одну measurement с десятком полей и тегом с десятком значений, то получившееся 150 миллиардов — не переварят никогда. И вам уронят influx oom'ом. А потом systemd его перезапустит и influx продолжит работать. И он у вас будет падать, терять данные, флапать мониторингом (если тот будет успевать режим "упал-отжался"), и вы будете недоумевать, что происходит.
А происходит феерическая архитектурная фигня (ФАФ), бороться с которыми можно только с помощью костылей и подпорок.
Решение какое? Использовать всё-таки инфлакс? Или забить на него, как на неудачное решение? Или ограничиться подмножеством его функций?
Так как производительность influx на чтение совсем никуда не годится, для основных данных попробую использовать Timescale. Агрегация по временному промежутку там есть, а continuous queries заменяются на запуск запросов SELECT INTO по cron.
Метрики пока останутся в influx, чтение нужно только для администратора.
Метрики пока останутся в influx, чтение нужно только для администратора.
Timescale будет занимать до 30 раз больше места на диске чем influxdb.
Они там со сжатием походу совсем не заморачивались, автор в комментах просто рекомендует использовать специальную файловую систему, которая всё будет сжимать сама. В общем не рекомендую.
Рекомендую посмотреть в сторону clickhouse.
Я настрадался с influx так, что уже даже серверные метрики теперь храню в кликхаусе.
Простой udp-сервер в 100 строк кода притворяется influxdb, ловит метрики от telegraf и сохраняет их в кликхаус. Работать с ним приятней, данные на диске занимают меньше.
Это я вдохновился приложением коллег, которое притворяется elasticsearch, принимает по http json-запрос и сохраняет все данные в кликхаус. Там тоже можно в 100 строк кода уложиться.
Они там со сжатием походу совсем не заморачивались, автор в комментах просто рекомендует использовать специальную файловую систему, которая всё будет сжимать сама. В общем не рекомендую.
Рекомендую посмотреть в сторону clickhouse.
Я настрадался с influx так, что уже даже серверные метрики теперь храню в кликхаусе.
Простой udp-сервер в 100 строк кода притворяется influxdb, ловит метрики от telegraf и сохраняет их в кликхаус. Работать с ним приятней, данные на диске занимают меньше.
Это я вдохновился приложением коллег, которое притворяется elasticsearch, принимает по http json-запрос и сохраняет все данные в кликхаус. Там тоже можно в 100 строк кода уложиться.
Спасибо.
По поводу размера БД: в моем случае это не критично, данных не много, рост полностью предсказуем. Cardinality на текущий момент — 66 и не думаю, что в будущем значительно изменится. Да и Postgresql — хороший фундамент, как мне кажется.
Выше уже предлагали присмотреться к clickhouse, немного полистал доку. В глаза бросилось то, что она изначально позиционируется как бд для аналитических запросов и редкого чтения. В моем случае это критично, хоть и указанные характеристики гораздо лучше influx.
Вполне возможно, что я просто ем кактус с tsdb и нужно вернуться к велосипедам и реляционным бд.
Вероятно, что КХ лучше подходит для bulk записей. В этом основной камень преткновения.
Чисто реляционные — не лучший выбор, т.к. у вас постоянно идет прореживание записей, т.е. заранее можно примерно оценить сколько «слотов» нужно и аллоцировать под них место и структуры. Именно поэтому tsdb и появились — более оптимальная работа именно с определенными структурами.
Чисто реляционные — не лучший выбор, т.к. у вас постоянно идет прореживание записей, т.е. заранее можно примерно оценить сколько «слотов» нужно и аллоцировать под них место и структуры. Именно поэтому tsdb и появились — более оптимальная работа именно с определенными структурами.
Простой udp-сервер в 100 строк кода притворяется influxdb, ловит метрики от telegraf и сохраняет их в кликхаус. Работать с ним приятней, данные на диске занимают меньше.
а зачем, если можно поднять графит? А телеграф в него умеет напрямую?
Зачем мне графит если кликхаус не просто современнее и навороченнее, а сильно эффективнее.
Я говорю графит — и подразумеваю стек от lomik (не graphite-python over whisper, а graphite @CH и пускай запись данных будет головной болью графита, а не моего прокси или агента мониторинга).
В указанной мною статье в графите от ломика не было тегов. Авторы статьи очень сильно надеялись, что их поддержка появится в ближайшее время. Прошёл год и они появились.
Уж лучше моей головной болью будет 100 строк моего кода, чем годы ожиданий пока сделают, то что мне нужно.
К тому же мне не нравится структура бд в графите от ломика. Эта гибкость дорого обходится. Она не имеет смысла для серверных метрик (где структура может быть сгенерирована за первых пару минут анализа метрик). Гораздо эффективнее создать один раз нужную колонку (конечно автоматически, а не в ручную) и складировать метрики в неё, тогда сжатие на уровне колонки будет гораздо эффективнее, чем создать две колонки ключ и значение и пихать в них всё подряд.
Можно сравнить "универсальную схему" и мою схему, которая создаётся динамически по мере надобности.
При запросе на cpu у меня будут доставаться с диска данные только по cpu, а не все данные, а потом отфильтровываться cpu.
Для моего кейса мне не нужен графит, мне достаточно кликхауса и 100 строк кода, которые автоматически добавляют новые колонки.
Уж лучше моей головной болью будет 100 строк моего кода, чем годы ожиданий пока сделают, то что мне нужно.
К тому же мне не нравится структура бд в графите от ломика. Эта гибкость дорого обходится. Она не имеет смысла для серверных метрик (где структура может быть сгенерирована за первых пару минут анализа метрик). Гораздо эффективнее создать один раз нужную колонку (конечно автоматически, а не в ручную) и складировать метрики в неё, тогда сжатие на уровне колонки будет гораздо эффективнее, чем создать две колонки ключ и значение и пихать в них всё подряд.
Можно сравнить "универсальную схему" и мою схему, которая создаётся динамически по мере надобности.
При запросе на cpu у меня будут доставаться с диска данные только по cpu, а не все данные, а потом отфильтровываться cpu.
Для моего кейса мне не нужен графит, мне достаточно кликхауса и 100 строк кода, которые автоматически добавляют новые колонки.
Спаибсо за комментарии.
Немного замечаний.
1. А чего сразу телеграфом не слать в КХ? Достаточно output plugin написать. Понимаю, что форк, все дела, но возможно, что и примут патч с этим output plugin'ом в апстрим в одной из следующих версий (вообще ребята из телеграф показались достаточно адекватными в этом плане).
2. а чем смотреть метрики? В графане визуализируете?
3. преимущество стека от ломика в том, что туда мойру можно прикрутить и получить нормальный алертинг. А как Вы предлагаете алертинг делать? Через стороннее решение? Графана? Фу-фу-фу.
4. повторюсь, что насколько я помню, что КХ хорош только для батчевых записей. Телеграф же шлет можно сказать — единичные метрики. Насколько хорошо это будет работать? Насколько я помню, стек от ломика оптимизирует записи в памяти и шлет их пачками в КХ, что обеспечивает эффективность на запись.
5. Касательно тезиса, что схема лучше динамическая, чем универсальная — ну, мы же понимаем, что есть несколько нюансов с метриками. Первая — что обычно они только добавляются (т.е. типов метрик становится больше). Вторая — что обычно количество наблюдаемых объектов (узлов, сервисов и т.п.) тоже увеличивается. Третья — старые метрики обычно нужны с ретеншеном и разрежением частоты с агрегацией. Если ретеншен, положим, можно сделать откидываем партиций в КХ, то как разрежение делать? Эффективно? Или речь про достаточно маленькое хранилище, для которого эта проблема в принципе не проявится? Четверое — сжатие при использовании унивесарльной схемы для каждой из таблиц (т.е. НЕ УНИВЕРСАЛЬНОЙ схемы для ВСЕХ метрик) — будет больше, при не очень большой потере скорости. С другой стороны, метрики обычно нужны только для оперативного мониторинга, а скорость доступа к историческим данным нужна ± постоянная (но можно, что не слишком высокая), в не зависимости от их датировки. Как-то так.
Ну, и как Вы заметили — метрики бывают разные. Вы про «Она не имеет смысла для серверных метрик». А бизнес метрики? Метрики приложений (которые вроде бы еще системные, но не совсем)?
Немного замечаний.
1. А чего сразу телеграфом не слать в КХ? Достаточно output plugin написать. Понимаю, что форк, все дела, но возможно, что и примут патч с этим output plugin'ом в апстрим в одной из следующих версий (вообще ребята из телеграф показались достаточно адекватными в этом плане).
2. а чем смотреть метрики? В графане визуализируете?
3. преимущество стека от ломика в том, что туда мойру можно прикрутить и получить нормальный алертинг. А как Вы предлагаете алертинг делать? Через стороннее решение? Графана? Фу-фу-фу.
4. повторюсь, что насколько я помню, что КХ хорош только для батчевых записей. Телеграф же шлет можно сказать — единичные метрики. Насколько хорошо это будет работать? Насколько я помню, стек от ломика оптимизирует записи в памяти и шлет их пачками в КХ, что обеспечивает эффективность на запись.
5. Касательно тезиса, что схема лучше динамическая, чем универсальная — ну, мы же понимаем, что есть несколько нюансов с метриками. Первая — что обычно они только добавляются (т.е. типов метрик становится больше). Вторая — что обычно количество наблюдаемых объектов (узлов, сервисов и т.п.) тоже увеличивается. Третья — старые метрики обычно нужны с ретеншеном и разрежением частоты с агрегацией. Если ретеншен, положим, можно сделать откидываем партиций в КХ, то как разрежение делать? Эффективно? Или речь про достаточно маленькое хранилище, для которого эта проблема в принципе не проявится? Четверое — сжатие при использовании унивесарльной схемы для каждой из таблиц (т.е. НЕ УНИВЕРСАЛЬНОЙ схемы для ВСЕХ метрик) — будет больше, при не очень большой потере скорости. С другой стороны, метрики обычно нужны только для оперативного мониторинга, а скорость доступа к историческим данным нужна ± постоянная (но можно, что не слишком высокая), в не зависимости от их датировки. Как-то так.
Ну, и как Вы заметили — метрики бывают разные. Вы про «Она не имеет смысла для серверных метрик». А бизнес метрики? Метрики приложений (которые вроде бы еще системные, но не совсем)?
1. думал об этом, но там input plugin от моего коллеги висит в пуллреквестах больше года. Просить его написать в долгий ящик ещё и output plugin у меня пока совести не хватает.
2. графана
3. графана
4. конечно шлю пачками, а не поштучно
5. для мониторинга серверов новые типы метрик добавляются раз в полгода.
Бизнес метрики и метрики приложений я сразу пишу в кликхаус. Не вижу смысла в 2019 году для новых сервисов писать данные в графит, а потом страдать, что подсев на графит очень сложно переезжать на кликхаус, и что сторонняя прослойка, подменяющая графит на кликхаус работает не очень оптимально зато гибко.
В общем напишу ещё раз, что для моих задач это решение работает как надо, и я не претендую на всеобщую универсальность.
Мой посыл первого комментария был в том, что написать приложение, которое будет заменять ваш текущий «инструмент с хранилищем» и сохранять всё в кликхаус — это вовсе не «рокет сайнс», всё самое тяжёлое на себя берёт кликхаус.
2. графана
3. графана
4. конечно шлю пачками, а не поштучно
5. для мониторинга серверов новые типы метрик добавляются раз в полгода.
Бизнес метрики и метрики приложений я сразу пишу в кликхаус. Не вижу смысла в 2019 году для новых сервисов писать данные в графит, а потом страдать, что подсев на графит очень сложно переезжать на кликхаус, и что сторонняя прослойка, подменяющая графит на кликхаус работает не очень оптимально зато гибко.
В общем напишу ещё раз, что для моих задач это решение работает как надо, и я не претендую на всеобщую универсальность.
Мой посыл первого комментария был в том, что написать приложение, которое будет заменять ваш текущий «инструмент с хранилищем» и сохранять всё в кликхаус — это вовсе не «рокет сайнс», всё самое тяжёлое на себя берёт кликхаус.
Позвольте поинтересоваться, как вы алертинг в графане к КХ прикрутить умудрились, если он (драйвер датасорса) и по сей день не является частью самой графаны, а только встроенные драйвера позволяют пользоваться шедулером для алертинга?
Раньше это делалось через костыли, сейчас это работает из коробки начиная с версии 20.1.2.4.
В конфиге нужно указать mysql_port и создать в графане датасурс mysql.
В конфиге нужно указать mysql_port и создать в графане датасурс mysql.
Одна из причин жизни с TICK'ом — очень хороший язык для графаны. У clickhouse'а, например, non_negative_derivative написать можно в запросе?
Я вообще не понимаю целеполагания использования TimeScaleDB. Постгрес? Ну, постгрес. Но это же не значит, что его нужно тащить везде. Действительно для метрик лучше подходит КХ, но еще большой вопрос какие гарантии сохранности данных нужны.
Так что я согласен с morozovsk
Так что я согласен с morozovsk
Текущее решение (решающее проблему комбинаторного взрыва) — использовать per measurement CQ. Никаких звёзд. Дополнительно, надо проявлять гигену в телеграфе и дропать ненужные теги, а так же не собирать что попало (например, отключать per-cpu для cpu, которое добавляет тысячи к комбинаторному множетелю из-за количества cpu на современных системах).
Второе: добавить в мониторинг проверку NRestarts для influxdb.service. Это число увеличивается каждый раз, когда systemd делает «упал-отжался» для сервиса.
Второе: добавить в мониторинг проверку NRestarts для influxdb.service. Это число увеличивается каждый раз, когда systemd делает «упал-отжался» для сервиса.
Сразу перейти на clickhouse. У меня на работе пришлось перейти с influxdb, когда 16Гб памяти перестало хватать для работы с данными всего-навсего за неделю. Требовалось — за пару месяцев минимум, а лучше — за полгода. Сейчас — clickhouse, у которого поставили уже потом 32Гб на всякий случай и таки да, полгода неагрегированных данных.
Но да, есть и свои нюансы, там не совсем тот SQL, к которому все привыкли…
P.S. часть метрик показывается через графану (для которых это имеет смысл), часть — используется для автоматики.
Но да, есть и свои нюансы, там не совсем тот SQL, к которому все привыкли…
P.S. часть метрик показывается через графану (для которых это имеет смысл), часть — используется для автоматики.
Кстати кто юзает influx незабудьте обновиться до 1.7.5 или прописать shared_secret отличный от пустого. А то ваша база открыта для всех желающийх под любым логином.
DEL
PS: Перенёс комментарий в ветку выше
PS: Перенёс комментарий в ветку выше
> В моем случае данные имеют финансовую составляющую и обрабатывать их хотелось бы с высокой точностью.
«Уж сколько раз твердили миру», что для финансовых данных числа с плавающей точкой не годятся — а поскольку чего-то по типу decimal в influxdb нет, то лучшим выбором пока остаются целые числа.
P.S. Конечно, это не значит, что проблемы с точностью нет.
«Уж сколько раз твердили миру», что для финансовых данных числа с плавающей точкой не годятся — а поскольку чего-то по типу decimal в influxdb нет, то лучшим выбором пока остаются целые числа.
P.S. Конечно, это не значит, что проблемы с точностью нет.
что для финансовых данных числа с плавающей точкой не годятся
Это одна из тех фраз, которые слышишь(видишь) в каждой второй статье или книге и которые не имеют никакого отношения к действительности. Финансовые расчеты как правило выполняются с использованием double (binary64 в терминах IEEE 754). Совершенно бессмысленно использовать decimal (decimal64) для всех вычислений. Вы все равно будете получать результат, который будет требовать округления (пример, я хочу посчитать сколько индийских рупий я могу купить на 1000 рублей, курс RUB/INR — 0.91 и результат 1098,901098901 рупий, binary64 и decimal64 могут представить это значение без потери точности, при этом мне придется округлить до 1098,90). При этом операции над decimal64 — дороже чем над binary64, т.к. реализуются программно. Бухгалтерия — другое дело, там использование decimal имеет какой-то смысл.
Как вы себе представляете хранение агрегированных данных для каждой тайм зоны? Знаете ли вы про параметр запроса tz('Europe/Berlin') к примеру? То что вы называете «сдвигом», я не думаю что вы применяете это корректно, ещё и удивляетесь что получается что то не то.
По поводу производительности, то как правильно сказали выше, вы зря используете select *, вам и вправду нужны все точки? Если так — то даже реляционная база даст выше производительность.
Попробуйте select mean(«value»)… Where time > now() — 24h group by time(10m)
В этом случае вернётся среднее value для каждого интервала в 10 минут за последние сутки, это будет 144 точки, если надо меньше — увеличьте group by период.
Вообще то, по факту, этот запрос возвращает абсолютно все что есть, а не за последние сутки.
В любом случае, попробуйте запрос что я дал выше, отрабатывает ли он быстрее?
По поводу производительности, то как правильно сказали выше, вы зря используете select *, вам и вправду нужны все точки? Если так — то даже реляционная база даст выше производительность.
Попробуйте select mean(«value»)… Where time > now() — 24h group by time(10m)
В этом случае вернётся среднее value для каждого интервала в 10 минут за последние сутки, это будет 144 точки, если надо меньше — увеличьте group by период.
SELECT * FROM coins_info WHERE time <= NOW()
Вообще то, по факту, этот запрос возвращает абсолютно все что есть, а не за последние сутки.
В любом случае, попробуйте запрос что я дал выше, отрабатывает ли он быстрее?
Influx узали для мониторинга, это наверное самая прожорливая TSDB что я видел, при этом упать может в любой момент без сохранения данных. да и вообще косяков много, которые как-то плохо лечат.
А что сейчас используете?
Influx пробовали пристроитьта стек в 2016 году для хранения сырых временных рядов. Привлекли continues queries для построения равномерно разреженных рядов. От идеи пришлось отказаться из-за «краевых эффектов». Плюс в то время в инете нашлось много issues на тему просадки производительности influx при росте базы. Решили не рисковать и остаться на проприетарным хранилище трендов
Influx пробовали пристроитьта стек в 2016 году для хранения сырых временных рядов. Привлекли continues queries для построения равномерно разреженных рядов. От идеи пришлось отказаться из-за «краевых эффектов». Плюс в то время в инете нашлось много issues на тему просадки производительности influx при росте базы. Решили не рисковать и остаться на проприетарным хранилище трендов
Забавно, в 2023 influx с огромным отрывом на первом месте.
Починили детские проблемы?
Возможно дело в методике расчета этого рейтинга. Согласно описанию они смотрят на:
количество результатов на запросы в гугл
гугл тренды
количество упоминаний на SO
количество вакансий с упоминанием
количество страниц на linkedin, где в skills указана эта бд
количество твитов с упоминаниями бд
Т.е. вообще ничего про суть технологогии или фичи, только про популярность. Возможно что всё починили и активно пиарятся, а возможно у людей просто пригорает)
Сравнивая Influx и Timescale за период от апреля 2019 до сейчас: первый в рейтинге вырос в 2 раза (17.218 -> 31.257), второй почти в 5 (0.948 -> 4.696).
Sign up to leave a comment.
Гнев, торг и депрессия при работе с InfluxDB