Доброго времени суток!

Помогите, пожалуйста, выбрать СУБД для системы контроля промышленного оборудования.

В базу будут писаться данные примерно с 1000 объектов по 64-128 байт с каждого раз в секунду. Клиенты - поставщики данных подключаются через интернет по самопальному (предположительно) протоколу, 1000 соединений одновременно.
Чтение из базы восновном предполагается двумя способами параллельно:
- те же 64-128 байт считываются около 4000 клиентов в секунду.
- плюс раз в несколько секунд запрос с обработкой 10-100 Мб и результатом в 10-100К. В том числе, сложные запросы хранимыми процедурами, или, в любом случае, программой на самом сервере, например CGI.
Клиенты запрашивающие данные работают через web-интерфейсы, т.е. будет http сервер, около 4000 одновременных сессий.

Размер базы зависит от требуемого времени накопления (пока не определено), может быть от 2 до 16 Тб.
В базе восновном две большие таблицы занимающие 95% всего размера. Всего таблиц около 30.
Данные восновном числа, BLOB-ов и прочей мультимедии не будет.

Требуется высокая надёжность.
Вероятнее всего linux на 64.

Понятно, что много зависит от железа, но тут можно потратится.
СУБД можно и платную, но только обоснованно, а не "на всякий случай".

В связи с доступом к системе через браузеры, решения упрощающие интеграцию СУБД с системами генерации html приветствуются, хотя это и не главный критерий.

SERG1257Правильно ли я понимаю, что датчик пишет в базу свое событие и читает обо всех событиях, а СУБД у вас - точка входа, куда все пишут и читают.
[/quot]

Нет. Источники данных тоже подключены через интернет, до 1000 источников. данные от них идут только в один конец, но независимо от др-друга. Но вы правы в том, что на стороне сервера можно вначале накопить несколько входящих пакетов, а класть в базу большими порциями. Тогда запись по 64К-128К раз в секунду. Так же правы и в том, что часть данных можно (кроме записи в базу) сразу отсылать другим клиентам.

SERG1257AltCtrlDel - плюс раз в несколько секунд запрос с обработкой 10-100 Мб и результатом в 10-100К. А это что за запрос? Просто любопытно
Создать данные для построения графиков/отчётов. Сгруппировать по временным интервалам. Есть относительно нетривиальные пересчёты, типа, пересчёт с матформулами использующими текущие и ряд предыдущих значений, искать пропуски в данных. Заранее такое в базу записывать проблематично, у клиентов разные критерии анализа и будут появляться новые алгоритмы - новые поля плодить не хотелось бы, хотя тут конкретно смотреть буду.
SERG1257Это похоже взаимодействие с GUI клиента
оно
SERG1257AltCtrlDel может быть от 2 до 16 Тб. это ваши фантазии. Вам понадобится секционирование (ручное на вьюхах или средствами СУБД), а устаревшая часть будет агрегироватся, выгружатся из СУБД, паковатся, засовыватся в дальний пыльный угол и там забыватся.
Секционирование всё равно понадобится. И если разбивать на короткие секции (на квартал), то потом, всё равно, будут иногда встречаться хотелки посмотреть старые данные не прерывая основную работу (желательно) в той же системе. Т.е. придётся восстанавливать частично старые данные по отдельным объектам, если захотят посмотреть.

Dimitry SibiryakovSERG1257устаревшая часть будет агрегироватся
У меня есть подозрение, что эта часть будет устаревать ещё до помещения в базу. На зачем
бы в базе понадобились сырые данные в таком количестве?..


Это обязательное требование. Для "разбора полётов" в случае аварий.

Dimitry SibiryakovДля "разбора полётов" данным не обязательно находиться именно в базе. В виде файлов данные
хранятся гораздо удобнее.
И гораздо проще попадают в потерянные кластеры. Плавали, знаем. Плюс постоянный себе геморой с конвертацией плоских файлов в новые версии.

Сергей АрсеньевЗа какой период времени можно потерять данные от датчиков в случае сбоя?
секунды
Сергей АрсеньевМогут ли датчики связываьтся с несколькими разными (с разными путями доступа) агентами по сохранению информации.
нет. Каналы от датчиков на объектах узкие.
Сергей АрсеньевИ т.п.
А вот это самое интересное. )

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

Ну перезагрузка компа всяко не уложиться. А вот с кластерами, тут я, честно говоря, не разбираюсь.

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

Датчики шлют через интернет на фиксированный IP. В каком смысле мультиплексированным, не совсем понял.


Сергей АрсеньевAltCtrlDelнет. Каналы от датчиков на объектах узкие.
Тут надо понимать, что ремонт канала должен укладываться в эти секунды. или считать допустимым неработоспособность части датчиков.

Скажем так. Разрыв канала связи с датчиком - форсмажор. А вот если серверная часть упадёт - моя проблема.

Сергей АрсеньевА по кластеры почитать надо, чтобы понимать на какие грабли люди уже наступали и где дорожки протоптали.

Не посоветуете ли что и где почитать?

И так никто конретную субд и не предложил. Ну хоть какие то рекомендации? Дельфинчика? Слоника? Огненную птичку? Или только оракл на спарке?

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

Dimitry SibiryakovЛюбой приличный датчик имеет внутренний буфер, достаточный чтобы обойтись пару часов а то
и дней без связи с внешним миром. Пофиг что упало - сервер или канал.

А потом он по быстрому должен всё залить. Что резко увеличивает нагрузку на канал передачи и сервер.

Постоянно накапливать данные и отправлять большими порциями датчик не может т.к. их немедленно должны смотреть клиенты - задержка только неск. секунд на время прохождения.

Кеширование с нескольких объектов для записи в базу сервером обязательно.

SiemarglВ подобных системах почти поголовно стоит MSSQL.

почему?

SiemarglНо исходные слишком шапкозакидательские, чтобы вообще что то ТСу предлагать.

Не флейма ради. Поправте меня, в чём я не прав. Это соответствует хотелкам начальства с небольшим моим "прозапасом", чтоб каждые полгода заново не строить.

Siemargl1. Интеллектуальные датчики в кол-ве 1000 шт. Редкость в принципе. Модель можно?

В стартовом сообщении я не писал что это датчики. Я писал что это объекты, реально ПК. Потом уж, отвечая на вопросы про датчики, сам "датчики" написал чтоб не разжёвывать - каюсь. Объектов с ПК до 1000 штук, это с учётом запаса "на вырост". Каналы узкие у некоторых (GPRS). Данные нужны в онлайне (в том числе), т.е. большими блоками отсылать не катит.

Siemargl2. 4000 читающих клиентов к _пишущей_ БД. Такое и в OLTP редко встретить, не то что в АСУТП.

клиенты по стране разнесены. Я сам предполагаю что реально будет чуть более 2-х читающих на один пишуший, но требуют до 8-ми.
И это не в полном смысле АСУТП - "У" управления никакого нет.

Siemargl3. Кластер и 16Тб. Хотим купить пяток мэйфреймов?

Я написал " (пока не определено), может быть от 2 до 16 Тб". Ну не знаю я как там дальше пойдёт. Понадобится - купят.
Давайте пока ограничимся 2Тб.

Очень критична надёжность, малые потери в случае восстановления.