Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 PostgreSQL vs MsSQL vs Oracle  [new]
iR7
Member

Откуда:
Сообщений: 23
Привет!

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

Дано:
Порядка 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, но с ним очень мало знаком и хотелось бы узнать у профессионалов насколько он подойдет к такой системе?

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

Спасибо
2 окт 12, 23:56    [13259002]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
iR7
Member

Откуда:
Сообщений: 23
iR7
Уметь работать со стендбаями, создавать полные/инкрементарные/версионные Бэконы
Опечатался. Имеются ввиду бэкапы, а не бекон :-)
3 окт 12, 00:00    [13259021]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54768

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

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

PS: Пихать в БД сырые данные только для того чтобы их агрегировать и стереть - грязное
извращение.

Posted via ActualForum NNTP Server 1.5

3 окт 12, 01:54    [13259200]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
iR7,
1. Если логика обработки отдельно взятого события не предполагает рыскания по другим отдельно взятым событиям в пределах интервала 5-20 мин - не грузите отдельные события в реляционную БД - грузите их в "инмемори БД".
2. В реляционную СУБД для постобработки/анализа грузите только агрегированные значения. Глядишь, впишитесь в дешёвые варианты промышленных СУБД.
3 окт 12, 02:20    [13259226]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
iR7
Member

Откуда:
Сообщений: 23
Dimitry Sibiryakov
То, для чего у заказчика есть админ. Потому что без админа такая система не выживет.
Или то, для чего у исполнителя есть программист. Ибо без него оно совсем не взлетит.

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

Свои варианты?
3 окт 12, 02:27    [13259230]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
iR7
Member

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

Очень интересная мысль, можно поподробнее?

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

С точки зрения функционала пользователи должны иметь возможность просмотреть список событий. Это возможно в таком сценарии?
3 окт 12, 02:31    [13259232]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
mad_nazgul
Member

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


Это все про Oracle


iR7
Быть бесплатной или почти бесплатной для корпоративного сегмента


Выбросите этот пункт и берите Oracle...
В противном случае "мучайтесь" с PostgreSQL

<:o)
3 окт 12, 07:57    [13259354]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
DirksDR
Member

Откуда: Пермь
Сообщений: 340
iR7,

автор
При вставке события в базу вызывается триггер/процедура

Вставка событий пачками эффективней, чем поштучно.
В этой связи, не нравится мне вариант с триггерами. Поштучную вставку событий будет тормозить, для вставки пачками триггер будет сложным и "долгоиграющим". По крайней мере MSSQL рекомендует, чтобы триггера были простые и быстрые.
Если id события типа bigint (простой int не проходит, за 30 дней число событий получается около 2млрд),
то альтернативный вариант обработки пачками запоминает id последнего обработанного события и обрабатывает все, что пришло позже. Я за такой вариант, просто, можно управлять запуском (1-2-5 сек), можно разные варианты обработки писать, несколько заданий в параллель сделать для разного типа событий.

автор
1 раз в 5-10-20 минут агрегированные данные реплицируются в центральное хранилище

Пользователи работают с агрегированными данными из центрального хранилища?
Может передавать агрегированные данные туда сразу при обработке пачками (в прилинкованный сервер)? Глядишь, и репликация не потребуется...
3 окт 12, 08:26    [13259380]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
АнатоЛой
Member

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

Очень интересная мысль, можно поподробнее?

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

С точки зрения функционала пользователи должны иметь возможность просмотреть список событий. Это возможно в таком сценарии?

1) Перевожу "in-memory database". В патронташе от SQLite и Apache Derby до Oracle Times Ten и IBM SolidDB.
Просветить и сравнить для ваших нужд не готов.
2) Крутите в ОЗУ оперативные данные, регистрируйте в РСУБД агрегированные, показывайте пользователям детальные за последние 20 минут из in-memory и агрегированные сохранённые из RDBMS. Можете сохранять в файлах оригинальные сырые, чтобы в редких случаях их можно было поднять в in-memory.
3 окт 12, 11:21    [13260312]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
V&N
Guest
iR7, в postgresql из коробки:
- нет job-ов, в какой-то степени, можно заменить pgagent, at, cron;
- нет инкрементальных/версионных бэкапов - использовать pg-rman, walmgr ...
По остальным параметрам, вроде-бы подходит.
Дополнительно использовать In-memory database особо нет смысла,
в postgresql достаточно быстрая вставка (~ 70 ГБ/час, на обычной персоналке + sata)
3 окт 12, 11:50    [13260567]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54768

V&N
в postgresql достаточно быстрая вставка (~ 70 ГБ/час, на обычной персоналке
+ sata)

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

Posted via ActualForum NNTP Server 1.5

3 окт 12, 13:35    [13261477]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
V&N
Guest
Dimitry Sibiryakov, Вы правы, если тупо DELETE.
Многое зависит от прокладки между стулом и клавиатурой, знаний о возможностях конкретной СУБД, архитектуры приложения, ...

Неизвестно в каком виде и разрезах хранятся сырые данные с датчиков.
Возможно получится хранить в базе только агрегированные данные, которые не нужно удалять.
А для работы с детализированными данными, использовать FOREIGN DATA WRAPPERS.
3 окт 12, 14:46    [13262186]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
iR7
Member

Откуда:
Сообщений: 23
mad_nazgul
iR7
Быть бесплатной или почти бесплатной для корпоративного сегмента
Выбросите этот пункт и берите Oracle...

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

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

