Генеральный директор и разработчик InfluxDB. Следующая версия InfluxDB (0.9.5) будет иметь новый механизм хранения. Благодаря этому движку мы сможем эффективно хранить либо данные одного события, либо регулярно повторяющиеся серии. т. е. нерегулярные и регулярные временные ряды.
InfluxDB поддерживает типы данных int64, float64, bool и string с использованием различных схем сжатия для каждого из них. Prometheus поддерживает только float64.
Для сжатия версия 0.9.5 будет иметь компрессию, совместимую с Prometheus. В некоторых случаях мы увидим лучшие результаты, поскольку мы меняем сжатие на временных отметках на основе того, что мы видим. Лучший случайный сценарий - это регулярная серия, отсчитываемая точными интервалами. В них по умолчанию мы можем сжать отметки времени в 1 к в качестве начального времени в 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, которое запускается «на лету».
Возможно, что-то еще, но об этом я могу думать в данный момент.
Прометей здесь. Павел прав, что Prometheus есть и будет всегда плавать только (строки возможны ограниченным образом через метки), тогда как InfluxDB поддерживает множество типов данных. Я предполагаю, что языки запросов довольно похожи по силе на практике (Prometheus - Turing Complete). Наш подход HA состоит в том, чтобы иметь изолированные избыточные серверы, alertmanager будет выводить предупреждения из них. Обычно мы применяем AP-подход к мониторингу, а не к CP, так как лучше потерять немного данных, чем ваш мониторинг. Прометей стремится стать системой, в которую вы можете положиться в чрезвычайной ситуации. –
Конструкция кластеризации InfluxDB также в значительной степени является AP, но она, в конечном счете, является последовательной. Мы достигаем этого через Hinted Handoff (доступно в текущем выпуске) и Active Anti-Entroy (который мы начнем с 0.9.6). Очевидно, что мы еще не закончили кластеризацию, но это цель дизайна. Подробнее здесь: https://influxdb.com/blog/2015/06/03/InfluxDB_clustering_design.html –
Другой Прометей dev здесь. Да, сам Прометей не стремится быть долговечным долговременным хранилищем. Но в других отношениях его объем больше и больше об активных системах и мониторинге услуг: из клиентских библиотек (которые не только говорят на каком-то протоколе вывода показателей, но и помогают управлять примитивами показателей, такими как счетчики, датчики, гистограммы и сводки) , по активному обнаружению цели/сбору данных, панели мониторинга, вплоть до оповещения о вычислении и обработке уведомлений. Язык запросов также не похож на SQL, но отлично работает для вычислений по размерным временным рядам. – Julius