Time series database что это
Time Series, метрики и статистика: знакомство с InfluxDB
Введение
Любому системному администратору постоянно приходится иметь дело с данными, представленными в форме временных рядов (time series): статистика скачивания файлов, статистика запросов к серверам, данные об использовании системных и аппаратных ресурсов виртуальными машинами…
Чтобы все это хранить и обрабатывать, нужен адекватный и производительный инструмент.
Для хранения временных рядов часто используются специализированные решения — так называемые time series (темпоральные) базы данных. Об их плюсах и минусах мы уже писали. Пытаясь исправить недостатки имеющихся решений, мы даже разработали собственный продукт — time series базу данных YAWNDB, которая используется в нашей системе мониторинга. Но все time series базы данных являются низкоуровневыми, а возможности их применения весьма ограничены. Во-первых, они не позволяют объединять временные ряды c данными других типов — например, со словарями. Во-вторых, они совершенно не рассчитаны на работу с большими объемами данных. В большинстве темпоральных БД даже нет языка запросов. Поэтому стандартная задача — запросить и получить нужную информацию в любой момент времени — становится очень сложной и нетривиальной. Конечно, её можно решить и без языка запросов, но это под силу только пользователям, обладающим специальными знаниями и недюжинными навыками программирования.
Для хранения временных рядов сегодня всё чаще используются так называемые NoSQL базы данных — как популярные HBase и Cassandra, так и более специализированные решения — например, OpenTSDB, KairosDB и Acunu. Возможно, в некоторых ситуациях такой вариант вполне оправдан, но для решения подавляющего большинства практических задач он вряд ли подойдёт. Все перечисленные выше БД работают на базе инфраструктуры Hadoop, и для их нормального функционирования требуется огромное количество зависимостей. Да и с производительностью у них не всё так гладко, как может показаться на первый взгляд (подробнее об этом см., например, здесь).
Как же решить проблему хранения временных рядов, метрик и статистики? Мы серьезно задумались над этим вопросом, когда подбирали вариант хранения информации о запросах к нашим NS-серверам.
Совершенно неожиданно в обсуждении нашего поста на Хабрахабре один из читателей порекомендовал NoSQL базу данных InfluxDB. Мы попробовали ее — и остались вполне довольны. Своим опытом работы с InfluxDB мы хотели бы поделитьcя в этой статье.
Общая информация
База данных InfluxDB (см. репозиторий на GitHub), написанная на языке Go — продукт новый: первый его релиз состоялся в октябре 2013 года. Она позиционируется как база данных для хранения временных рядов, метрик и информации о событиях.
B качестве низкоуровневого хранилища пар «ключ-значение» в InfluxDB используется база данных LevelDB. Для этой цели можно также использовать RocksDB (по утверждению разработчиков InfluxDB, именно это хранилище показывает наилучшую производительность — см. отчет о тестировании здесь), и LMDB.
Записывать данные в InfluxDB можно различными способами. Во-первых, данные в формате JSON можно передавать через HTTP API. Во-вторых, InfluxDB поддерживает протокол Carbon, используемый в инструменте для обработки и визуализации данных Graphite. В-третьих, данные можно отправлять по протоколу UDP.
InfluxDB может использоваться в качестве бэкенда для Graphite, и благодаря этому можно существенно повысить его производительность. Поддерживается также возможность работы с дашбордом для метрик Grafana (более подробно об этом речь ещё пойдёт ниже).
Несомненным плюсом InfluxDB являются и широкие возможности интеграции с другими программными продуктами — например, инструментом для обработки логов Fluentd, демонами для сбора статистики CollectD и и StatsD, фреймворками для мониторинга Sensu и Shinken.
Установка
Установим Influx DB и посмотрим, как её можно использовать на практике. Процедуры установки и настройки мы будем рассматривать на пример с OC Ubuntu; для других дистрибутивов Linux они могут отличаться (подробности см. в официальной документации).
Выполним следующую команду:
По завершении установки запустим InfluxDB:
По умолчанию InfluxDB использует порты 8083, 8086, 8090 и 8099. Можно использовать и другие порты — для этого потребуется внести соответствующие изменения в конфигурационный файл. Рассмотрим особенности конфигурирования InfluxDB более подробно.
Настройка и конфигурирование
Все настройки InfluxDB хранятся в конфигурационном файле /opt/influxdb/current/config.toml. Они делятся на следующие группы:
[logging] — параметры логгирования (указываются уровень логгирования и имя файла лога);
[admin] — настройки веб-интерфейса (порт, на котором работает внутренний веб-сервер, и путь к файлам веб-интерфейса);
[api] — настройки HTTP API;
[input_plugins] — настройки ввода данных из внешних источников (в InfluxDB можно передавать данные, предназначенные для отправки в Graphite; также в этом разделе можно настроить ввод данных по протоколу UDP).
[raft] — настройки протокола согласования RAFT;
[storage] — общие настройки хранения данных;
[cluster] — настройки работы в кластерном режиме (более подробно они будут описаны ниже;
[wal] — настройки опережающего введения журнала (Write Ahead Logging, WAL).
Создаём базу данных
По завершении установки откроем в браузере страницу localhost:8083. Мы увидим веб-интерфейс для работы с базами данных. Выглядит он так:
Введем теперь логин (root) и пароль (root) (начальные значения можно задать в конфигурационном файле до первого запуска), а затем нажмем на кнопку Connect. Откроется следующее окно:
Графический интерфейс InfluxDB прост и интуитивно понятен. Обратим внимание на некоторые важные моменты, которые следует учитывать при создании первой базы данных.
Чтобы упростить и ускорить чтение данных при запросе, базу лучше разделить на составные части небольшого объема — так называемые шарды (англ. shards) Совокупность шардов, формируемых на основе одного и того же принципа, называется шардовым пространством (англ. shard space).
Создавая базу, нужно указать, какие шардовые пространства будут входить в ее состав. Данные можно делить на шарды, во-первых, по временным отрезкам. Если, например, мы будем хранить в базе информацию о действиях пользователей, то ее удобнее разбивать на временные отрезки — например, данные за каждые 7 дней будут хранится в отдельном шарде. Длина временного отрезка указывается в разделе Duration. В графе Retention указывается срок хранения шарда.
При создании базы данных можно указывать и параметры для работы в кластере. В графе RF (эта аббревиатура означает Replication Factor — фактор репликации) указывается, на скольких узлах должна храниться копия каждого шарда в шардовом пространстве. В графе Split указывается, на сколько шардов нужно делить данные в для конкретного временного промежутка.
Чтобы каждый сервер в кластере был готов к записи «горячих» данных в любой момент времени, значение фактора репликации рекомендуется рассчитывать по следующей формуле:
(RF — фактор репликации, NoS — число серверов)
Алгоритм, лежащий в основе деления данных на шарды, включает следующие шаги:
1. Программа просматривает все шардовые пространства в базе.
2. Затем она проходит все шардовые пространства циклом и ищет пространство, которому соответствуют новые данные.
3. После этого просматриваются все шарды для заданного временного интервала;
4. Если шардов не существует, то будет создано N шардов (N — число, указанное в графе split).
5. Данные записываются в шард с использованием алгоритма hash(series_name) % N.
Рекомендуется устанавливать небольшие размеры шарда по времени (duration).
Если установить для времени хранения шарда (retention) значение inf (т.е. бесконечный), этот шард никогда не будет удалён.
Установив все необходимые настройки, нажмём на кнопку Create Database.
Работа в кластере
В режиме кластера несколько серверов InfluxDB образуют единую систему. Каждый узел кластера может принимать запросы на чтение и запись. Для организации работы в кластере используется протокол согласования RAFT. Понятное и наглядное объяснение принципа его работы представлено в этой презентации.
Согласно официальной документации, в текущем релизе работа в кластере поддерживается лишь в режиме тестирования. Полноценная реализация запланирована на одну из следующих версий (0.9 или 0.10).
В документации ничего не сказано о том, как прописываются настройки кластера в конфигурационном файле, поэтому мы подробно остановимся на этом моменте. Итак, чтобы настроить кластер, нужно:
1. Запустить первый узел InfluxDB со всеми нужными настройками, но без параметра seed-servers в конфигурационном файле (раздел cluster).
2. На втором и всех последующих узлах в качестве значения параметра seed-servers указывается IP-адрес первого сервера, который должен быть запущен самостоятельно:
Если сервер уже был запущен без установки параметра seed-servers, то перед добавлением в кластер нужно удалить с него все данные InfluxDB (путь к данным по умолчанию: /opt/influxdb/shared/data/).
При добавлении нового узла можно указывать IP-адрес любого сервера, уже входящего в состав кластера.
Порт указываем тот же, что и в разделе [raft] (по умолчанию — 8090).
Управление правами пользователей
Возможности управления правами пользователей через графический интерфейс очень ограничены: можно только выполнять простейшие операции добавления и удаления пользователей и разрешать полный (c правами администратора) доступ.
Более тонкие настройки доступа к данным можно устанавливать только через API. Доступ к метрикам реализован в виде регулярных выражений.
В схематичном виде структура запроса выглядит так:
Приведём пример команды для изменения настроек доступа:
Просмотреть текущие правила можно с помощью команды
Из полученного вывода видно, что пользователь grafana может читать все метрики (“*.”), но при этом не может ничего писать (“^$”).
Интеграция с Grafana
Grafana представляет собой удобный дашборд для выборки и визуализации метрик. На русском языке публикаций о нём почти нет, за исключением совсем небольшой заметки на Хабре.
Специально для желающих посмотреть, как работает InfluxDB в связке с Grafana, мы подготовили сценарий (playbook) для Ansible и разместили его на GitHub.
Чтобы осуществить тестовый запуск, клонируйте репозиторий по ссылке выше, в файле hosts укажите IP-адреса машин, которые будут входить в кластер, а затем запустите скрипт run.sh. Обратите внимание, что описание конфигурации Influxdb задаётся в «родном» для Ansible формате YAML, из которого затем генерируется файл в формате TOML.
Заключение
На основании собственного (пусть пока и не очень большого) опыта мы сделали вывод о том, что InfluxDB представляет собой интересное и перспективное решение, которое может быть рекомендовано к практическому использованию. Надеемся, что и у вас по прочтении нашей статьи возникнет желание познакомиться с InfluxDB поближе.
Если кто-то из вас уже использует InfluxDB — приглашаем поделиться опытом в комментариях.
Читателей, которые по тем или иным причинам не имеют возможности оставлять комментарии здесь, приглашаем в наш блог.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
7 мощных баз данных временных рядов
Базы данных временных рядов полностью настраиваются с данными временных меток, которые индексируются и эффективно записываются таким образом, что можно вставить данные временных рядов. Эти данные временных рядов можно запрашивать гораздо быстрее, чем из реляционной базы данных или базы данных NoSQL.
1. InfluxDB
InfluxDB является одной из самых популярных баз данных временных рядов среди DevOps, которая написана в Go. InfluxDB была разработана с самого начала, с целью обеспечить высокомасштабируемый механизм приема и хранения данных. Он очень эффективен при сборе, хранении, запросе, визуализации и выполнении действий с потоками данных временных рядов, событий и метрик в реальном времени.
Она предоставляет политики понижающей дискретизации и хранения данных для поддержания высокой ценности, высокой точности данных в памяти и более низкой ценности данных на диске. Он построен на основе «облачной» технологии для обеспечения масштабируемости в нескольких топологиях развертывания, включая локальную облачную среду и гибридные среды.
Особенности
Так как это открытый исходный код, вы можете загрузить и поднять его на своем сервере. Тем не менее, они предлагают InfluxDB Cloud на AWS, Azure и GCP.
2. Prometheus
Он плотно интегрируется с Grafana для визуализации.
Особенности
У Prometheus есть сотни экспортеров для экспорта данных из Windows, Linux, Java, базы данных, API, веб-сайта, серверного оборудования, PHP, обмена сообщениями и т.д.
3. TimescaleDB
Он может использоваться для мониторинга DevOps, понимания показателей приложений, отслеживания данных с устройств Интернета вещей, понимания финансовых данных и т.д. Можно измерять журналы, события Kubernetes, метрики Prometheus и даже пользовательские метрики.
Владельцы продуктов могут использовать его для понимания производительности продукта с течением времени, что помогает принимать стратегические решения для роста.
Особенности
4. Graphite
Особенности Graphite:
5. QuestDB
Функции QuestDB:
6. AWS Timestream
Как AWS может отсутствовать в списке?
С помощью специализированного механизма запросов можно одновременно запрашивать последние данные и архивные сохраненные данные. Она предоставляет множество встроенных функций для анализа данных временных рядов для поиска полезной информации.
Функции Amazon Timestream:
7. OpenTSDB
Имеет демон временных рядов (TSD) и утилиты командной строки. Демон временных рядов отвечает за хранение данных в HBase или их извлечение из нее. С TSD можно общаться с помощью HTTP API, telnet или простого встроенного графического интерфейса. Для сбора данных из различных источников в OpenTSDB нужны такие инструменты, как flume, collectd, vacuumetrix и т.д.
Функции OpenTSBD:
Заключение
Поскольку в наши дни используются все больше и больше IoT или умных устройств, на веб-сайтах с миллионами событий в день в реальном времени генерируется огромный трафик, увеличивается торговля на рынке, что и привело к созданию база данных временных рядов! Базы данных временных рядов являются обязательным элементом производственного стека для мониторинга.
Большая часть вышеперечисленной базы данных временных рядов доступна для бесплатного использования, поэтому получите облачную виртуальную машину и попробуйте посмотреть, что подойдет именно вам.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Знакомство с InfluxDB и базами данных временных рядов
Авторизуйтесь
Знакомство с InfluxDB и базами данных временных рядов
InfluxDB, база данных временных рядов (TSDB), разработанная InfluxData, в последние несколько месяцев демонстрирует всё большую популярность. Она стала одной из справочников для разработчиков и инженеров, желающих внедрить мониторинг в реальном времени в свою собственную инфраструктуру. Но что именно из себя представляет InfluxDB? Зачем она нужна? Какую ценность вы можете привнести, внедрив InfluxDB в свою среду?
Эта статья — отправная точка для разработчиков, инженеров и ИТ-специалистов, которые хотят изучить InfluxDB, его концепции, случаи использования и реальные приложения.
Для начала поговорим в целом о базах данных временных рядов. О том, что они из себя представляют и чем отличаются от традиционных реляционных баз данных (РБД). После этого рассмотрим концепции, которые определяют InfluxDB. Не знакомы с измерениями, тегами или полями? Всё будет объяснено.
Что такое база данных временных рядов?
БД временных рядов, исходя из названия, представляют собой системы баз данных, специально предназначенные для обработки информации, связанной со временем.
В основном все имеют дело с реляционными базами данных (MySQL или SQL Server). Возможно, вы также имели дело с базами данных NoSQL (MongoDB или DynamoDB). Все они основаны на том, что у вас есть таблицы. Эти таблицы содержат столбцы и строки, каждая из которых определяет запись в вашей таблице. Часто эти таблицы специально предназначены для определённой цели. Одна может быть предназначена для хранения пользователей, другая — для фотографий или видео. Такие системы эффективны, масштабируемы и используются множеством гигантских компаний с миллионами запросов на своих серверах.
Базы данных временных рядов работают иначе. Данные по-прежнему хранятся в «коллекциях», но эти коллекции имеют общий знаменатель: они объединены со временем. Это означает, что для каждой точки, которую вы можете сохранить, у вас есть связанная с ней временная метка.
Возникает вопрос: нельзя ли использовать реляционную базу данных и просто включить в неё столбец с именем «время»? Например, в Oracle есть тип данных TIMESTAMP, который можно было бы использовать для этой цели. Конечно, такое возможно, но это неэффективно.
Зачем нужны базы данных временных рядов?
Три слова: быстрый приём данных.
Системы баз данных временных рядов построены так, чтобы быстро и эффективно принимать данные. Реляционные базы данных тоже имеют большую скорость загрузки данных (от 20 000 до 100 000 строк в секунду). Тем не менее, приём не постоянен во времени. У реляционных баз данных есть один ключевой аспект, который делает их медленными при росте данных — индексы.
При добавлении новых записей в реляционную БД и при наличии в таблице индексов СУБД будет многократно переиндексировать данные для быстрого и эффективного доступа к ним. Как следствие, производительность со временем снижается. При этом увеличивается нагрузка, что приводит к трудностям при чтении данных.
База данных временных рядов оптимизирована для быстрого приёма данных. Такие системы используют индексацию данных, объединённых со временем. Как следствие, скорость загрузки не уменьшается со временем и остается достаточно стабильной (от 50 до 100 тыс. строк в секунду на одном узле).
Специфичные концепции баз данных временных рядов
Кроме высокой скорости приёма, базы данных временных рядов вводят специфичные для этих технологий концепции.
Одной из них является организация хранения данных. В традиционной РБД данные хранятся до тех пор, пока вы не решите их удалить. Учитывая сценарии использования БД временных рядов, вы можете не хранить ваши данные слишком долго: это или слишком дорого, или данные со временем теряют актуальность.
Системы вроде InfluxDB могут позаботиться об удалении данных через определённое время, используя концепцию, называемую политикой хранения. Вы также можете выполнять непрерывные запросы к оперативным данным для выполнения определённых операций. В реляционной БД можно найти эквивалентные операции (например «задания» в SQL), которые могут выполняться по заданному расписанию.
Совершенно другая экосистема
Особенности БД временных рядов хорошо видны, когда речь заходит об их экосистемах. Как правило, реляционные базы данных окружены приложениями, которые подключаются к ним для получения информации или добавления новых записей.
Часто база данных ассоциируется с одной системой. Клиенты подключаются к веб-сайту, который обращается к базе данных для получения информации. БД временных рядов созданы под множество клиентов (программ). Здесь нет простого сервера, обращающегося к БД, но есть куча разных сенсоров (к примеру), выполняющих вставку данных одновременно.
Как следствие, её инструменты были разработаны для того, чтобы предоставить эффективные способы потребления или производства данных.
Потребление данных
Потребление данных часто осуществляется с помощью инструментов мониторинга вроде Grafana или Chronograf. Эти клиенты имеют встроенные решения для визуализации данных и даже для создания пользовательских предупреждений.
Эти инструменты часто используются для создания живых панелей мониторинга, которые могут быть представлены графиками, гистограммами, датчиками или картами окружающего мира.
Производство данных
Производство данных осуществляется агентами, которые нацеливаются на специальные элементы в инфраструктуре и извлекают из них метрики. Такие агенты называются «агентами мониторинга». Вы можете легко настроить их для запроса данных за определённый промежуток времени. Примерами являются Telegraf (который является официальным агентом мониторинга), CollectD или StatsD.
Теперь вы лучше понимаете, что такое базы данных временных рядов и чем они отличаются от реляционных. Пришло время углубиться в конкретные концепции InfluxDB.
Концепции InfluxDB
В этом разделе будут объяснены ключевые концепции InfluxDB и ключевые запросы, связанные с этими концепциями. InfluxDB встраивает свой собственный язык запросов и это заслуживает отдельного пояснения.
Язык запросов InfluxDB
Прежде чем начать, важно знать, какую версию InfluxDB вы используете в настоящее время. По состоянию на октябрь 2019 года InfluxDB выпускается в двух версиях: v1.7+ и v2.0.
InfluxDB v2.0 в настоящее время (на октябрь 2019 года) является альфа-версией и использует язык Flux. InfluxDB v1.7 оснащён языком InfluxQL (а также Flux, если его активировать). Пока лучше использовать InfluxQL, так как Flux не полностью установлен в текущей версии платформы.
InfluxQL — это язык запросов, который очень похож на SQL, и позволяет любому пользователю запрашивать свои данные и фильтровать их. Вот пример запроса InfluxQL:
Дальше будут рассмотрены ключевые концепции InfluxDB, предоставляемые с соответствующими запросами IQL (InfluxQL).
Ключевые концепции InfluxDB
Рассмотрим список основных терминов, которые необходимо знать для работы с InfluxDB в 2019 году.
База данных
База данных — само по себе простое для понимания понятие, потому что вы привыкли использовать этот термин в реляционных базах данных. В SQL-среде БД будет содержать набор таблиц и схем и будет представлять один экземпляр самостоятельно.
В InfluxDB БД содержит набор измерений. Однако один экземпляр InfluxDB может содержать несколько баз данных. В этом его отличие от традиционных систем. Эта логика подробно представлена на графике ниже:
Наиболее распространённые способы взаимодействия с базами данных — это либо их создание ( CREATE DATABASE “devconnected”; ), либо переход в них ( USE devconnected; ) для просмотра коллекций (вы должны быть «в базе данных», чтобы запрашивать коллекции, иначе это не сработает).
Измерение
Как показано выше, база данных хранит несколько измерений (measurement). Для простоты восприятия думайте об измерении как о таблице SQL. Она хранит данные и даже метаданные в разные моменты времени. Данные, которые должны сосуществовать вместе, должны храниться в одном измерении.
Теги и поля
Обратите внимание, есть тонкая разница между тегами и полями.
Для тех, кто впервые начинает работать с InfluxDB, будет трудно понять, чем отличаются теги и поля. Они похожи на «столбцы», где вы можете хранить точно такие же данные. Определяя новый «столбец» в InfluxDB, вы можете либо объявить его как тег, либо как значение, и между ними есть различия.
Самая большая разница между ними заключается в том, что теги индексируются, а значения — нет. Теги можно рассматривать как метаданные, определяющие данные в измерении. Это подсказки, дающие дополнительную информацию о данных, но не сами данные. Поля — это сами данные. В прошлом примере столбец «температура» был бы полем.
Что вам выбрать: тег или поле?
В данном случае стоит выбрать тег. Необходимо, чтобы столбец «местоположение» индексировался и учитывался при выполнении запроса к местоположению.
Хорошей практикой будет держать измерения относительно небольшими, когда речь идёт о большом количестве полей. Всё большее количество полей часто связано с меньшей производительностью. Вы можете создать другие измерения, чтобы сохранить другое поле и правильно его проиндексировать.
Теперь, когда мы добавили метку местоположения в измерение, немного углубимся в таксономию.
Набор тега называется «tag set». Имя столбца в теге называется «tag key». Значения тега называются «tag values». Та же систематика повторяется для полей. Вернёмся к чертежам.
Временная метка
Временная метка (timestamp) — наверное, самое простое для определения ключевое слово. В InfluxDB — это дата и время, определённые в формате RFC3339. При использовании InfluxDB очень часто определяют столбец времени как метку в Unix-времени, выраженную в наносекундах.
Вы можете выбрать формат наносекунд для временного столбца и позже снизить точность, добавляя нули в конец значения, чтобы оно соответствовало формату наносекунд.
Политика хранения
Политика хранения определяет, как долго вы собираетесь хранить ваши данные. Политики хранения определяются для каждой базы данных и их может быть несколько. По умолчанию политика хранения будет autogen и хранит ваши данные вечно. Как правило, базы данных имеют несколько политик хранения, которые используются для разных целей.
Представим, что вы используете InfluxDB для оперативного мониторинга всей инфраструктуры.
Например, вы хотите знать, когда сервер отключается. В этом случае вас интересуют данные, поступающие с этого сервера в настоящий момент или за несколько минут до этого. Вы не заинтересованы в хранении данных в течение нескольких месяцев, поэтому хотите определить небольшую политику хранения: например один или два часа.
Предположим, вы используете InfluxDB для IoT, например для сбора данных, поступающих из резервуара для воды. Позже вы захотите поделиться своими данными с группой научных специалистов, чтобы они могли их проанализировать. В этом случае вы можете хранить данные дольше: например пять лет.
Точка
Точка (point) — это просто набор полей с одинаковой отметкой времени. В SQL это будет выглядеть как строка или как уникальная запись в таблице. Здесь нет ничего особенного.
Случаи использования InfluxDB
Мониторинг DevOps — очень объёмная тема. Всё больше команд вкладывают средства в создание быстрой и надёжной архитектуры, основанной на мониторинге. Начиная от сервисов и заканчивая кластерами серверов, инженеры часто создают стек мониторинга, который обеспечивает интеллектуальные оповещения.
Чтобы узнать больше о мониторинге DevOps, ознакомьтесь со статьёй «Monitoring systemd services in realtime with Chronograf».
С помощью инструментов в начале статьи вы можете создать собственную инфраструктуру мониторинга и принести прямую пользу вашей компании или начинающему предприятию.
Развитие IoT, вероятно, будет революцией, которая произойдёт в ближайшие несколько лет. Предполагается, что к 2020 году более 30 миллиардов устройств будут считаться устройствами IoT. Независимо от того, осуществляете ли вы мониторинг одного устройства или гигантской сети таких девайсов, вам необходимо иметь точные и мгновенные показатели, чтобы вы могли принимать наилучшие решения.
Реальные компании уже работают с InfluxDB для IoT. Одним из примеров может быть WorldSensing, компания, которая нацелена на расширение умных городов с помощью индивидуальных концепций, таких как интеллектуальная парковка или система мониторинга трафика.
Промышленные и умные заводы
Заводы становятся всё более и более связанными. Процесс выполнения задач более автоматизирован, чем когда-либо. Как следствие, возникает очевидная необходимость иметь возможность контролировать каждый элемент производственной цепочки для обеспечения максимальной производительности. Но даже когда машины не выполняют всю работу и задействованы люди, мониторинг временных рядов даёт уникальную возможность донести соответствующие показатели до менеджеров.
Помимо повышения производительности, они могут способствовать созданию более безопасных рабочих мест, поскольку они способны быстрее обнаруживать проблемы.
Ваше собственное воображение
Приведённые выше примеры являются лишь примерами. Ваше воображение — это единственное ограничение для приложений, которые вы можете применить для баз данных временных рядов. Например, временные ряды могут использоваться даже в кибербезопасности.
Идём дальше
В этой статье было рассмотрено, что такое базы данных временных рядов и как они используются в реальном мире. А также много технических терминов, стоящих за InfluxDB.
Хороший совет — создайте что-то сами. Установите InfluxDB, поиграйте с инструментами. Создайте информационную панель, поиграйтесь с запросами, настройте некоторые оповещения. Только так вы сможете сами «пощупать» эту технологию и составить о ней своё мнение.