Ответ 1

Генеральный директор и разработчик InfluxDB. Следующая версия InfluxDB (0.9.5) будет иметь новый механизм хранения. Благодаря этому движку мы сможем эффективно хранить либо данные одного события, либо регулярно повторяющиеся серии. т.е. нерегулярные и регулярные временные ряды.

InfluxDB поддерживает типы int64, float64, bool и строковые данные, используя различные схемы сжатия для каждого из них. Prometheus поддерживает только float64.

Для сжатия версия 0.9.5 будет иметь компрессию, совместимую с Prometheus. В некоторых случаях мы увидим лучшие результаты, поскольку мы меняем сжатие на временных отметках на основе того, что мы видим. Лучший случайный сценарий - это регулярная серия, отсчитываемая точными интервалами. В тех случаях, когда по умолчанию мы можем сжать временные метки 1k точек в качестве 8-байтового начального времени, дельта (закодированный зигзагом) и счетчик (также закодированный зигзагом).

В зависимости от формы данных, которые мы видели, 2,5 байта на каждую точку в среднем после комков.

YMMV на основе временных меток, типа данных и формы данных. Например, случайные поплавки с отметками времени наносекундного масштаба с большими переменными дельтами будут самыми худшими.

Переменная точность в метках времени - еще одна особенность, которой обладает InfluxDB. Он может представлять собой второй, миллисекундный, микросекундный или наносекундный масштаб. Прометей фиксируется в миллисекундах.

Еще одно отличие заключается в том, что записи в InfluxDB являются прочными после того, как клиент отправит ответ об успешном завершении. Буферы Prometheus записываются в память и по умолчанию стирают их каждые 5 минут, что открывает окно потенциальной потери данных.

Наша надежда заключается в том, что после выпуска 0.9.5 InfluxDB это будет хороший выбор для пользователей Prometheus для использования в качестве долгосрочного хранилища метрик (совместно с Prometheus). Я почти уверен, что поддержка уже находится в Prometheus, но пока выпуск 0.9.5 не упадет, это может быть немного скалистым. Очевидно, нам придется работать вместе и выполнять кучу тестирования, но это то, на что я надеюсь.

В случае проглатывания единичных серверов я ожидал бы, что у Prometheus будет более высокая производительность (хотя мы не проводили тестирование здесь и не имели числа) из-за их более ограниченной модели данных и потому, что они не добавляют записи на диск до написания из индекса.

Язык запросов между ними очень различен. Я не уверен, что они поддерживают, что мы еще не или наоборот, поэтому вам нужно будет вникнуть в документы на обоих, чтобы увидеть, есть ли что-то, что вы можете сделать, что вам нужно. В долгосрочной перспективе наша цель состоит в том, чтобы функциональность запросов InfluxDB была надмножеством решений Graphite, RRD, Prometheus и других временных рядов. Я говорю суперсеть, потому что мы хотим позже охватить их в дополнение к более аналитическим функциям. Очевидно, нам потребуется время, чтобы добраться туда.

Наконец, более долгосрочная цель InfluxDB - поддерживать высокую доступность и масштабируемость по горизонтали посредством кластеризации. Текущая реализация кластеризации еще не полностью завершена и находится только в alpha. Однако мы работаем над этим, и это основная цель проекта для проекта. Наша структура кластеризации заключается в том, что данные в конечном итоге согласуются.

Насколько мне известно, подход Прометея заключается в использовании двойной записи для HA (поэтому нет никакой гарантии последовательности) и использования федерации для горизонтальной масштабируемости. Я не уверен, как будет работать запрос на федеративные серверы.

Внутри кластера InfluxDB вы можете запросить границы сервера без копирования всех данных по сети. Это потому, что каждый запрос разбивается на задание MapReduce, которое запускается на лету.

Вероятно, больше, но это то, о чем я могу думать в данный момент.

Ответ 2

У нас есть маркетинговое сообщение от двух компаний в других ответах. Теперь пусть игнорирует его и возвращается к печальному реальному миру рядов данных времени.

