Привет!

Подскажите пожалуйста, какой движок БД выбрать.
Есть проект, необходимо создать систему, которая бы обрабатывала данные от нескольких тысяч датчиков в реальном времени. Нужно выбрать БД для хранения и обработки множества ежесекундных событий.

Дано:
Порядка 2000-5000 датчиков присылают 10 событий в минуту (~ 333.33 - 833.33 событий в 1 сек).
Каждое событие должно быть занесено в БД и в идеале обработано по получению, т.е. вызывать определенную логику в зависимости от типа события и значения показаний (но в реальности можно использовать пакетную пост-обработку 1 раз в 1-2-5 сек).
Агрегированные значения должны обрабатываться аналитическим модулем и в свою очередь вызывать дальнейшую реакцию со стороны пользователя.
В качестве клиентской части предполагаются web-приложения. Использование win-приложений возможно только на сервере.
Со стороны БД наиболее частыми будут операции по вставке данных с датчиков, но чтение из таблицы с их значениями будет достаточно редким (1 раз в 10 мин а то и реже), основные чтения будут из агрегированных таблиц.
Объем данных - 10-100 Gb

Изначально идея такая:
Датчики отправляют свои события некоему серверу на определенный порт.
На сервере этот порт слушает робот, который занимается разбором каждого события на значения и эти значения вставляет в базу.
При вставке события в базу вызывается триггер/процедура, который смотрит на вставляемые значения и в зависимости от того что именно вставляется - выполняет некую небольшую логику. (альтернативный вариант - данные вставляются as is и обрабатываются пачкой каждые 1-2-5 сек). И так с каждым событием.
Затем с обработанными результатами работают пользователи, процедуры, задания, и прочие роботы.
1 раз в 5-10-20 минут агрегированные данные реплицируются в центральное хранилище
1 раз в сутки данные старше 30 дней стираются.

База должна:
Иметь хранимые процедуры, триггеры, вьюхи, индексы, задания
Уметь работать со стендбаями, создавать полные/инкрементарные/версионные Бэконы
Иметь встроенные механизмы репликации
Быть бесплатной или почти бесплатной для корпоративного сегмента
Работать под Windows (желательно)
Уметь работать на виртуалках и иметь совместимость с VeamBackup (желательно)

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

Собственно, что посоветуете и почему?

Спасибо

iR7Уметь работать со стендбаями, создавать полные/инкрементарные/версионные Бэконы
Опечатался. Имеются ввиду бэкапы, а не бекон :-)

Dimitry SibiryakovТо, для чего у заказчика есть админ. Потому что без админа такая система не выживет.
Или то, для чего у исполнителя есть программист. Ибо без него оно совсем не взлетит.
Найдется и то и другое. Тут вопрос не в ресурсах, а скорее в том что более правильно для этой системы.
Dimitry SibiryakovPS: Пихать в БД сырые данные только для того чтобы их агрегировать и стереть - грязное извращение.

Свои варианты?

АнатоЛойiR7,
1. Если логика обработки отдельно взятого события не предполагает рыскания по другим отдельно взятым событиям в пределах интервала 5-20 мин - не грузите отдельные события в реляционную БД - грузите их в "инмемори БД".
Очень интересная мысль, можно поподробнее?

АнатоЛой2. В реляционную СУБД для постобработки/анализа грузите только агрегированные значения. Глядишь, впишитесь в дешёвые варианты промышленных СУБД.
С точки зрения функционала пользователи должны иметь возможность просмотреть список событий. Это возможно в таком сценарии?

mad_nazguliR7 Быть бесплатной или почти бесплатной для корпоративного сегмента
Выбросите этот пункт и берите Oracle...
Уже пробовали, по началу замахнулись на Enterprise а потом получили массу удовольствия в позе Бобра, когда встал вопрос с лицензированием.

mad_nazgulВ противном случае "мучайтесь" с PostgreSQL

Почему мучайтесь?

DirksDR Вставка событий пачками эффективней, чем поштучно. Согласен, но дело в том что события хранятся не просто так и та очередность с которой они поступили влияет на дальнейшую логику и анализ сбоев. Поэтому пачки к сожалению не пройдут если не сохранить порядок поступления :-(

DirksDR В этой связи, не нравится мне вариант с триггерами. Поштучную вставку событий будет тормозить, для вставки пачками триггер будет сложным и "долгоиграющим". Так и происходит сейчас, что не может не удручать

DirksDR то альтернативный вариант обработки пачками запоминает id последнего обработанного события и обрабатывает все, что пришло позже. И если происходит сбой между запомнил и обработал - данные (от 333 до 4166 событий) теряются, верно?

DirksDR Я за такой вариант, просто, можно управлять запуском (1-2-5 сек), можно разные варианты обработки писать, несколько заданий в параллель сделать для разного типа событий. В принципе интересная мысль, надо ее обдумать

DirksDR Пользователи работают с агрегированными данными из центрального хранилища?
Может передавать агрегированные данные туда сразу при обработке пачками (в прилинкованный сервер)? Глядишь, и репликация не потребуется... К сожалению без репликаци не обойтись. Пользователи работают с агрегированными данными как локального так и центрального хранилища. Но локальная часть системы должна быть доступна всегда независимо от доступности/недоступности центральной части.

АнатоЛой2) Крутите в ОЗУ оперативные данные, регистрируйте в РСУБД агрегированные, показывайте пользователям детальные за последние 20 минут из in-memory и агрегированные сохранённые из RDBMS. Можете сохранять в файлах оригинальные сырые, чтобы в редких случаях их можно было поднять в in-memory.
Я правильно понимаю, что данные изначально попадают от робота в in-memory database, где агрегируются и после этого исходная часть попадает в базу или в файл, а агрегированная только в базу?

Хм.. с in-memory пока не сталкивался, так что задам возможно глупый вопрос, но что произойдет с in-memory database в случае сбоя? Как я понимаю все хранящиеся в ней и не слитые в файл/базу данные потеряются, верно?

V&NДополнительно использовать In-memory database особо нет смысла,
в postgresql достаточно быстрая вставка (~ 70 ГБ/час, на обычной персоналке + sata) Как я понимаю это простой инсерт в таблицу, без логики и триггеров

Dimitry SibiryakovВставка - полбеды. Проблема обычно начинается при последующем удалении.
А как с ним дела у PostgreSQL?