Alexander RyndinИ вот там то TimesSeries на большой железке ( IBM Power P750 с крутым Storage )


4 юнита - большая железяка )
Спасибо поржал )

Alexander Ryndinочень сильно проиграет Oracle CEP (да и любому другому CEP), стоящему на обычном серваке (Intel Xeon с 2 CPU).


автор 1 billion meter reads
per hour was achieved using 24 compute nodes on Exalogic



277 777*60 *60 =999 997 200

почти милиард

Alexander RyndinДохтаР,

Все зависит от типа нагрузки. Вот пример , где обрабатывается 1 млн. сообщений в секунду. Тип нагрузки там практически тот же.

А Вы не родественник известного тут персонажа Базиста :)

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

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

Alexander Ryndinна небольшой машинке 2 CPU-12 ядер (1/30 Exalogic)

лимоны в секунду на транзакционной базе.

Alexander Ryndin
В общем маркетинг IBM как обычно показывает некорректные сравнение. А вы, похоже, их апологет аля GVF112GVF, но для Informix.





Что касается железа , то IBM вне конкуренции для толстых сабжевых решений.

А что касается СУБД нужно посмотреть )).

Вот и я заинтересовался , что может реально перестрелять Оракл, а не маркенигово.

Буду следить,
АнатоЛой спасибо за наводку.

Хотелось бы еще увидеть вас в теме
http://www.sql.ru/forum/actualthread.aspx?tid=905803

отстрел тролей , попробую взять на себя

Alexander RyndinДохтаРМне как практику вы врядли докажете , что сможете вытянуть

пропущено...

лимоны в секунду на транзакционной базе.Я где-то говорил о транзакционной нагрузке?

В приведенном примере MDM никому и никогда не нужно иметь 1млн. транзакций в секунду в базу.

Вот представьте: стоит у меня дома датчик электричества, и что мне даст снятие информации с него о потребленной энергии каждую секунду? Это просто никому не нужно. А вот суммарное потребление посчитать за каждую минуту (если не час) или найти резкий скачек напряжения - это имеет смысл. В этом и есть смысл Complex Event Processing. Он не складирует весь этот необработанный шлак, который генерится со скоростью 1 млн. сообщений в секунду, а выполняет аггрегацию в оперативной памяти . Вот отсюда и берутся:
Alexander Ryndinна небольшой машинке 2 CPU-12 ядер (1/30 Exalogic) - 1 млн. сообщений в секунду


Интересно сколько срезов в этом ОЛАП кубе ?
Если мы уж говорим об электричестве, еще есть 1 фазные и трехфазные потребители ,
у однофазных потребитетей есть интересная игра , перетяни фазу называется
Еще есть пусковые токи, яркий этому примеры - лифт и сварочный аппарат

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

И вобще я не вижу смысла централизовать обработку потребеления электоэнегнии.
В счетчике можно проц поставить который все соберет и раз
в неделю будет выгружать средние и пиковые значения.

Alexander Ryndin
В приведенном примере MDM никому и никогда не нужно иметь 1млн. транзакций в секунду в базу.



про 1 млн тразнакций в базу я вобще речи не веду.
Я вам соизмеримую статистику доступа пользоваетельских сессий к блокам данных привел.
А если вы собираетесь агрегировать,
то тут нужно так же учесть сериализацию доступа к строкам агрегатов.

И тут мы наверное начнем обсуждать ( в качестве вброса) чьи блокировки работают ( занимаются и отпускаются) быстрее.

Alexander RyndinДохтаРто тут нужно так же учесть сериализацию доступа к строкам агрегатов.
И тут мы наверное начнем обсуждать ( в качестве вброса) чьи блокировки работают ( занимаются и отпускаются) быстрее.1) Эти агрегаты делаются в памяти
2) Тут нет параллельного доступа нескольких пользователей

что то вы темните
Я не пойму , зачем аж 12 ядер ?
Ну допустим 1 - операционка и прочее системное обслуживание.
один агрегирует , а еще за 10 зачем платить ?

Alexander RyndinДохтаРИнтересно сколько срезов в этом ОЛАП кубе ?При чем здесь OLAP-кубы? В CEP это очень похоже на SQL язык - вы запускает некий запрос


Ну а на выходе у вас, по сути, табличка с замерами каждую минуту.


Ну давайте прикинем
customer.name, - 10 + байт
sum(meter.kwh), -4 байта
avg(meter.kwh), - 4 байта
min(meter.kwh), - 4 байта
max(meter.kwh) - 4 байта

36 байт * 1 000 000 + плюс служебной инфы 15 -20 %
Вобщем гигабитная сетка нужна.
И собственно вопрос каким оборудованием собрать всю эту инфу
от дестяков тысяч разрозненных потребителей в одни поток ( TCP соединение) ?

И главное зачем ?


Alexander Ryndin
ДохтаРРади просто суммирования по одному полю я бы даже не начинал такой проект с миллионами сообщений.
У меня большие сомнения, что суммарные срезы дадут возможность каким то образом,
что то оптимизировать в энергоснабжении , или увидеть причины возникающих проблем.
И в конечном итоге окупить вложенные в систему средства.Суммарные срезы с периодом 1 минута более чем достаточны. Но есть еще аварии, воровство электричества (по сути эти fraud-задача) и т.д. Вот эта информация должна быть real-time. И эта вполне решаемая задача без закачивания 1 млн. транзакций в секунду в базу данных.


Мдааааа, вкладывать средства на ветер для поиска единичного воровства , еще тот нанораспил проект

Alexander RyndinДохтаРИ вобще я не вижу смысла централизовать обработку потребеления электоэнегнии.
В счетчике можно проц поставить который все соберет и раз
в неделю будет выгружать средние и пиковые значения.Ну весь мир идет именно к централизации этого процесса.
В США это используют, например, для того, чтобы хитро балансировать использование обычных и альтернативных источников.

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

А что касается воровства, то системное воровство в конкретном месте
вычисляется разницей в учете на подстанции и сумма по потребителям,
потом дополнительно расследуется конкретными людми на местах и получается профит.
Скороть принятия решения тут особо не нужна, электричества на впрок не ненаберешь