Хранение данных временных рядов, реляционных или нет?

Я создаю систему, которая проверяет устройства на данные по различным показателям, таким как загрузка процессора, использование диска, температура и т.д. (возможно) с 5-минутными интервалами с использованием SNMP. Конечной целью является предоставление визуализации пользователю системы в виде графиков временных рядов.

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

Что лучше, реляционная база данных (например, MySQL или PostgreSQL) или нереляционная или база данных NoSQL (например, MongoDB или Redis) в отношении производительности при запросе данных для графического отображения.

Реляционная

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

Поля: id fk_to_device fk_to_metric metric_value timestamp

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

SELECT metric_value, timestamp FROM data_instances
    WHERE fk_to_device=1 AND fk_to_metric=2

Число строк в этой таблице будет:

d * m_d * f * t

где d - количество устройств, m_d - это накопительное число показателей, записываемое для всех устройств, f - это частота, при которой данные опрошены, а t - это общее количество время, которое система собирает данные.

Для пользователя, который записывает 10 показателей для 3 устройств каждые 5 минут в течение года, у нас будет только 5 миллионов записей.

Индексы

Без индексов на fk_to_device и fk_to_metric при сканировании этой непрерывно расширяющейся таблицы потребуется слишком много времени. Поэтому требование индексирования вышеупомянутых полей, а также timestamp (для создания графиков с локализованными периодами) является обязательным.

Нереляционный (NoSQL)

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

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

Еще не решил

Будет ли реляционное решение с правильной индексацией уменьшаться до обхода в течение года? Или привлекает ли основанная на коллекции структура NoSQL (которая соответствует моей ментальной модели сохраненных данных)?

Ответы

Ответ 1

Определенно реляционная. Неограниченная гибкость и расширение.

Две поправки, как в концепции, так и в приложении, сопровождаются повышением.

  • Это не "отфильтровать ненужные данные"; он выбирает только необходимые данные. Да, конечно, если у вас есть индекс для поддержки столбцов, определенных в предложении WHERE, это очень быстро, и запрос не зависит от размера таблицы (захват 1000 строк из таблицы из 16 миллиардов строк является мгновенным).

  • У вашей таблицы есть одно серьезное препятствие. Учитывая ваше описание, фактический PK (Device, Metric, DateTime). (Пожалуйста, не называйте это TimeStamp, это означает что-то еще, но это небольшая проблема.) Столбец Id полностью и полностью избыточен. Уникальность строки обозначается:

       `(Device, Metric, DateTime)`

    Столбец Id ничего не делает, он лишний (не избыточный). Дополнительный индекс для поддержки столбца Id, очевидно, препятствует скорости INSERT и добавляет к используемому дисковым пространствам, вы можете избавиться от него.

  • Теперь, когда вы устранили препятствие, вы, возможно, не узнали его, но ваша таблица находится в шестой нормальной форме. Очень высокая скорость, с одним индексом на ПК. Для понимания прочитайте этот ответ из заголовка Что такое шестая нормальная форма?.

    • (У меня есть только один индекс, а не три, а на не-SQL - три индекса).

    Я имею ту же таблицу (без ключа Id, конечно). У меня есть дополнительная колонка Server. Я поддерживаю несколько клиентов удаленно.

       `(Server, Device, Metric, DateTime)`

    Таблица может использоваться для поворота данных (т.е. Devices сверху и Metrics вниз или поворота) с использованием точно такого же кода SQL (да, переключите ячейки). Я использую таблицу для создания неограниченного количества графиков и диаграмм для клиентов с их производительностью сервера.

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

    • Это позволяет мне создавать Charts Like This, шесть нажатий клавиш после получения файла статистики мониторинга от клиента, используя одну команду SELECT. Обратите внимание на сочетание и совпадение; ОС и сервер на одной диаграмме; различные Сводки. Конечно, нет ограничений на количество матриц статистики и, следовательно, диаграмм. (Используется с разрешения клиента.)

    • Читатели, которые не знакомы со стандартом для моделирования реляционных баз данных, могут найти IDEF1X Notation.

И последнее, но не менее важное: SQL - стандарт IEC/ISO/ANSI. Бесплатное ПО на самом деле является не-SQL; мошенничать использовать термин SQL, если они не предоставляют стандарт. Они могут предоставлять "дополнительные услуги", но они отсутствуют.

Ответ 2

Нашел очень интересные вышеупомянутые ответы. Попытка добавить еще несколько соображений.

1) Старение данных

Управление временными рядами обычно требует создания политики старения. Типичный сценарий (например, сервер сервера мониторинга) требует сохранения:

  • 1-секундные необработанные образцы в течение короткого периода времени (например, в течение 24 часов)

  • 5-минутные подробные совокупные образцы в течение среднего периода (например, 1 неделя)

  • 1-часовая деталь над этим (например, до 1 года)

Хотя реляционные модели позволяют точно (моя компания реализовала массивные централизованные базы данных для некоторых крупных клиентов с десятками тысяч серий данных), чтобы управлять им соответствующим образом, новая порода хранилищ данных добавляет интересные функции, которые нужно изучить, например:

  • автоматическая очистка данных (см. команду Redis 'EXPIRE)

  • многомерные агрегирования (например, задания сокращения карты a-la-Splunk)

2) Сбор в режиме реального времени

