Архитектура ХД для временнЫх данных

Господа, возникла задача организовать хранилище данных. Есть опыт работы с уже существующими БД, но вот с задачей их проектирования меня нелегкая столкнула впервые (ибо вообще я занимаюсь алгоритмами а ля Data Mining)
Выскажите, пожалуйста, свое мнение относительно оптимальной на Ваш взгляд архитектуры БД под следующую задачу:

Серверу поступает информация от кучи разных сенсоров/датчиков и необходимо организовать ее хранение для последующего анализа с целью автоматического принятия каких-либо решений (приоритет №1) и отображения пользователям-операторам (приоритет №2).

Важные аспекты:
1. Допустим, алгоритмы анализа данных неизвестны и им для работы может потребоваться произвольный временной срез/промежуток. Кроме того, для расчетов могут потребоваться данные с нескольких устройств, которые могут иметь разную периодичность подачи данных (см. п.5)
2. Пользователь может задать временной промежуток и ему нужно показать данные за этот период от 1 до N (N<10) устройств. Таких пользователей на сервер может приходиться до 100 чел.
3. Все пользователи хотят видеть также последнее актуальное значение по каждому и датчиков.
4. Количество датчиков и сенсоров может быть в любой момент увеличено "горячим" способом, т.е. архитектура (и сама система работы с БД есс-но) должна предусматривать данную возможность. По прикидкам в месяц может быть до 10-ти таких событий.
5. Данные могут поступать в любой момент, хотя относительно постоянная периодичность имеет место быть. У одних датчиков данные могут поступать в среднем 1 раз в минуту, у других - раз в 15 минут, у третьих - 2 раза в секунду. И все это нужно бережно хранить.
6. Самый критичный параметр для всей этой беды - быстродействие - данные нужно отдавать подсистеме анализа предельно быстро.
7. Количество датчиков/сенсоров в системе от 100 до 10 000 шт.
(8) БД может стать (и скорее всего станет) со временем распределенной.
(9) Сама система со временем может стать "системой реального времени" (и перекочевать на QNX или RHEL MRG, например), соотвественно, требования к быстродействию возрастут.

Ну, или в самом простом виде вопрос можно сформулировать так: "Каковы способы организации БД для хранения большого количества распределенных во времени данных?"

Мне лично кажется, что требования очень схожи с требованиями к БД для АСУ ТП. Кстати, может быть данная задача вообще не для реляционных БД?

P.S. Буду признателен также за любые ссылки на полезные материалы. Например, описания архитектуры БД для чего-нибудь подобного, фондовый рынок, например, или сбор данных со счетчиков электроэнергии.

Спасибо

0

IMHO, на коленке такое будет сложно. Если контора коммерческая - смотреть в сторону покупки iFix или ему подобного

0

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

Неужели не существует адекватного бесплатного (в идеале opensource) решения для хранения временнЫх данных? Не создавать же для каждого показания датчика (или каждой минуты на худой конец) строку таблицы

P.S. За iFix спасибо, не знал.

0

Сообщение от scriptus Не создавать же для каждого показания датчика (или каждой минуты на худой конец) строку таблицы

Именно так и делать. Единственно, в базу выплевывать порциями - в этом случае искать компромисс с актуальностью данных придется

0

Тогда придется в пределах интервала (записи данных в БД) не в БД данные хранить, а программный буфер для каждого девайса создавать на этот период. Тяжеловато, конечно, получится, но что делать.
Аналитическая ценность информации со временем убывает, поэтому в принципе можно прореживание по времени организовать, тогда достаточно компактно получается с точки зрения хранения.

0

В твоем случае можно использовать т.н. секционированные представления (partition views) Передовые серверы БД красиво это умеют

1

Угу, я в принципе так и собирался.
Спасибо.

P.S. Вроде бы реализовал все, что нужно на PostgreSQL. Не самое изящное решение, конечно, получилось, но все что надо ХД делает.

0