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

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

166
database non-relational-database nosql relational-database time-series

10 ответов

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

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

коррекция

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

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

       (Device, Metric, DateTime)

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

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

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

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

Высота

  1. ответ с что такое шестая нормальная форма ? движется вперед.

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

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

      (Server, Device, Metric, DateTime)

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

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

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

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

Еще Одна Вещь

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

142

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

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

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

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

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

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

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

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

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

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

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

19

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

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

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

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

7

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

3

создайте файл, назовите его 1_2.данные. наблюдать странные идеи? что вы получаете:

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

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

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

  • 1_2_january2014.данные
  • 1_2_february2014.данные
  • 1_2_march2014.данные

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

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

3

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

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

2

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

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

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

2

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

2

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

1

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

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

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

1