Слабая согласованность
В большинстве крупных Web-ориентированных магазинов для достижения высокой доступности и обеспечения восстановления после аварийных отказов используется репликация баз данных OLTP, обычно в глобальной сетевой среде. Однако, похоже, что никто не собирается платить за транзакционную согласованность в глобальной сети. Как отмечалось в разд. 2, распространенным рефреном в Web-приложениях является «конечная согласованность» [Bre00, DHJ+07]. Обычно сторонники такого подхода выступают за разрешение несогласованности не техническими средствами; например, дешевле предоставить кредит недовольному клиенту, чем поддерживать стопроцентную согласованность. Другими словами, реплики, в конечном счете, становятся согласованными, по-видимому, тогда, когда система переводится в пассивное состояние.
Должно быть понятно, что конечная согласованность невозможна без обеспечения транзакционной согласованности над общей рабочей нагрузкой. Например, предположим, что транзакция 1 фиксируется в узле 1 и аварийно завершается или теряется в узле 2. Транзакция 2 читает результаты транзакции 1 и пишет результаты в базу данных, что приводит к распространению несогласованности и загрязнению системы. При этом, очевидно, должны существовать рабочие нагрузки, для которых конечная согласованность достижима, и было бы интересно попытаться найти такие рабочие нагрузки. Однако, как отмечалось выше, результаты авторов показывают, что удаление поддержки транзакций – блокировок и защелок – из систем баз данных в основной памяти приводит к резкому повышению производительности.
