Знакомство с InfluxDB и базами данных временных рядов


Оглавление (нажмите, чтобы открыть):

Слияние временных рядов в influxdb 0.9.x

У меня есть система, которая требует мониторинга ее показателей. Для этого я использую grafana + infuxdb. Версия influxdb, которую я сейчас использую, равна 0,9.

Я хочу иметь возможность рассчитать некоторые статистические данные. Мой вариант использования довольно прост:

  1. Я хочу сделать запрос выбора из нескольких источников временных рядов.
  2. Я хочу сделать групповой оператор внутри запроса select, чтобы собрать мои данные.
  3. Наконец, я хочу найти среднее значение внутри каждой группы.

Мой запрос выглядит следующим образом:

Это кажется тривиальным, однако, это немного сложно. Я получаю что-то вроде этого:

В соответствии с документацией infuxdb вы можете захватывать данные из нескольких источников. Другими словами, вы можете написать несколько рядов данных после ключевого слова FROM. В то время как я хочу объединить их и выполнить свою обработку в объединенной серии. В influxdb 0.8.x была функция merge которая давала вам возможность смешивать источники данных. Однако в influxdb 0.9.x нет операций объединения или объединения.

В InfluxDB 0.9 поддерживаются операции MERGE или JOIN. Операция MERGE больше не нужна. Все серии в пределах измерения автоматически объединяются при запросе, если явно не исключены теги в предложении WHERE.

Итак, когда вы пишете

Вы получаете пустой результат.

Следовательно, мой вопрос заключается в следующем: каков способ выбора данных из нескольких источников временных рядов, их слияния, группировки по некоторым критериям и применения функции агрегации для каждой группы с использованием инструментов infuxdb 0.9.x?

Apache Kudu vs InfluxDB по данным временных рядов для быстрой аналитики

Как Apache Kudu сравнивается с InfluxDB для данных датчика IoT, требующих быстрой аналитики (например, робототехники)?

Куда недавно выпустила v1.0 У меня есть несколько конкретных вопросов о том, как Куда обрабатывает следующее:

  1. сегментирования?
  2. Политика хранения данных (сохранение данных для заданного количества точек данных или время и агрегирование/отмена данных после этого)?
  3. Имеются ли функции свертывания/агрегации (например, преобразование интервальных данных 1 с в данные с интервалом 1 мин)?
  4. Есть ли поддержка для непрерывных запросов (то есть материализованные представления данных — запрос для просмотра 60 секунд на постоянной основе)?
  5. Как хранятся данные между диском и памятью?
  6. Можно ли индуцировать регулярные временные ряды из нерегулярного (преобразование нерегулярных событий в регулярные интервалы времени)?

Также существуют ли какие-либо другие сильные и слабые стороны между Kudu и InfluxDB?

Создан 25 сен. 16 2020-09-25 03:53:42 Anonymous

Является ли шорт-лист ограничен только этими двумя базами данных, потому что многие другие реализации могут соответствовать цели, от историков растений до недавно введенных TSDB. – Sergei Rodionov 25 сен. 16 2020-09-25 16:57:20

Я ищу несколько полный пакет, поэтому я рад открыть этот вопрос другим кандидатам. Influxdb от первых впечатлений неплох, но я не уверен, как он масштабируется на одном узле (кластеризация, к сожалению, сделана закрытым источником). Я очень кратко посмотрел на OpenTSDB, но заметил, что мне придется принять общую сложность запуска кластера Hadoop/Hbase, который может немного запутаться. – user1478046 25 сен. 16 2020-09-25 22:56:26

1 ответ

Kudu — это гораздо более низкоуровневое хранилище данных, чем InfluxDB. Это больше похоже на распределенную файловую систему, которая предоставляет несколько базовых функций, а не полноценную базу данных. В настоящее время он использует механизм запросов, такой как Impala для поиска данных, хранящихся в Kudu.

Kudu также довольно молодой. Вероятно, будет возможно построить базу данных временных рядов с kudu в качестве распределенного хранилища под ней, но в настоящее время ближайшей реализацией этого будет this proof of concept project.

Что касается ответов на ваши вопросы.

1) Куда хранит данные в таблетках и предлагает два способа данных разбиения на разделы: Range Partitions and Hash based Partitioning