Почему мучайтесь?
3 окт 12, 16:12    [13262811]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
iR7
Member

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

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

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

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

DirksDR
Пользователи работают с агрегированными данными из центрального хранилища?
Может передавать агрегированные данные туда сразу при обработке пачками (в прилинкованный сервер)? Глядишь, и репликация не потребуется...
К сожалению без репликаци не обойтись. Пользователи работают с агрегированными данными как локального так и центрального хранилища. Но локальная часть системы должна быть доступна всегда независимо от доступности/недоступности центральной части.
3 окт 12, 16:32    [13262973]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11463
iR7
Поэтому пачки к сожалению не пройдут если не сохранить порядок поступления :-(
Вы основы реляционной теории когда-нибудь читали?
3 окт 12, 16:34    [13262981]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
iR7
Member

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

Я правильно понимаю, что данные изначально попадают от робота в in-memory database, где агрегируются и после этого исходная часть попадает в базу или в файл, а агрегированная только в базу?

Хм.. с in-memory пока не сталкивался, так что задам возможно глупый вопрос, но что произойдет с in-memory database в случае сбоя? Как я понимаю все хранящиеся в ней и не слитые в файл/базу данные потеряются, верно?
3 окт 12, 16:38    [13262995]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
iR7
Member

Откуда:
Сообщений: 23
V&N
Дополнительно использовать In-memory database особо нет смысла,
в postgresql достаточно быстрая вставка (~ 70 ГБ/час, на обычной персоналке + sata)
Как я понимаю это простой инсерт в таблицу, без логики и триггеров
3 окт 12, 16:39    [13263005]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
iR7
Member

Откуда:
Сообщений: 23
Dimitry Sibiryakov
Вставка - полбеды. Проблема обычно начинается при последующем удалении.
А как с ним дела у PostgreSQL?
3 окт 12, 16:41    [13263013]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54768

iR7
А как с ним дела у PostgreSQL?

Задай этот вопрос в качестве проверки на профпригодность тому программисту у исполнителя,
который

"найдётся".

Posted via ActualForum NNTP Server 1.5

3 окт 12, 18:25    [13263594]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
йцуке
Member

Откуда:
Сообщений: 102
iR7
Привет!

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


Перед тем как писать самостоятельно, готовые решения по архивации технологических данных смотрели?
Их море. К примеру, Hyper Historian от Iconics, Wonderware Data Historian его схема работы ниже
+
Картинка с другого сайта.


В качестве плюшек: высокая скорость записи, большой объем хранения (зачастую хранят сырые данные в собственном формате, обеспечивающем небольшой объем, обращение извне к ним идет через стандартный интерфейс sql сервера), т.к. используются в АСУ ТП, то генерация событий и тревог является нормой и есть компоненты для этого. Зачастую зачастую есть компоненты для отображения всего в web.
Цена таких решений традиционно пропорциональна количеству записываемых сигналов.
3 окт 12, 19:22    [13263879]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
temp/unlogged tables
Guest
V&N
iR7, в postgresql из коробки:
- нет job-ов, в какой-то степени, можно заменить pgagent, at, cron;
- нет инкрементальных/версионных бэкапов - использовать pg-rman, walmgr ...
По остальным параметрам, вроде-бы подходит.
Дополнительно использовать In-memory database особо нет смысла,
в postgresql достаточно быстрая вставка (~ 70 ГБ/час, на обычной персоналке + sata)

Это если в temp/unlogged tables?
Плюс расположенных на виртуальном диске RAM-Drive, как аналог InMemory DB?
4 окт 12, 00:17    [13264879]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
V&N
Guest
temp/unlogged tables, unlogged - да,
где-то тест выкладывал на 1600 полей и 10000000 записей.
Смысл в рам диске, если в скорость винта не упирается ?
Или Вы считаете что 20 метров в секунду для сата много?

рамдрайв на 70 гиг и на персоналке o_o - дайте попробовать, хотя-бы по ssh на часок-два.
4 окт 12, 02:21    [13265076]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
DPH3
Member

Откуда:
Сообщений: 456
iR7,

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

С такой задачей справится даже MySQL. Никакой логики в БД тут тоже нафиг не надо.
Я бы делал на бесплатной версии DB2, но это уже личное....

Если совсем жалко денег на лицензии и не жалко на зарплаты, то дублирование тоже можно делать через сервер приложений (но это уже извращение).
4 окт 12, 02:44    [13265101]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
iR7
mad_nazgul
В противном случае "мучайтесь" с PostgreSQL

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


"Удобства во дворе".
Особенно все что связано с репликацией и резервным копированием.

А так сама по себе СУБД вполне конкурент Oracle (можно спорить, но это мое мнение ;-)
4 окт 12, 07:42    [13265192]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MsSQL vs Oracle  [new]
RAMDISK
Guest
V&N
temp/unlogged tables, unlogged - да,
где-то тест выкладывал на 1600 полей и 10000000 записей.
Смысл в рам диске, если в скорость винта не упирается ?
Или Вы считаете что 20 метров в секунду для сата много?

рамдрайв на 70 гиг и на персоналке o_o - дайте попробовать, хотя-бы по ssh на часок-два.

Это смотря какой винт, и какой профиль нагрузки создает PostgreSQL при этих вставках. Если винт на 100 МБ/сек в среднем и профиль на 100% Sequential, то да, RAMDISK вряд ли тут поможет.
4 окт 12, 23:22    [13270865]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить