Согласованность "рано или поздно" и хранение данных
Интересно, что значительная часть публикаций, посвященных согласованности "рано или поздно", фокусируется на семантике операций чтения и записи. Например, в недавней статье Вернера Фогельса (Werner Vogels) разъясняются многие понятия из области согласованности "рано или поздно", но обсуждение ведется в контексте клиентов, систем хранения данных и операций модификации.
В статье про Amazon Dynamo затрагивается много интересных тем и показывается, каким образом в Dynamo сохраняются BLOB'ы с доступом к значениям по ключу. Кроме того, в подразделе 4.4 про версии данных обсуждается использование операций "добавить покупку в корзину" и "удалить покупку из корзины" и то, как эти операции фиксируются в BLOB'ах, хранение которых поддерживает Dynamo. Даже если истории версий переупорядочиваются, покупки, добавленные в корзину, не будут потеряны, если только соответствующая версия BLOB'a не откажет вместе с другими версиями. Случайно удаленные покупки появятся снова.
Системы хранения сами по себе не могут обеспечить коммутативность, требуемую для создания устойчивых систем, функционирующих с применением асинхронных контрольных точек. Для обеспечения возможности переупорядочивания нужны бизнес-операции. Система Dynamo не делает этого сама по себе. За семантику согласованности "рано или поздно" и коммутативность отвечает приложение Shopping Cart, работающее поверх системы хранения Dynamo.
По мнению авторов, настало время отказаться от изучения согласованности "рано или поздно" в терминах операций модификации и систем хранения. Реальные результаты удается получить только при исследовании семантики операций уровня приложения.
