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

Question

Я создаю систему, которая опрашивает устройства на предмет данных по различным показателям, таким как загрузка ЦП, использование диска, температура и т. Д. С (вероятно) 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 (для создания графиков с локализованными периодами) является обязательным требованием.

Non-Relational (NoSQL)

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

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

Undecided

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

Answer 1

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

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

Исправление

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

2. У вашего стола есть одно серьезное препятствие. Учитывая ваше описание, фактический ПК является (Device, Metric, DateTime). (Пожалуйста, не называйте это TimeStamp, это означает что-то другое, но это незначительная проблема.) Уникальность строки определяется по:

      (Device, Metric, DateTime)
   

   • Колонка Id ничего не делает, она полностью и полностью избыточна.

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

     • Для столбца Id требуется дополнительный индекс, который, очевидно, ограничивает скорость INSERT/DELETE и увеличивает используемое дисковое пространство.

     • Вы можете избавиться от этого. Пожалуйста.

Высота

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

   • (у меня есть только один индекс, а не три; для не-SQL вам могут понадобиться три индекса).

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

     (Server, Device, Metric, DateTime)

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

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

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

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

Еще одна вещь

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

Answer 2

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

1) Устаревание данных

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

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

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

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

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

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

• многомерных агрегаций (например, задания сокращения карт а-ля-Splunk)

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

• 1_2_january2014.data
• 1_2_feb February2014.data
• 1_2_march2014.data

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

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

Answer 5

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

Answer 6

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

Answer 7

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

Я обнаружил, что колоночные базы данных (Google, вы найдете MonetDB, InfoBright, parAccel и т. Д.) Делают потрясающую работу для временных рядов.

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

Answer 8

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

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

Answer 9

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

Answer 10

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

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

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