Некоторая история

InfluxDB и prometheus были сделаны для замены старых инструментов прошлой эпохи (RRDtool, графит).

InfluxDB - это база данных временных рядов. Prometheus - это инструмент сбора и оповещения о метриках, с механизмом хранения, написанным именно для этого. (Я на самом деле не уверен, что вы могли [или должны] повторно использовать механизм хранения для чего-то еще)

Ограничения

К сожалению, создание базы данных - очень сложное мероприятие. Единственный способ, с помощью которого оба этих устройства могут отправить что-то, - это сбросить все жесткие функции, связанные с высокой доступностью и кластеризацией.

Скажем, это одно приложение, в котором работает только один node.

Prometheus не имеет цели поддерживать кластеризацию и репликацию вообще. Официальным способом поддержки отказоустойчивости является "запустить 2 узла и отправить данные обоим из них". Уч. (Обратите внимание, что это серьезно ТОЛЬКО существующий способ, он написал много раз в официальной документации).

InfluxDB говорил о кластеризации в течение многих лет... до тех пор, пока в марте он не был официально отменен. Кластеризация больше не включена в таблицу для InfluxDB. Просто забудь это. Когда это будет сделано (предположим, что это когда-либо), оно будет доступно только в Enterprise Edition.

https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/

В течение следующих нескольких лет, мы надеемся, будет создана хорошо спроектированная база данных временных рядов, которая будет обрабатывать все сложные проблемы, связанные с базами данных: репликация, восстановление после сбоев, безопасность данных, масштабируемость, резервное копирование...

На данный момент нет серебряной пули.

Что делать

Оцените объем ожидаемых данных.

100 метрик * 100 источников * 1 секунда = > 10000 точек в секунду = > 864 Мегапит-точек в день.

Самое приятное в базах данных временного ряда заключается в том, что они используют компактный формат, они хорошо сжимаются, они объединяют точки данных и очищают старые данные. (Кроме того, они имеют функции, относящиеся к временным рядам данных.)

Предположим, что datapoint обрабатывается как 4 байта, это всего лишь несколько гигабайт в день. К счастью для нас, имеются системы с 10 ядрами и 10 ТБ дисками. Вероятно, это может работать на одном node.

Альтернативой является использование классической базы данных NoSQL (Cassandra, ElasticSearch или Riak), а затем разработка недостающих бит в приложении. Эти базы данных не могут быть оптимизированы для такого типа хранилищ (или они: современные базы данных настолько сложны и оптимизированы, что не могут точно знать, если они не определены).

Вы должны оценить емкость, требуемую вашим приложением. Напишите доказательство концепции с этими различными базами данных и измерьте вещи.

Посмотрите, попадает ли он в ограничения InfluxDB. Если это так, это, вероятно, лучший выбор. Если нет, вам нужно будет сделать собственное решение поверх чего-то другого.

Ответ 3

InfluxDB просто не может удерживать производственную нагрузку (метрики) от 1000 серверов. У этого есть некоторые реальные проблемы с проглатыванием данных и заканчивается заторможенным/повешенным и непригодным. Мы пытались использовать его некоторое время, но как только количество данных достигло некоторого критического уровня, его больше нельзя было использовать. Не помогло обновление памяти или процессора. Поэтому наш опыт определенно избегает этого, это не зрелый продукт и имеет серьезные проблемы архитектурного дизайна. И я даже не говорю о внезапном переходе к рекламе Influx.

Далее мы исследовали Прометея и, хотя он требовал переписать запросы, он теперь глотает в 4 раза больше показателей без каких-либо проблем, по сравнению с тем, что мы пытались подавать в Influx. И вся эта загрузка обрабатывается одним сервером Prometheus, она быстрая, надежная и надежная. Это наш опыт работы с огромным международным интернет-магазином под довольно большой нагрузкой.

Ответ 4

Текущая реализация Prometheus IIRC предназначена для всех фидов данных на одном сервере. Если у вас есть гигантское количество данных, возможно, он не подходит для Прометея.