При рассмотрении геораспределенной базы данных, предпочтительно с репликацией, мы должны учитывать компромиссы между предпочтением A (доступность) или C (согласованность) (при наличии раздела WAN), иначе L (задержка) или C (согласованность) (без разделения WAN).
Теперь, если ваше приложение может терпеть умеренную задержку, имея сильную магистраль WAN, вы должны пойти на согласованность (для которой предназначен dbms), в противном случае, если приложение может выдержать случайную устаревание и периодическое отключение в WAN, перейдите к доступности.
Затем встает вопрос о том, как обеспечить согласованность, доступность и требования к задержке для вашего приложения. То, что я понял, согласованность в реплицированных DBMS происходит через синхронную связь, где обеспечение доступности в основном уменьшает свойство согласованности (что сейчас предлагают системы NoSQL). Тем не менее, обеспечение требования к задержке для такого рода dbms остается открытым вопросом как для исследователей баз данных, так и для систем (я думаю, !!).
Подробнее на http://danweinreb.org/blog/improving-the-pacelc-taxonomy
Что мне больше всего понравилось, так это то, что подобные вопросы возникали перед всем сообществом. Это реальные требования, и у нас до сих пор нет соответствующих решений. Переход на новую или открытую архитектуру из системы, такой как Oracle, не является простым решением. Кажется, такие гиганты, как Google, все еще ищут правильный ответ. Смотри http://research.google.com/archive/spanner.html