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

185

Я создаю систему, которая опрашивает устройства на предмет данных по различным показателям, таким как загрузка ЦП, использование диска, температура и т. Д. С (вероятно) 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
Очень правильный вопрос, я сам задумался над этим, является ли реляционная БД правильным способом хранения структуры данных, которая на самом деле является иерархической (структура SNMP). Иногда, когда я пишу запрос для извлечения даже тривиальных данных, запрос слишком сложен, я чувствовал, что данные должны быть искажены в форме, которая не является собственной. Например, сопоставление ifnames и их индексов, предположительно, тривиальная задача, оба являются дочерними для одного родительского oid. Но то, как он хранится в реляционной БД, не относится к его первоначальной структуре, и я считаю, что более эффективно хранить его в иерархической форме.
Бенни
«Для пользователя, записывающего 10 показателей для 3 устройств каждые 5 минут в течение года, у нас будет чуть менее 5 миллионов записей». Не * 3 10 * 365 * 24 * 12 примерно равна 3 млн , которые не только до 5 миллионов?
Матье Бордере

Ответы:

152

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

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

коррекция

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

PerformanceDBA
источник
1
@PerformanceDBA. Не могли бы вы использовать предложенную схему для установки, которая должна обрабатывать ~ 3 миллиона тактов с частотой 1 минута? Как бы вы заказали ПК для такого стола? Разве Device, Metric, DateTime не создадут фрагментацию и не заставят СУРБД разделять страницы? Вместо этого, если сначала поместить DateTime, это уменьшит фрагментацию (я предполагаю, что время вставки упорядочено), но делает чтение хуже.
Маркоб
1
@Buchi. Я использую Sybase ASE. Но это не проблема платформы (конечно, высокие платформы обеспечивают производительность, которая на порядок выше, чем нижняя; на три порядка лучше, чем Oracle, но это не главное), построение диаграммы из таблицы " работает "на любой платформе. Используйте правильный инструмент для работы. СУБД - это инструмент базы данных, а не инструмент построения графиков. gnuplot, Apple Numbers (или, если вам нравится платить в десять раз больше, вдвое меньше, MS Excel) - это инструменты построения диаграмм, а не базы данных. В наши дни мы используем слои инструментов для получения результата, монолит - это динозавр.
PerformanceDBA
1
@marcob. Ваш вопрос хороший, но на него нельзя ответить в комментариях. Если вы откроете новый вопрос и напишите мне (зайдите в профиль), я отвечу на него. Для быстрого ответа здесь. (1) ~ 3 миллиона метрик. Отлично, чем больше, тем лучше, он красиво распределяет точки INSERT, а ваши гарантируют конфликты на последней странице. Сервер многопоточный, да? Разделите таблицу. Используйте FILLFACTOR и оставляйте место для вставок, и, таким образом, избегайте разбиения страницы. (2) ~ 3 Милл означает, что метрики не нормализованы, если вы исправите это, он будет еще быстрее.
PerformanceDBA
1
@marcob. (3) Я использую данный индекс именно для распределения вкладышей под нагрузкой, что гарантирует отсутствие конфликтов. (4) Таким образом, мой метод получает как вставки без конфликтов, так и высокую производительность при SELECT.
ПроизводительностьDBA
2
@Loic. С какой стати любой человек, у которого есть инвестиции (данные; код) в платформу SQL, которая обрабатывает данные временных рядов легко и с очень высокой производительностью (как подробно описано в ответе), перейдет на TSDB без SQL; неизвестная скорость для чего-либо, кроме данных временных рядов? Почему тот, у кого есть требование, превышающее только временные ряды, не использует платформу SQL? Ум поражает. TSDB быстрее, чем Relational, только в печальном случае, когда данные хранятся в БД, но не нормализованы в Relationally. Например. когда Idстолбцы используются, как «ключи». Как советуют "теоретики".
ПроизводительностьDBA
21

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

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

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

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

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

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

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

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

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

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

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

Паоло Боццола
источник
7

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

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

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

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

Ravindra
источник
1
Не могли бы вы объяснить, как таблица "нормализована"? У Маркуса есть ошибка в таблице, но это не ошибка нормализации.
PerformanceDBA
поправлюсь, таблицы нормализованы в традиционном смысле. Я имел в виду денормализованный в том смысле, что сценарий использования содержит все данные в одной таблице.
Равиндра
4

Создайте файл, назовите его 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

hellomichibye
источник
Я написал пост в блоге на эту тему. с помощью Google Translate вы можете найти это полезным: blog.michaelwittig.info/die-spaltenorientierte-datenbank-kdb
hellomichibye
3

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

Сунил
источник
2

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

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

Фил Джексон
источник
2

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

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

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

фаэтон
источник
2

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

Хуан Асеньо
источник
«СУБД не подходят под задачу» - почему бы и нет? code.facebook.com/posts/190251048047090/…
Автор Zathrus Writer
1

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

monch1962
источник
Да, Zabbix хорош и уже интегрируется с мониторингом SNMP. Zabbix может использовать MySQL или PostgreSQL и работает более или менее из коробки на Ubuntu.
Дирк Эддельбюттель
Спасибо, у меня есть знания о Zabbix и многих других инструментах SNMP. Однако я развиваю этот проект как учебный процесс, в обсуждаемой здесь теме и многих других аспектах. Хороший момент, хотя!
Маркус Уайброу
0

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

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

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

Адам
источник
добавьте timescaledb в этот список сейчас
PirateApp