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

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

В рассматриваемой системе хотят вообще СУБД заменить на in-memory БД или все же задействовать in-memory только для read-only данных (как пример, но не ограничиваясь, НСИ)? А то вот мне не понятно, например, зачем серверу приложений постоянно обращаться к БД, за теми же справочниками клиентов, а не сохранить его в кэше. Ну а если ребут, то да - прочитаем с диска и наполним кеш.

Хотя, я думаю, посыл поста был не в том, что in-memory плох, а в том зачем кластер, если все можно в одном ящике, тем более довольно мощном (мне кажется к 256 ядер должно и соответственно памяти прилагаться). Если я правильно понял, то полностью согласен, да и вообще очевидные во многом вещи-то.

З.Ы. Помню, когда еще плотно занимался WebLogic, Oracle предалагала идею очередей сообщений без персистентности на диск, а с сохранением в распределенный кэш. Т.е. идея в том, что у нас несколько десятков серверов и, если вероятность отказа всех одновременно очень мала (ну там резервирование по питанию и т.д.), то зачем использовать энергонезависимую память, если можно просто резервировать сообщения в энергозависимойпамяти на других машинах (хотя и по сети, что наверное даже медленнее, чем диск). Но вот не взлетело, такой реализации JMS (АПИ Java для работы с очередями сообщений) мы так и не дождались.

любое изделие  in-memory СУБД имеет смысл в том случае, когда запросы на чтение значительно, очень значительно преобладают перед запросами на внесение/изменение данных, иначе журнал транзакций уровняет условия. Как верно подмечено - случай НСИ. Но не транзакционные системы.

Посыл был в том, что лучшая в смысле производительности и эффективности транзакционная система на планете на текущий момент одна, это IBM  IMS в одном экземпляре, не в кластере, её результат пока никем не превзойдён, имхо. Там интересное соотношение по типу запросов.
Но как утверждают специалисты лаборатории IMS - значительное превосходство платформы можно продемонстрировать в самых тяжёлых условиях - выполняя update данных.

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

А вы говорите, что "нет приличных специалистов в стране". Есть! Есть приличные специалисты! Смогли же построить систему, которая плохо работает на 256-ядерной установке! А это задача не каждому по плечу! Слава Всевышнему, есть чем нам ответить всяким злопыхателям. И пусть они заранее трепещут!...

По существу. Я что-то давно не встречал тех, кто надеются, что кластер будет работать быстрее, чем ящик. Кластер работает лучше только в случае, когда (по разным причинам) начинает иметь значение скорость переключения контекста адресного пространства, и в тестируемой системе это делается слишком расходно. Кластер в таком случае просто позволяет уменьшить количество таких переключений. Но это реликтовая на сегодняшний день ситуция, рассматривать ее, я думаю, не имеет смысла.

И конечно, кластера лучше продаются, а это, батенька, аргумент такой, что всем аргументам аргумент!

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

вот сравнение скорости переключения контекста супротив скорости сетевого взаимодействия в кластере я бы с удовольствием послушал.
Кластер выигрывает только тогда, когда задача замечательно параллелится и отдельные подзадачи не пересекаются по данным. Тогда да, бинго и кластер. Взаимодействие между нодами сведено к минимуму, данные на каждом узле кластера свои... Если задача не параллелится, или есть необходимость работы с одними и теми же данными на разных узлах в одно и то же время, то кластерная инфраструктура начинает усложнятся, накладные расходы возрастать, что неизбежно ведёт к проигрышу одному серверу
ИМХО.

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