Usecases: InfluxDB против Prometheus [закрыто]
после Прометей веб-страницы одним из основных различий между Prometheus и InfluxDB является usecase: в то время как Prometheus хранит временные ряды только InfluxDB лучше ориентирован на хранение отдельных событий. Поскольку была проделана большая работа над двигателем хранения InfluxDB, я задаюсь вопросом, верно ли это.
Я хочу настроить базу данных временных рядов и, кроме модели push / push (и, вероятно, разницы в производительности), я не вижу большой вещи, которая разделяет оба проекта. Может кто-нибудь объяснить разницу в использовании?
4 ответов
генеральный директор и разработчик InfluxDB здесь. Следующая версия InfluxDB (0.9.5)будет иметь наш новый механизм хранения. С помощью этого движка мы сможем эффективно хранить либо отдельные данные о событиях, либо регулярно отбираемые серии. т. е. нерегулярные и регулярные временные ряды.
InfluxDB поддерживает типы данных int64, float64, bool и string, используя различные схемы сжатия для каждого из них. Prometheus поддерживает только float64.
для сжатия версия 0.9.5 будет иметь сжатие соревноваться с Прометеем. В некоторых случаях мы увидим лучшие результаты, так как мы меняем сжатия метки на основе того, что мы видим. Наилучший сценарий - это регулярная серия, отобранная с точными интервалами. В них по умолчанию мы можем сжимать временные метки точек 1k как время начала 8 байтов, Дельта (закодированный зигзаг) и счетчик (также закодированный зигзаг).
в зависимости от формы данных, которые мы видели
YMMV на основе временные метки, тип данных и форма данных. Случайные поплавки с наносекундными метками времени с большими переменными дельтами были бы худшими, например.
переменная точность в метках времени-еще одна функция, которую имеет InfluxDB. Он может представлять секунды, миллисекунды, микросекунды, наносекунды или шкале времени. Прометей фиксируется в миллисекундах.
другое отличие заключается в том, что записи в InfluxDB долговечны после успешного ответа, отправленного клиенту. Буферы Prometheus записываются в память и по умолчанию сбрасываются каждые 5 минут, что открывает окно потенциальной потери данных.
мы надеемся, что после выпуска 0.9.5 InfluxDB это будет хорошим выбором для пользователей Prometheus для использования в качестве долгосрочного хранилища метрик (в сочетании с Prometheus). Я уверен, что поддержка уже в Prometheus, но до тех пор, пока релиз 0.9.5 не упадет, он может быть немного скалистым. Очевидно, нам придется работать вместе и провести кучу тестов, но на это я и надеюсь.
для единичных серверных метрик я ожидал бы, что Prometheus будет иметь лучшую производительность (хотя мы не проводили здесь тестирования и не имеем номеров) из-за их более ограниченной модели данных и потому, что они не добавляют записи на диск перед написанием индекса.
язык запросов между ними очень отличается. Я не уверен, что они поддерживают, что мы еще не Или наоборот, поэтому вам нужно будет копаться в документах на обоих, чтобы увидеть, если есть кое-что, что можно сделать, что тебе нужно. Более долгосрочная наша цель состоит в том, чтобы функциональность запросов InfluxDB была надмножеством графита, RRD, Prometheus и других решений временных рядов. Я говорю superset, потому что мы хотим охватить их в дополнение к более аналитическим функциям позже. Очевидно, он отведет нас туда.
наконец, долгосрочной целью InfluxDB является поддержка высокой доступности и горизонтальной масштабируемости посредством кластеризации. Текущая реализация кластеризации функция еще не завершена и находится только в alpha. Тем не менее, мы работаем над этим, и это основная цель проекта. Наша конструкция кластеризации заключается в том, что данные в конечном итоге согласованы.
насколько мне известно, подход Прометея состоит в том, чтобы использовать двойные записи для HA (поэтому нет никакой возможной гарантии согласованности) и использовать Федерацию для горизонтальной масштабируемости. Я не уверен, как будет работать запрос через федеративные серверы.
в кластере InfluxDB вы можете запросить границы сервера без копирования всех данных по сети. Это потому, что каждый запрос разлагается на своего рода задание MapReduce, которое запускается на лету.
вероятно, есть еще, но это то, о чем я могу думать в данный момент.
мы получили маркетинговое сообщение от двух компаний в других ответах. Теперь давайте проигнорируем это и вернемся к печальному реальному миру временных рядов данных.
Немного Истории
InfluxDB и prometheus были сделаны для замены старых инструментов из прошлой эпохи (rrdtool, графит).
InfluxDB-это база данных временных рядов. Prometheus-это своего рода инструмент сбора метрик и оповещения, с механизмом хранения, написанным именно для этого. (Я на самом деле не уверен, что вы могли бы [или должен] повторно использовать механизм хранения для чего-то еще)
ограничения
к сожалению, написание базы данных является очень сложным делом. Единственный способ, которым обоим этим инструментам удается отправить что-то, - это отбросить все жесткие функции, связанные с высокой доступностью и кластеризацией.
грубо говоря, это одно приложение работает только на одном узле.
Prometheus не имеет цели поддерживать кластеризацию и репликацию вообще. Официальный способ поддержки отработки отказа -"запустите 2 узла и отправьте данные на оба из них". Ай. (Обратите внимание, что это серьезно единственный возможный способ, он написан бесчисленное количество раз в официальной документации).
InfluxDB говорил о кластеризации лет... пока он не был официально заброшен в марте. кластеризация больше не на столе для InfluxDB. Забудь об этом. Когда это будет сделано (предположим, что это когда-либо) он будет доступен только в Enterprise Edition.
https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/
в течение следующих нескольких лет мы надеемся, что у нас будет хорошо спроектированная база данных временных рядов, которая обрабатывает все сложные проблемы, связанные с базами данных: репликация, отказоустойчивость, безопасность данных, масштабируемость, резервное копирование...
на данный момент нет серебряная пуля.
Что делать
оцените ожидаемый объем данных.
100 метрик * 100 источников * 1 секунда = > 10000 точек данных в секунду = > 864 Мега-точки данных в день.
хорошая вещь о базах данных times series заключается в том, что они используют компактный формат, они хорошо сжимаются, они агрегируют данные и очищают старые данные. (Плюс они поставляются с функциями, относящимися к временным рядам данных.)
предположим, то, что точка данных обрабатывается как 4 байта, это всего лишь несколько гигабайт в день. К счастью для нас, есть системы с 10 ядрами и 10 ТБ дисками, которые легко доступны. Это, вероятно, может работать на одном узле.
альтернативой является использование классической базы данных NoSQL (Cassandra, ElasticSearch или Riak), а затем инженер недостающие биты в приложении. Эти базы данных не могут быть оптимизированы для такого типа хранения (или они? современные базы данных настолько сложны и оптимизированы, что не могут знать наверняка если не сравнивать).
вы должны оценить емкость, необходимую для вашего приложения. Напишите доказательство концепции с этими различными базами данных и измеряет вещи.
посмотрите, подпадает ли он под ограничения InfluxDB. Если так, то это, вероятно, лучший вариант. Если нет, вам придется сделать свое собственное решение поверх чего-то другого.
InfluxDB просто не может удерживать производственную нагрузку (метрики) с 1000 серверов. Он имеет некоторые реальные проблемы с проглатыванием данных и в конечном итоге заглох/повешен и непригоден для использования. Мы пытались использовать его некоторое время, но как только объем данных достиг критического уровня, он больше не мог использоваться. Никакие обновления памяти или процессора не помогли. Поэтому наш опыт определенно избегает его, это не зрелый продукт и имеет серьезные архитектурноакустические проблемы дизайна. И я даже не говорю о внезапном переходе на коммерческий Наплыв.
затем мы исследовали Prometheus и, хотя он требовал переписать запросы, теперь он глотает в 4 раза больше метрик без каких-либо проблем по сравнению с тем, что мы пытались кормить приток. И вся эта нагрузка обрабатывается одним сервером Prometheus, он быстрый, надежный и надежный. Это наш опыт работы с огромным международным интернет-магазином под довольно большой нагрузкой.
текущая реализация IIRC Prometheus разработана вокруг всех данных, подходящих на одном сервере. Если у вас есть гигантское количество данных, они могут не все поместиться в Прометее.