2) Nope Хотя если данные были структурированы с расстоянием разделением, сбросив таблетку должна быть эффективной работа (аналогично тому, как InfluxDB выпадает целые осколки при удалении данных).

3) Двигатели запросов, которые работают с Kudu, могут это сделать, например, импала или искра.

4) Impala имеет некоторую поддержку views

5) Данные хранятся в столбчатой ​​формате, аналогичной Паркетные однако большая точка продажи куду является то, что Куду позволяет столбчатые данным быть изменчивыми, которая является то, что очень сложно с текущими файлами паркета.

6) Хотя я уверен, что вы можете получить искру или импалу, чтобы сделать это, это не встроенная функция.

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


Создан 03 дек. 16 2020-12-03 07:08:48 tkinz27

Знакомство с InfluxDB и базами данных временных рядов

2379 просмотра

2 ответа

1531 Репутация автора

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

Ответы (2)

-1 плюса

1477 Репутация автора

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

Можете ли вы добавить в MySQL 1 миллион записей в секунду в течение нескольких недель, даже не переставая работать, даже не задумываясь о возможности сопровождения? Как вы можете массово удалить старые данные, которые больше не актуальны, при сохранении этой скорости загрузки?

Структура данных InfluxDB и модель базы данных

Подскажите, пожалуйста, какая структура данных имеет InfluxDB и какую модель данных использует InfluxDB? Это модель ключ-значение. Я прочитал полную документацию и не понял этого.

3 ответа

1. Модель данных и терминология

База данных InfluxDB хранит точки. Точка имеет четыре компонента: измерение, набор тегов, набор полей и временную метку.

Измерение предоставляет способ связать связанные точки, которые могут иметь разные наборы тегов или наборы полей. Набор тегов — это словарь пар ключ-значение для хранения метаданных с точкой. Fieldset — это набор типизированных скалярных значений — данных, записываемых точкой.

Формат сериализации для точек определяется [линейным протоколом] (который включает дополнительные примеры и пояснения, если вы хотите прочитать более подробно). Пример пункта из спецификации помогает объяснить терминологию:

”Температура, машина = устройство 42, тип = сборка внутренняя = 32, внешняя = 100 1434055562000000035

Измерение это температура.

Набор тэгов: machine = unit42, type = Assembly. Ключи, machine и type, в tagset называются ключами tag. Значения, unit42 и сборка, в наборе тегов называются значениями тегов.

Набор полей является внутренним = 32, внешним = 100. Внутренние и внешние ключи в наборе полей называются полевыми ключами. Значения 32 и 100 в наборе полей называются значениями полей.

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

Мы объясним фактор репликации, группы сегментов и фрагменты позже, когда опишем, как работает путь записи в InfluxDB.

Мастер Йода рекомендует:  50 лучших бесплатных пресетов для Lightroom

Есть еще один термин, который нам нужно начать: серия. Серия — это просто сокращение, обозначающее политику хранения + измерение + набор тегов. Все точки с одинаковой политикой хранения, измерениями и набором тегов являются членами одной серии.

Вы можете обратиться к [глоссарию документации] для этих или других терминов, которые могут использоваться в этой серии постов в блоге.

2. Получение баллов от клиентов

Клиенты POST указывают (в формате линейного протокола) на конечную точку HTTP / записи InfluxDB. Очки можно отправлять индивидуально; однако для эффективности большинство приложений отправляют баллы партиями. Типичная партия варьируется в размерах от сотен до тысяч точек. POST определяет базу данных и необязательную политику хранения через параметры запроса. Если политика хранения не указана, используется политика хранения по умолчанию. Все точки в теле будут записаны в эту базу данных и политику хранения. Точки в теле POST могут быть из произвольного числа рядов; точки в партии не обязательно должны быть из одного измерения или набора тегов.

Когда база данных получает новые точки, она должна (1) сделать эти точки долговечными, чтобы их можно было восстановить в случае сбоя базы данных или сервера, и (2) сделать точки запрашиваемыми. Этот пост посвящен первой половине, делая очки прочными.

3. Сохраняющиеся точки хранения

Чтобы сделать точки долговечными, каждая партия записывается и синхронизируется с журналом записи вперед (WAL). WAL — это файл только для добавления, который читается только во время восстановления базы данных. Для повышения эффективности дискового и дискового ввода-вывода каждый пакет в WAL сжимается с помощью [сжатие snappy] перед записью на диск.

