dbms_photoshopд0kРазработчики все логи забили в виндовый эвент вьюверЗаставь дурака богу молиться - он и лоб разобьет.


А что не правильно ?
Есть стандартное средство хранения логов , которой не справилось с задачей.

dbms_photoshopд0kпо shared nothing полностью поддерживаю.

Я ALL-y как системный архитектор говорю , можете не верить, ваше правоНеплохо бы помнить, что кроме хранилищ есть еще OLTP решения, для которых shared nothing не катит.

Когда начинаешь реализовывать конкретные решения, возможности по масштабированию и оптимизации хранения данных для отчетности конечно супер. Нормального колоночного хранения в Оракле нет (кроме in memory option 12c и псевдо-колоночного храннения с hybrid columnar compression) а по возможностям партиционирования Оракл и рядом не стоял с тем же hadoop.

Зато потом начинаются приколы когда начинается параллельная загрузка данных (для лишнего пафоса именуемая ingestion вместо loading) или когда приходит понимание, что нет никаких ограничений целостности. Вот вообще никаких. И если мартышки смогли запороть проект на MSSQL то с сырыми технологиями биг даты они его точно завалят.

Если надо отчетность по хранилищу с возможностью покрутить данные в excel (slice and dice), то что-то дешевле по стоимости владения чем MSSQL крайне тяжело придумать.

Возвращаясь к сильно нагруженным OLTP, сомневаюсь что у Оракла есть серьезные конкуренты.



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

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

зы Кто то уже зарегал мой серый ник
.

dbms_photoshop
зы. А в чем причина излишней скромности, чтоб не зарегаться самому? Никто ж не требует указывать ФИО.

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

kinky catdbms_photoshopБыло бы интересно встретить use-case, что вот мы перевели высоконагруженную OLTP ACID систему с Oracle на MySQL cluster и снизили стоимость владения на столько-то.
ну чудес не бывает, mysql cluster это все лишь mysql с параллельностью (партиционирование вроде там и так есть), плюс архитектурные недостатки всех sharing nothinig, когда надо что то собрать accross nodes, большой джоин например).

Офтоп
Оптимизатор Informix еще 15 лет назад великолепно делал правильные планы
по межнодовому джоину через дблинки и ничего лишенего по сети не ганял.
Я НЕ говорю что он панацея как СУБД , но оптимизатор у него по приличнее
современного ораклового .
Ораклу даже по прошествии 15 лет , после остановки развития Informix
до его стоимостного оптимизатора еще расти и расти.

-2-д0kshared nothing архитектура самое то.shared nothing это не архитектура, а ее отсутствие. Активно применялась, когда прямая связь была не по карману.

Прямая межхостовая кластреная связь всегда и везде была быстрее
и дешевле маршрутизируемой аналогичной скорости до появления
инструкций аппаратной виртуализации в процессорах.
После появления инструкций аппаратной виртуализации, она всеравно
дешевле , но сильно ограничивает полет мысли облачных системных архитекторов.
К аржхитектуре shared nothing прямые или марштуризируемые связи
соотносятся так же, как парус с паровым двигателем, дизелем или атомным реактором.

приблизительно так ...

AmKadд0kХно оптимизатор у него по приличнее
современного ораклового
А мне было бы интересно посмотреть примеры сравнения. Не холивара ради.

Когда то в информиксовской ветке, кажется под эгидой Дениса Журавлева
проводилось сравнение одинаковой структуры таблиц в оракле и информиксе
и сравнивались планы запросов от стоимостных оптимизаторов.

В работе мне часто приходилось сравнивать таблицы
на разных серверах я ганял left outer join через дблинк.
Информикс всегда работал в десятки раз быстрее.

Еще + информиксу , они индексы строит в тысячи раз быстрее не лазя
попусту в темп если оперативной памяти хватает
у него нет тараканов с http://dba-blog.blogspot.com/2005/08/pgamaxsize-hidden-parameter.html

Но информикс чистый блокировочник и софт для него нужно писать
очень пунктуально , а не куяк куяк и в продакшин.
Информикс подхода куяк куяк и в продакшин не прощает в принципе.

NETClientд0kХИнформикс подхода куяк куяк и в продакшин не прощает в принципе.
Какой злой дядька, этот твой Информикс!

Поэтому он и сдох, не выдержал конкуренции от гавнокодеров на рынке труда.
Они вместе с Лари забросали его шапками

NETClientд0kХ,

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

особенно ОЛТП , с лост апдетами.
Разница меджу блокировчником и ораклом для ОЛТП
только в том что блокировочник ведет себя всегда в режиме
ораклового select .... for update
на всю транзакцию.


Попробуйте в оракле for update используя
where current of
закомитить запись и сделать следующий фетч.
Привет ORA-01002

Если вы комитетесь в курсоре и не используете
where current of
то за первым же комитом внутри цикла
вы слетаете с блокировок и хваленой оракловой
консистентности в говнокод.

NETClientд0kХс лост апдетами.Я и слов-то таких не знаю.
д0kХfor update используя
where current
И такого в продакшене никогда не использовал.

извините за глупый риторический вопрос ,
А зачем вам нужен именно оракл для решения задач.

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

NETClientд0kХРазница меджу блокировчником и ораклом для ОЛТП
только в том что блокировочник ведет себя всегда в режиме
ораклового select .... for update
на всю транзакцию.Ты хочешь сказать что в твоем блокировочнике блокировка держится и после окончания select-чтения до момента фиксации или отката транзакции?

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

Там по сути такая же конститентность , но наоборот,
не по факту старта запроса , а исходя из имеющихся блокировок
по факту фетча конкретной записи внутри транзакции.
Люди которые пишут многопоточный софт на С++ или Джаве понимают
принципы защиты бизнеслогики блокировчниками , без
срачей о рестарте транзакций.

Поищите по форуму , очень интересное чтиво , о
вычислении алгоритма автоматического рестрта транзакций в оракле разных версий. :)

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

NETClientЯ-то всегда по своему наивному говнокодерству считал, что блокировочник вешает блокировку только на время чтения для обеспечения согласованности данных.

Блокировчник вешает блокировку на всю глубину транзакции
и даже дальше если ему это сказал программист.

Оракл по умолчанию никак не гарантирует согласованность
данных между несколькими запросами внутри транзакции.

Только одним джоином на транзакцию в for update курсоре с изменением
по where curent of или переходом в сериализейбл, что совсе грустно для
много пользовательского режима.

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

NETClientд0kХВозмите любой блокировочник , поставьте режим грязного чтения
ваш результат будет не хуже.Как?! Но ведь согласованное чтение закоммиченных данных и грязное чтение - не одно и то же.
А абзац про консистентность - прости, не осилил.

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