Здравствуйте. Возникла задача выбора СУБД с несколькими условиями.
Первым из условий заказчика для выполнения работы является физическое дублирование данных БД на нескольких (не менее двух) машинах (мощных desktop-класса или серверов) в локальной гигабитной сети. Примерная схема представлена на рисунке ниже. Сеть содержит 9 узлов, узлы (1,2), (3,8), (4,5,9) и (6,7) дублируют друг друга (выделены одним и тем же цветом).
Вторым из условий заказчика является логическое распределение данных. На рисунке ниже каждый цвет означает свою часть базы данных (это не ссылочная целостность, скорее разные БД, привожу для полноты). На каждом из узлов установлен клиентский софт, работающий со всей базой данных в целом.



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

pkarklinА почему узлов (4,5,9) - три?потому что три больше двух, а два минимальная избыточность, можно и больше.

Dimitry SibiryakovВопрос, как обычно, а какую СУБД знает топик стартер. Сделать такую хрень можно
практически в любой - вопрос только затрат времени и сил.

а чтобы сразу была распределенная и усилий минимум? писать не мне, выбирать субд мне.

pkarklinНеобходима ли балансировка нагрузки между узлами одного "пула"?
Нет, задача - повышение надежности.
Dimitry Sibiryakov, при прочих равных нужна СУБД с репликацией?

pkarklin0108Нет, задача - повышение надежности.

Тогда, таки непонятно, зачем три узла (4,5,9). И да, бюджет бы стоило огласить.
Ну могут два из трех отказать, хотя шансов меньше, чем откажет один из двух.
А насчет логического разделения мне объяснили так: есть много таблиц, части не связаны, но для клиентского софта это одна база данных

pkarklinТ.е. это ни есть горизонтальное партицирование данных каждой таблицы по нескольким серверам? А клиентскому софту не пофигу, к какому количествую бд обращаться?
Нет, это именно разброс групп связанных таблиц по узлам в сети. Строго говоря не пофигу, нужно же решать задачу проверки доступности узлов сети, иначе нужно хранить информацию обо всех узлах сети, в которых своя БД. С одной БД нужно знать только адрес мастер-узлов.

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

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

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

авторЗадача стоит под заданную область сделать макет такого распределенного софта. Основное требование - надежность.

Надежность - это кластера как с общей СХД, так и географически распределенные, это зеркалирование, репликация и т.п. Когда в ТЗ всплывает "мощных desktop-класса" и гиморная архитектура - ни о какой надежности речи не может идти.
задача - упрощение работы с БД, есть одна БД, ничего не надо настраивать на множество БД, пусть это решает слой СУБД.

Насчет desktop - согласен. Но как размещать два кластера в разных концах страны?

pkarklin, не знаю. Т.е. вы предлагаете если делить, то на разные БД, которые реплицируются сами по себе, отдельно от других?