Еще важнее то, что некоторые нереляционные хранилища данных по своей сути распределены и обеспечивают гораздо более эффективный сбор данных в реальном времени (или почти в реальном времени), что может быть проблемой для РСУБД из-за создания горячих точек (управление индексацией при вставке в одну таблицу). Эта проблема в пространстве РСУБД обычно решается с возвратом к процедурам пакетного импорта (так было в прошлом), в то время как технологии no-sql преуспели в массивной сборке и агрегации в реальном времени (см., Например, Splunk, упомянутые в предыдущих ответах).

Ответ 3

В таблице есть данные в одной таблице. Таким образом, отношение к нереляционному - это не вопрос. В основном вам нужно прочитать много последовательных данных. Теперь, если у вас достаточно памяти для хранения данных, сопоставимых с годами, то ничего не стоит использовать Redis/MongoDB и т.д.

В основном базы данных NoSQL будут хранить ваши данные в одном месте на диске и в сжатой форме, чтобы избежать множественного доступа к диску.

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

Инструменты, такие как Splunk, используют резервные копии NoSQL для хранения данных временных рядов, а затем с помощью карты уменьшить для создания агрегатов (что может быть, что вы хотите позже). Поэтому, по-моему, использование NoSQL - это вариант, поскольку люди уже пробовали его для подобных случаев использования. Но миллион строк приведет к ползучести базы данных (может быть, нет, с приличным оборудованием и правильными конфигурациями).

Ответ 4

Если вы смотрите на пакеты GPL, RRDTool - это хороший взгляд. Это хороший инструмент для хранения, извлечения и графического отображения временных рядов. Ваш прецедент выглядит точно так же, как временные ряды данных.

Ответ 5

Создайте файл, назовите его 1_2.data. идеализированная идея? что вы получаете:

  • Вы сохраняете до 50% пространства, потому что вам не нужно повторять значение fk_to_device и fk_to_metric для каждой точки данных.
  • Вы сохраняете еще больше места, потому что вам не нужны индексы.
  • Сохраните пары (timestamp, metric_value) в файл, добавив данные, чтобы получить заказ по метке времени бесплатно. (предполагая, что ваши источники не отправляют данные заказа для устройства).

= > Запросы по timestamp работают очень быстро, потому что вы можете использовать бинарный поиск, чтобы найти нужное место в файле для чтения.

если вам нравится, что еще более оптимизировано, начните думать о том, чтобы разделить ваши файлы следующим образом:

  • 1_2_january2014.data​​li >
  • 1_2_february2014.data​​li >
  • 1_2_march2014.data​​li >

или используйте kdb + из http://kx.com, потому что они делают все это для вас:) Столбец-ориентированный - это то, что может вам помочь.

Появляется облачное ориентированное по столбцам решение, поэтому вы можете взглянуть на: http://timeseries.guru p >

Ответ 6

Это проблема, которую нам пришлось решать в ApiAxle. Мы писали сообщение в блоге о том, как мы это сделали, используя Redis. Он не был там очень долго, но он оказался эффективным.

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

Ответ 7

Я думаю, что ответ на этот вопрос должен в основном касаться того, как ваша база данных использует хранилище. Некоторые серверы баз данных используют ОЗУ и Диск, некоторые используют только ОЗУ (необязательно Диск для настойчивости) и т.д. Наиболее распространенные решения SQL Database используют память + дисковое хранилище и записывают данные в макет на основе Row (каждый вставленный исходный текст записывается в том же физическом местоположении). Для хранилищ временного хранения в большинстве случаев рабочая нагрузка похожа: Относительно низкий интервал большого количества вставок, в то время как чтение основано на столбцах (в большинстве случаев вы хотите прочитать ряд данных из определенного столбца, представляющих метрику)

Я нашел Columnar Databases (google it, вы найдете MonetDB, InfoBright, parAccel и т.д.) делают потрясающую работу для временных рядов.

Что касается вашего вопроса, который лично я считаю несколько недействительным (как и все обсуждения, использующие термин отказа NoSQL - IMO): Вы можете использовать сервер базы данных, который может говорить на SQL с одной стороны, что делает вашу жизнь очень простой, поскольку все знают SQL в течение многих лет, и этот язык был усовершенствован снова для запросов данных; но по-прежнему используют ОЗУ, процессорный кэш и диск с ориентацией на столбцы, что делает ваше решение максимально подходящим для Time Series

Ответ 8

5 Миллионов рядов на сегодняшний день нет данных о потоках. Ожидайте, что данные будут находиться в ТБ или ПБ всего за несколько месяцев. На данный момент РСУБД не масштабируются для задачи, и нам нужна линейная масштабируемость баз данных NoSql. Производительность будет достигнута для столбчатого раздела, используемого для хранения данных, добавления большего количества столбцов и меньше типов строк для повышения производительности. Использовать открытую работу TSDB над HBASE или MapR_DB и т.д.

Ответ 9

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

Ответ 10

Вы должны заглянуть в База данных временных рядов. Он был создан для этой цели.

База данных временных рядов (TSDB) - это программная система, оптимизированная для обработки данных временных рядов, массивов чисел, индексированных по времени (время datetime или datetime).

Популярный пример базы данных временных рядов InfluxDB