К_НаумовНасколько хорошо 1:С работает с распределенными БД ?
ДеняСейчас у нас в репликации около 20 баз.
Гхм... Вот лично я уже совсем запутался. Давайте отделим мух от котлет, прийдем к единой терминологии, а после продолжим обсуждение, не возражаете?

"Распределенные БД" и "репликация" - суть совершенно разные вещи, хотя и для того, и для другого нужны некоторые каналы обмена информацией.

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

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

Достоинства и недостатки.

" Распределенная БД " позволяет экономить место на дисках конкретного компьютера (особенно, если вся совокупная информация занимает много места). Недостаток "распределенной БД" - если один из серверов "попал в состояние комы", получить консолидированные данные, либо ввести данные, логически связанные с данными, находящимися на вышедшем из строя сервере, не удастся. Понятно, что такая схема работы с данными приводит к высоким рискам. Чем больше серверов, тем больше вероятность, что один из них рухнет, и распределенная БД станет недоступной. Примерно так же обстоит дело с количеством удаленных каналов связи. Если выйдет из строя один из каналов связи, распределенная БД может целиком оказаться "в нокдауне". Поэтому распределенные БД используют преимущественно тогда, когда данные на разных площадках существенным образом автономны и слабо связаны с данными на других серверах. В таком случае можно продолжить работу с оставшейся в живых частью распределенной БД, когда один из серверов рухнул, либо вышел из строя канал связи с ним. Стараются разделить данные в распределенной БД таким образом, чтобы по крайней мере ввод и кооректировка информации не была никак связана с данными, находящимися на других серверах. Тогда высокие риски будут относиться только к операциям получения консолидированных отчетов. Последние достижения информационных технологий сводятся к тому, что экономия денег на объемах дисковых носителей за счет повышения рисков недоступности информации, как правило, себя не поравдывает.

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

Справедливости ради следует заметить, что существуют также методы репликации , использующие распределенные транзакции (для MS SQL Server - это "непосредственно обновляемые подписчики"), риски использования которых эквивалентны рискам "распределенных БД".

В качестве справки лирического отступления - СУБД Cache\' имеет весьма развитые механизмы для построения распределенных БД, но не имеет никаких встроенных штатных механизмов для организации "репликации", что меня в своё время сильно расстроило (эта тема обсуждалась здесь, здесь здесь).

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