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

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

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

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

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

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

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

• автоматизированные данные продувки (см. Рэдис истечения срока действия команда)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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