Несмотря на то, что формат WAL эффективно делает входящие данные долговечными, он является чрезвычайно плохим форматом для чтения, что делает его непригодным для поддержки запросов. Чтобы обеспечить возможность немедленного запроса новых данных, входящие точки также записываются в кэш в памяти. Кеш — это структура данных в памяти, которая оптимизирована для выполнения запросов и вставки. Структура данных кэша представляет собой карту последовательностей в отсортированный по времени список полей.


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

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

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

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

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

Необязательная продолжительность времени жизни, гранулярность временных блоков в периоде времени жизни и количество реплик настраиваются с помощью политики хранения InfluxDB:

СОЗДАЙТЕ ПОЛИТИКУ УДЕРЖАНИЯ В РЕЖИМЕ ДЛИТЕЛЬНОСТИ.

Продолжительность является необязательным временем жизни (если данные не должны истекать, установите длительность в INF). Длительность осколка — это детализация данных в течение срока действия. Например, длительность одночасового шарда с 24-часовым интервалом конфигурирует базу данных для хранения 24 одночасовых шардов. Каждый час самый старый осколок теряется (удаляется) из базы данных. Задайте REPLICATION для настройки коэффициента репликации — сколько копий сегмента должно существовать в кластере.

Конкретно, база данных создает такую физическую организацию данных на диске:

