Как хранить многолетние временные ряды 100 x 25 Гц - Sql Server или база данных временных рядов

Question

Я пытаюсь определить возможные способы хранения 100 каналов данных с плавающей запятой 25 Гц. Это приведет к 78 840 000 000 точек данных в год .

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

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

• Как бы вы обработали эти данные?

• Существуют ли в Sql Server функции или схемы таблиц, которые могут обрабатывать такое количество данных временных рядов?

• Если нет, существуют ли сторонние расширения для сервера Sql для эффективной обработки гигантских временных рядов?

• Если нет, существуют ли базы данных временных рядов, которые специализируются на обработке таких данных, но обеспечивают естественный доступ через службы отчетов Sql, .Net и Sql?

спасибо!

Answer 1

Вы можете проверить Infobright Community или Enterprise Edition, я думаю. Это ориентированное на столбцы хранилище, предназначенное для аналитических целей и больших (как говорится, уже существующих установок до 30 ТБ) и хорошей степени сжатия.

Загрузчик данных также работает довольно быстро, и для ETL-инструментов (Talend, kettle и т. Д.) Есть разъемы.

Общественная версия доступна бесплатно на условиях GNU GPL, но позволяет добавлять данные только через собственный загрузчик. Корпоративная версия поддерживает добавление / обновление по одной строке через DML.

Еще одно преимущество, которое вы можете использовать со всеми инструментами, поддерживающими соединения MySQL.

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

Я использую его для сравнительно небольшого (пока) объема данных бизнес-транзакций в аналитических целях, используя R в качестве инструмента анализа данных через интерфейс mysql и скрипты python (numpy) в качестве некоего ETL.

Минусы: Отсутствие официальной поддержки utf-8, агрегирование по значениям функций (выберите месяц (дата из ...)) еще не реализовано (план: июль 2009, AFAIK), но для этого я использую ETL.

Ссылка: http://www.infobright.org/Download/ICE/

Answer 2

Набор функций, который вы описываете, предназначен для аналитического куба. Проверьте службы аналитики от Microsoft, если вы находитесь в этой части технического мира:

http://msdn.microsoft.com/en-us/library/ms175609(SQL.90).aspx

Поскольку модель , которую вы описываете, вам необходимо реализовать модель Kimball (стандартная модель хранилища данных) с измерением Time. Я столкнулся с этой проблемой хранения файлов журналов мультимедиа некоторое время назад.

Удачи.

Answer 3

Полагаю, вам нужен произвольный доступ к серии данных. Идея, которую я уже использовал для таблицы данных об осадках, состоит в том, чтобы подразделить весь набор данных на меньшую часть, чтобы создать запись на каждые несколько минут или даже одну минуту. Затем вы можете извлечь этот все еще большой массив из БД и получить доступ непосредственно к необходимой части, вы можете найти прямую корреляцию между смещением по времени и байтовым смещением.

Answer 4

Я бы разделил таблицу, скажем, по дате, чтобы разбить данные на крошечные биты по 216,000,000 строк в каждой.

При условии, что вам не нужна статистика за весь год, это легко обслуживается индексами.

Скажем, запрос типа " даст мне среднее значение за данный час " будет считаться секундами.

Answer 5

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

Answer 6

Рассматривали ли вы HBASE или Open TSDB. Вы также можете взглянуть на Кассандру

Answer 7

Рассматривали ли вы базу данных временных рядов, как http://opentsdb.net?

Answer 8

У вас есть

A. 365 x 24 x 100 = 876 000 часов сигналов (все каналы) в год

B. каждый сигнал содержит 3600 * 25 = 90000 точки данных

Как насчет того, чтобы хранить данные как одну строку на сигнал, со столбцами для сводной статистики / статистики запросов для поддерживаемых в настоящее время вариантов использования и blob сжатого сигнала для будущих?