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

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 является мошенническим, если они не соответствуют стандарту. Они могут предоставить «дополнительные», но они отсутствуют основы.

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

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

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

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

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

• Более 1 часа (например, до 1 года)

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

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

• многомерные агрегации (например, map-Reduce Job a-la-Splunk)

2) Коллекция в реальном времени

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

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

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

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

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

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

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

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

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

• 1_2_january2014.data
• 1_2_february2014.data
• 1_2_march2014.data

или используйте kdb + с http://kx.com потому что они делают все это для вас :).

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

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

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

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

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

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

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

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

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

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

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

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