Глубокое погружение в InfluxDB

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

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

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

InfluxDB — это база данных, написанная на Go, чтобы помочь вам работать именно с данными временных рядов. Временной ряд — это набор точек, каждая из которых содержит метку времени. В InfluxDB временная метка может храниться с наносекундными интервалами. На практике мы можем увидеть что-то вроде этого:

Итак, зачем нам определенное хранилище для временных рядов? Почему мы не можем использовать традиционные базы данных, такие как MySQL, Cassandra, MongoDB или Elasticsearch? Чтобы ответить на эти вопросы, вы должны рассмотреть ваш вариант использования. Существуют различные тесты InfluxDB по сравнению с другими базами данных, и вы можете быстро увидеть, что InfluxDB превосходит их все.

Но дело не только в производительности; Временные ряды — это особый домен, а InfluxDB как база данных временных рядов предоставляет различные возможности для работы со временем. Это, наверное, самая важная причина для использования InfluxDB.

InfluxDB предлагает мощный движок и две точки входа для взаимодействия с ним. Он поддерживает HTTP API, который по умолчанию работает на порте 8086 с возможностью чтения и записи. И он поддерживает UDP как протокол записи.

Модель данных

Модель данных — это структура данных, которыми манипулирует и управляет InfluxDB. Вы можете увидеть measurement в виде таблицы, которая содержит набор точек, которые обычно находятся в одном домене. Каждая точка помечена tags и fields .

Мы называем набор тегов tagset . Основным отличием tags fields является индекс. tags индексируются, а fields нет. Индексирование tags позволяет вам делать оптимизированные запросы с меньшим потреблением ресурсов. И tag и field являются ключевыми значениями, но tag принимает строки, где fields принимают целые числа и числа с плавающей запятой.

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

На практике точка выглядит так:

Отметка времени не является обязательной, поскольку InfluxDB добавит ее, если она не указана.

Понимание модели InfluxDB важно для создания быстрой структуры вокруг вашего набора данных. Комбинация .measurement + tagset называется серией. Чтобы определить конкретную точку, правильной комбинацией является measurment + tagset + timestamp .

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

Зарегистрируй бесплатный аккаунт Codeship

TCP против UDP

Вы знаете разницу между TCP и UDP, так почему же InfluxDB поддерживает оба? Как выбрать правильный вариант для вашего случая использования?

Чтобы ответить на этот вопрос, вам нужно подумать о ключевых различиях между этими двумя протоколами: UDP не гарантирует успешность запроса. Применительно к InfluxDB клиент не знает, успешно ли сохранены точки в InfluxDB. Если вы храните конфиденциальные данные, вы, вероятно, должны быть на 100 процентов уверены, что все точки есть. С другой стороны, если для вас не важно хранить все точки, вы можете использовать UDP. Например, если вы используете процессор, вы можете пропустить момент, пока поведение не станет читабельным и понятным.

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

Кстати, для ясности, UDP работает быстрее и использует меньше ресурсов, чем TCP. Чтобы дать вам представление, мы сделали тест с php-sdk, разработанным Corley SRL :

Приток CLI

С InfluxDB есть CLI, названный influx ; если вы установите его через apt, yum или Docker, вы найдете его в своей системе. CLI является точкой входа по умолчанию. Вы можете делать все оттуда — вставлять точки, запрашивать и управлять доступом к базе данных. Он использует REST API для связи с InfluxDB.

Query Engine

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

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

Политика удержания

Число сохраняемых серий и точек быстро растет, что характерно для мониторинга, когда вы постоянно собираете и храните данные. В какой-то момент производительность чтения станет проблемой.

С другой стороны, если вам не нужно хранить все ваши данные в InfluxDB навсегда, есть функция, называемая retention policy . По умолчанию он хранит ваши данные вечно, но вы можете изменить их. Если вы установите retention policy на две недели, все точки, сохраненные с этим хранением, будут удалены через две недели.

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

С помощью параметров запроса rb вы можете переопределить политику хранения по default .