mad_nazgul,

у постгре родовая травма в части поддержки multiversion concurrency control.
на вакууме далеко в высонагруженных системах не уедешь.
Хотя его (вакуум) и пытаются как-то приводить в чувство....
И, думаю, что у любой системы к которой приложил руки Джим Старки, такой проблемы нет в столь болезненной форме.
Т.е., не только у Oracle database с этим сейчас более-менее приемлемо.

Не помрет сбер от замены субд. Горе обычно от ума, а не от смены поставщика самого по себе, бывает...

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

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

даже если вы сможете свою архитектуру построить так, чтобы она жила совсем без update-а,
не выглядит как самое разумное брать систему с дорогим insert-ом,
в расчёте на высокую нагрузку в части именно этого самого insert-а.

mayton,
упор делается на "эластичную масштабируемость" с сохранением транзакционных гарантий.

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


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

Именно вот это на текущий глубоко не актуально и беспредельно не интересно.

Вся псевдоинженерия построения ПО за последние 55-65 лет сумела целиком и плавно перетечь из состояния надежды и ожидания -
"а вдруг мы всё-таки сможем построить", математическим, или еще каким чудесным образом с помощью Аджайла,
ПО без багов, к убеждению, что "ПО без багов не бывает ни при каких обстоятельствах".

Начиная с этого момента приоритеты и предпочтения располагаются где-то на перпендикуляре от критики по части надежности и т.п.

Дело не столько в том, что ни Oracle ни Postgres не позиционируют свое ПО, как годное для работы на станции "Мир",
сколько в том, что при выборе такой странной, малопонятной и полубессмысленной штуковины как СУБД, может оказаться
несопоставимо важнее гарантия вида: "Это да, работаем мы как умеем, но будьте верены, ни завтра, ни послезавтра, вас не бросим".

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

Dimitry Sibiryakov,

mvcc - это всего лишь зонтик, шапочная идея общего вида.
Ее реальное исполнение может выражаться если не тысячами, то десятками несовпадающих реализаций.
Известно, что первая реализация от IBM просто не была выпущена именно потому, что авторы признали
фактические ее характеристики негодными для боевого использования даже для тех мизерных объемов,
под которые проектировалась система в 70е.

Признанный по суду умершим Джим Грей очень долго, почти до последнего дня считал, что mvcc это не просто отстойная
в инженерном отношении конструкция, которую принципиально нельзя заставить работать быстро, из-за неизбежно необходимого
сборщика мусора (хотя считать так уже после выхода Oracle 7 было более чем странно), но негодная для баз данных в
формально-математическом отношении конструкция, содержащая в себе логическую ошибку, и поверх этого вообще нельзя построить правильный ACID.

А сейчас не просто все, кто не имел версионности раньше, как-то ее пристроили себе, а и практически нет новых проектов, которые начинались бы не с mvcc в той или иной форме.
mvcc стал де-факто стандартным способом думать об устройстве субд.