Реализационные альтернативы
Архитектура в основывается на предположении об использовании службы хранения данных, обеспечивающей гарантии согласованности "в конечном счете". Более высокие уровни согласованности достигаются за счет использования дополнительных служб и протоколов. В последнее время появилось несколько систем, которые сами обеспечивают гарантии согласованности более высокого уровня (например, PNUTS компании Yahoo ).
В PNUTS поддерживается более развитый API с операциями типа Read-any, Read-latest, Test-and-set-write (required version) и т.д. С использованием этих примитивов можно реализовать сессионную согласованность прямо поверх "облачной" службы без потребности в дополнительных протоколах и очередях. Средствами такого API невозможно реализовать сериализуемость, но в PNUTS имеется операция Test-and-set-write (required version), на основе которой можно реализовать оптимистическое управления параллелизмом доступа к данным категории A. Описываемые в статье средства управления метаданными, сбора и обработки статистики и поддержки политик можно было бы легко приспособить для использования и в такой среде. Но, к сожалению, Yahoo PNUTS не является общедоступной системой. Поэтому мы не имели возможности более детально проработать реализацию и/или включить эту систему в состав своих экспериментов. Тем не менее, разработчики PNUTS утверждают, что, например, Read-any является более дешевой операцией, чем Read-latest. Следовательно, в этой системе поддерживается такой же баланс между стоимостью и согласованностью, и к PNUTS можно было бы применить рационализацию согласованности для оптимизации стоимости и производительности.
Еще одной новой системой является Microsoft SQL Data Services . В этой службе в качестве базовой системы используется MS SQL Server, а сама служба основана на схемах репликации и балансировки нагрузки. За счет использования MS SQL Server система может обеспечивать строгую согласованность. Однако в этой системе имеются сильные ограничения: данные не могут распределяться по нескольким серверам, а транзакции не могут распространяться на несколько машин.
Поэтому масштабируемость системы ограничена.
Рационализацию согласованности можно было бы реализовать и внутри Microsoft SQL Data Services. В частности, введение категорий A и C, а также простых стратегий типа Политики разъединения могло бы помочь повысить производительность. Однако поскольку в этом случае строгая согласованность достигается более дешевым способом (не требуется обмен сообщениями между серверами), выигрыш, скорее всего, был бы далеко не так велик, как в реальной распределенной среде, где объем данных может возрастать неограниченным образом, и данные могут распределяться между несколькими машинами.
Наконец, рационализация согласованности могла бы хорошо подойти и для традиционных распределенных систем баз данных, в частности, для кластерных решений. Если ослабление согласованности является приемлемым, рационализация согласованности может помочь уменьшить число сообщений, требуемых для обеспечения строгой согласованности. И в этом случае можно было бы прямо применить большинство компонентов нашей системы.