» Директор базы данных / db » Каталог политик хранения / db / rp » Группа сегментов (ограничено по времени). (Логический) » Каталог Shard (db / rp / Id #) » TSM0001.tsm (файл данных) » TSM0002.tsm (файл данных) »… Кэш в памяти записывается на диск в формате TSM. Когда очистка завершается, очищенные точки удаляются из кэша, и соответствующий WAL усекается. (WAL и кеш также поддерживаются отдельно). В файлах данных TSM хранятся столбчато организованные точки. После записи файл TSM является неизменным. Подробное описание макета файла TSM доступно в [документации InfluxDB].

4. Сжатие сохраняемых точек

Кеш — это относительно небольшой объем данных. Столбчатый формат TSM работает лучше всего, когда он может хранить длинные серии значений для серии в одном блоке. Чем дольше выполняется, тем лучше сжатие и уменьшается количество попыток сканировать поле для запроса. Формат TSM в значительной степени основан на лог-структурированных деревьях слияния. Новые (первый уровень) файлы TSM генерируются путем очистки кеша. Эти файлы позже объединяются (уплотняются) в файлы второго уровня. Файлы второго уровня далее объединяются в файлы третьего уровня. Дополнительные уровни сжатия возникают по мере того, как файлы становятся больше и в конечном итоге становятся холодными (диапазон времени, который они охватывают, больше не является горячим для записи.) В приведенной выше справочной документации содержится подробное описание сжатия.

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

Сравнение с SQL

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

В целом…

InfluxDB предназначен для работы с данными временных рядов. Базы данных SQL могут обрабатывать временные ряды, но не были созданы строго для этой цели. Короче говоря, InfluxDB предназначен для хранения большого объема данных временных рядов и быстрого анализа данных в реальном времени.

Сроки — это все

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

InfluxDB также признает, что ваши настройки schema могут меняться со временем. В InfluxDB вам не нужно определять схемы спереди. Точки данных могут иметь одно из полей измерения, все поля измерения или любое число между ними. Вы можете добавлять новые поля к измерению просто путем написания точки для этого нового поля. Если вам нужно пояснить термины измерения, теги и поля, ознакомьтесь с следующим разделом базы данных SQL с переходом на терминологию InfluxDB.

терминология

В приведенной ниже таблице (очень) простой пример таблицы, называемой foodships в базе данных SQL, с необработанным столбцом #_foodships и индексированными столбцами park_id , planet и time .

Те же самые данные выглядят в InfluxDB:

Обращаясь к приведенному выше примеру, в общем:

  • Измерение InfluxDB ( foodships ) аналогично таблице базы данных SQL.
  • Теги InfluxDB ( park_id и planet ) похожи на индексированные столбцы в базе данных SQL.
  • Поля InfluxDB ( #_foodships ) похожи на необъявленные столбцы в базе данных SQL.
  • Очки InfluxDB (например, 2015-04-16T12:00:00Z 5 ) аналогичны строкам SQL.

Основываясь на этом сравнении терминологии базы данных, непрерывные запросы и политики хранения InfluxDB аналогичны хранимым процедурам в базе данных SQL. Они указываются один раз, а затем выполняются регулярно и автоматически.

Конечно, между базами данных SQL и InfluxDB существуют некоторые существенные различия. SQL JOIN не доступны для измерений InfluxDB; ваш дизайн схемы должен отражать эту разницу. И, как мы уже упоминали выше, измерение похоже на таблицу SQL, где первичный индекс всегда предварительно задан во времени. Временные метки InfluxDB должны быть в эпоху UNIX (GMT) или отформатированы как строка даты, действительная в соответствии с RFC3339.

Мастер Йода рекомендует:  Знакомимся с веб-стандартами видеоруководство по работе с аудио от Microsoft

Более подробные описания терминов InfluxDB, упомянутых в этом разделе, см. В нашем глоссарии терминов .

InfluxQL и SQL

InfluxQL является SQL-подобным языком запросов для взаимодействия с InfluxDB. Он был с любовью создан, чтобы чувствовать себя знакомым с теми, кто приходит из других SQL или SQL-подобных сред, а также предоставляет функции, специфичные для хранения и анализа данных временных рядов.


Операция SELECT оператора InfluxQL следует форме SELECT SQL SELECT :

где WHERE является обязательным. Чтобы получить вывод InfluxDB в разделе выше, вы должны ввести:

Если вы хотите видеть данные только для планеты Saturn , вы должны ввести:

Если вы хотите увидеть данные для планеты Saturn после 12:00:01 UTC 16 апреля 2015 года, вы должны ввести:

Как показано в приведенном выше примере, InfluxQL позволяет указать временной диапазон вашего запроса в WHERE . Вы можете использовать строки даты и времени, заключенные в одинарные кавычки, которые имеют формат YYYY-MM-DD HH:MM:SS.mmm ( mmm — миллисекунды и не является обязательным, и вы также можете указать микросекунды или наносекунды). Вы также можете использовать относительное время с помощью now() который ссылается на текущую временную метку сервера:

Этот запрос выводит данные в меру foodships где метка времени более новая, чем текущее время сервера минус один час. Опции для определения длительности времени с помощью now() :

Письмо Имея в виду
нс наносекунд
u или μ микросекунд
Миз миллисекунды
s секунд
м минут
час часов
d дней
вес недель

InfluxQL также поддерживает регулярные выражения, арифметику в выражениях, инструкции SHOW операторы GROUP BY . См. Нашу страницу поиска данных для углубленного обсуждения этих тем. Функции InfluxQL включают COUNT , MIN , MAX , MEDIAN , DERIVATIVE и другие. Полный список можно просмотреть на странице functions .

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

Заметка о том, почему InfluxDB не является CRUD .

InfluxDB — это база данных, оптимизированная для данных временных рядов. Эти данные обычно поступают из таких источников, как распределенные группы датчиков, данные с больших сайтов или списки финансовых транзакций.

Единственное, что имеет эти данные, состоит в том, что оно более полезно в совокупности. В одном чтении говорится, что процессор вашего компьютера составляет 12% использования в 12:38:35 UTC во вторник трудно сделать выводы. Он становится более полезным в сочетании с остальной частью серии и визуализируется. Именно здесь начинают проявляться тенденции с течением времени, и из данных можно извлечь убедительные сведения. Кроме того, данные временных рядов обычно пишутся один раз и редко обновляются.

В результате InfluxDB не является полной базой данных CRUD, а больше похожей на CR-ud, определяя приоритетность производительности создания и чтения данных по сравнению с обновлением и уничтожением, а также предотвращая некоторое обновление и уничтожение поведения, чтобы создавать и читать более эффективные.

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

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

2ТБ, предрассчитанные(суммируются значения с одними и теми же фильтрами)

100Гб.
Сейчас где-то секунд 30 занимает каждый запрос по фильтрам, работать аналитикам с такими задержками крайне неудобно.
Реалтайм не нужен(для большинства метрик хватит актуальности «за вчера»).

Вопрос больше к тем, кто пользуются одной из БД — какие проблемы? Как шустро работает?.

  • Вопрос задан более трёх лет назад
  • 3913 просмотров

Не очень понял задачу, попробую объяснить разницу, как я это понимаю из своего опыта:

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ы и т.д.
* с дефолтным хранилищем при большом количестве серий начинает упираться в диск
* масштабируется неважно (подробностей не знаю)
* периодически из сообщества появляются разнообразные хранилища, которые улучшают ситуацию со скоростью и масштабированием

linux-notes.org

Установка InfluxDB в Unix/Linux

InfluxDB — база данных временных рядов с открытым исходным кодом, разработанная в InfluxData. Данный продукт написан на Go и оптимизирован для быстрого хранения с высокой скоростью поиска данных по временным рядам.

Данную ДБ используют в связке с CollectD и Grafana:

InfluxData состоит из:

  • Telegraf — программа которая позволяет собирать метрики с временными рядами.
  • InfluxDB — БД которую можно кластерезировать. Она была создана специально для хранения временных рядов.
  • Chronograf — инструмент для визуализации временных рядов. Web приложение для настройки графиков и dashboard’ов.
  • Kapacitor — утилита для обработки значений временных рядов и контроля отклонений значений.


Данные приложения, образуют стек технологий (который можно назвать TICK) и он выступает синонимом InfluxData.

Установка InfluxDB в Unix/Linux

Приведу примеры установок на различные ОС.

По умолчанию InfluxDB будет использовать 8083 и 8086 TCP-порты. По завершении установки вы можете изменить эти порты и другие параметры в файле конфигурации.

Установка InfluxDB в CentOS/RedHat/Fedora

А затем устанавливаем:

Для запуска службы InfluxDB, используйте:

Установка InfluxDB в Debian

Для пользователей Debian вы можете добавить конфигурацию репозитория InfluxData, для этого добавим ключ:

Добавляем репозиторий (в зависимости от версии):

А затем устанавливаем:

Для запуска службы InfluxDB, используйте:

Установка InfluxDB в Ubuntu

Для пользователей Ubuntu вы можете добавить конфигурацию репозитория InfluxData, для этого добавим ключ:

А затем устанавливаем:

Для запуска службы InfluxDB, используйте:

Установка InfluxDB в SLES & openSUSE

А затем устанавливаем:

Установка InfluxDB в FreeBSD/PC-BSD

Конфиг находится: /usr/local/etc/influxd.conf, а пример можно найти — /usr/local/etc/influxd.conf.sample.

Для запуска службы InfluxDB, используйте:

Для авто-запуска, пропишите в/etc/rc.conf файле:

Установка InfluxDB в Mac OS X

Установим для начала Homebrew и выполним потом:

Чтобы запустить influxdb при входе в систему, юзайте:

Для запуска службы InfluxDB, используйте:

PS: Если вы не хотите (или нужно запустить) в отдельном окне, то для этого используйте:

Настройка InfluxDB в Unix/Linux

По умолчанию InfluxDB использует порты 8083, 8086, 8090 и 8099. Можно использовать и другие порты — для этого потребуется внести соответствующие изменения в конфигурационный файл. Рассмотрим особенности конфигурирования InfluxDB более подробно.

Проверим какие слушает, можно:

Проверяем что сервис запущен:


В конфигурационном файле, открываем его для начала:

В нем имеются настройки, которые делятся на группы:

  • [logging] — Задается некоторые детали для логирования. Можно выставить уровень самого логироваия и указать имя лога;
  • [admin] — Задаются некоторые настройки веб-интерфейса. Можно задать порт (на нем будет работать внутренний веб-сервер). Так же, можно указать путь к файлам веб-интерфейса;
  • [api] — Настройки HTTP API;
  • [input_plugins] — Задаются некоторые настройки для ввода данных из внешних источников (можно настроить отправку данных в Grafana; Также в этом разделе можно настроить ввод данных по протоколу UDP).
  • [raft] —Задаются настройки протокола согласования RAFT;
  • [storage] — Задаются настройки хранения данных;
  • [cluster] —Задаются настройки для работы в кластерном режиме (более подробно они будут описаны ниже;
  • [wal] — настройки опережающего введения журнала (Write Ahead Logging, WAL).

Приводим к виду:

Для генерации конфига, используйте:

Подключение и создание БД в influxDB

Чтобы подключится, используем:

Для создания БД, используем следующую команду:

its_my_first_DB — Название БД.

Просмотр баз данных в influxDB

Чтобы подключится, используем:

Чтобы просмотреть какие БД имеются, используем:

Использование базы данных в influxDB

Чтобы подключится, используем:

Чтобы начать использовать БД:

Запишем некоторые данные в созданную БД:

Или, вставим еще другие данные:

Не очень сложно.

Просмотр данных в influxDB базе

Чтобы подключится, используем:

Чтобы просмотреть какие БД имеются, используем:

Чтобы начать использовать БД:

И, выбираем данные:

InfluxDB поддерживает сложный язык запросов, позволяющий выполнять много разных типов запросов. Например:

Создание пользователя в influxDB

Создать пользователя можно одним из следующих примерах:

Выставить права можно:

Все гениальное — просто!

А я на этом завершаю свою статью «Установка InfluxDB в Unix/Linux».

Добавить комментарий Отменить ответ


Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

InfluxDB

InfluxDB

Разработчики: InfluxData
Выпущена: 24 September 2013 года ; 6 years ago ( 2013-09-24 )
Постоянный выпуск: 1.7.0 / 06 November 2020 года [1]
Состояние разработки: Активное
Написана на: Go
Операционная система: Кроссплатформенность
Тип ПО: Time series database
Лицензия: MIT
Веб-сайт influxdata .com

InfluxDB — это база данных временных рядов с открытым исходным кодом, разработанная InfluxData. Написана на Go! и оптимизирована для быстрого хранения с высокой степенью готовности и поиска временных рядов данных в таких областях, как мониторинг операций, метрики приложений, данные о Internet of Things и аналитика в реальном времени. Также поддерживает обработку данных Graphite [2] .

Содержание

История

Y Combinator — backed Errplane [3] начал разработку InfluxDB в качестве проекта с открытым исходным кодом в конце 2013 года для мониторинга производительности и оповещения. Errplane привлекла финансирование в размере 8,1 млн. Долл. США под руководством фонда Mayfield и Trinity Ventures в ноябре 2014 года. [4] В конце 2015 года Errplane официально изменила свое название на InfluxData Inc. В сентябре 2020 года InfluxData повысила круглый раунд серии B в размере 16 000 000 долларов США [5] .

Техническое описание

InfluxDB не имеет внешних зависимостей [6] и предоставляет SQL-подобный язык со встроенными временными функциями для запроса структуры данных, состоящей из измерений, рядов и точек. Каждая точка состоит из нескольких пар ключ-значение, которые называются набором полей и временной меткой. Когда они группируются вместе с набором пар ключ-значение, называемых тегами, они определяют серию. Наконец, ряды группируются вместе строковым идентификатором для формирования измерения.

Значения могут быть 64-битными целыми числами, 64-битными плавающими точками, строками и булевыми.

Точки индексируются по времени и меток.

Политика хранения определяется для измерения и контроля того, как данные сбрасываются и удаляются.

Непрерывные запросы выполняются периодически, сохраняя результаты в целевом измерении.

Линейный протокол

InfluxDB принимает данные через HTTP, TCP и UDP.

Он определяет линейный протокол, который обратно совместим с графитом и принимает форму:

measurement(,tag_key=tag_val)* field_key=field_val(,field_key_n=field_value_n)* (nanoseconds-timestamp)?

Закрытые компоненты кластеризации источника

В мае 2020 года InfluxData объявила, что горизонтально масштабируемый компонент «кластеризации» InfluxDB будет продаваться как программное обеспечение с закрытым исходным кодом, чтобы создать устойчивый источник финансирования для разработки проекта. [7] Реакция сообщества была смешанной, с некоторым чувством, что движение было « приманкой и переключателем » [8] .

Хранение метрик потоков в БД Influx

Influx — БД временных рядов с открытым исходным кодом.

Для того, чтобы установить Influx на CentOS 7, необходимо сделать следующее:

1. Создать файл /etc/yum.repos.d/influxdb.repo:

2. Выполнить команду

3. Настроить в файле /etc/influxdb/influxdb.conf возможность подключения по UDP:

4. Запустить БД Influx

Процедура установки Influx на Debian/Ubuntu отличается только способом добавления необходимого репозитория.

БД Influx может быть установлена на одном сервере с WCS. Для подключения к БД используется TCP порт 8086 или UDP порт 8089.

Настройка БД

Для настройки БД Influx для хранения метрик необходимо:


1. Указать в файле настроек wcsoam.properties параметр

2. Указать в файле настроек init_tsdb.properties длительность хранения метрик

По умолчанию, длительность хранения метрик установлена в 2 суток (48 часов).

3. Запустить скрипт настройки БД

Структура БД

База данных для хранения значений метрик потоков в виде временных рядов содержит поля со следующими ключами:

Примеры выборки данных из БД Influx

Для потока, зная идентификатор узла, на котором он опубликован, и идентификатор медиасессии, можно выбрать данные из БД Influx:

1. Войдите в интерфейс командной строки Influx

2. Подключитесь к БД wcs-oam

3. Выведите список временных рядов

Отобразится список временных рядов, каждый соответствует потоку, опубликованному на заданном узле в определенной медиасессии

4. Выберите значения битрейта видео для потока на узле 3 в медиасессии 7ecbd270-123e-11e9-bb40-b96debd59887

Отобразятся значения битрейта видео с метками времени

Apache Kudu vs InfluxDB по данным временных рядов для быстрой аналитики

Как Apache Kudu сравнивается с InfluxDB для данных датчика IoT, требующих быстрой аналитики (например, робототехники)?

Куда недавно выпустила v1.0 У меня есть несколько конкретных вопросов о том, как Куда обрабатывает следующее:

  1. сегментирования?
  2. Политика хранения данных (сохранение данных для заданного количества точек данных или время и агрегирование/отмена данных после этого)?
  3. Имеются ли функции свертывания/агрегации (например, преобразование интервальных данных 1 с в данные с интервалом 1 мин)?
  4. Есть ли поддержка для непрерывных запросов (то есть материализованные представления данных — запрос для просмотра 60 секунд на постоянной основе)?
  5. Как хранятся данные между диском и памятью?
  6. Можно ли индуцировать регулярные временные ряды из нерегулярного (преобразование нерегулярных событий в регулярные интервалы времени)?

Также существуют ли какие-либо другие сильные и слабые стороны между Kudu и InfluxDB?

Создан 25 сен. 16 2020-09-25 03:53:42 Anonymous

Является ли шорт-лист ограничен только этими двумя базами данных, потому что многие другие реализации могут соответствовать цели, от историков растений до недавно введенных TSDB. – Sergei Rodionov 25 сен. 16 2020-09-25 16:57:20

Я ищу несколько полный пакет, поэтому я рад открыть этот вопрос другим кандидатам. Influxdb от первых впечатлений неплох, но я не уверен, как он масштабируется на одном узле (кластеризация, к сожалению, сделана закрытым источником). Я очень кратко посмотрел на OpenTSDB, но заметил, что мне придется принять общую сложность запуска кластера Hadoop/Hbase, который может немного запутаться. – user1478046 25 сен. 16 2020-09-25 22:56:26

1 ответ

Kudu — это гораздо более низкоуровневое хранилище данных, чем InfluxDB. Это больше похоже на распределенную файловую систему, которая предоставляет несколько базовых функций, а не полноценную базу данных. В настоящее время он использует механизм запросов, такой как Impala для поиска данных, хранящихся в Kudu.

Kudu также довольно молодой. Вероятно, будет возможно построить базу данных временных рядов с kudu в качестве распределенного хранилища под ней, но в настоящее время ближайшей реализацией этого будет this proof of concept project.

Что касается ответов на ваши вопросы.

1) Куда хранит данные в таблетках и предлагает два способа данных разбиения на разделы: Range Partitions and Hash based Partitioning

2) Nope Хотя если данные были структурированы с расстоянием разделением, сбросив таблетку должна быть эффективной работа (аналогично тому, как InfluxDB выпадает целые осколки при удалении данных).

3) Двигатели запросов, которые работают с Kudu, могут это сделать, например, импала или искра.

4) Impala имеет некоторую поддержку views

5) Данные хранятся в столбчатой ​​формате, аналогичной Паркетные однако большая точка продажи куду является то, что Куду позволяет столбчатые данным быть изменчивыми, которая является то, что очень сложно с текущими файлами паркета.

6) Хотя я уверен, что вы можете получить искру или импалу, чтобы сделать это, это не встроенная функция.

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

Создан 03 дек. 16 2020-12-03 07:08:48 tkinz27

Мастер Йода рекомендует:  Как предотвратить прокрутку страницы, при открытом модальном окне
Добавить комментарий