Рис. 2. Архитектура 28msec
На рис. 2 показана архитектура, разработанная для решения новой проблемы оптимизации. Если сравнить рис. 1 и рис. 2, то на первый взгляд архитектуры кажутся похожими. Но между ними имеются существенные различия:
Проблема согласованости данных решается не на уровне хранения, а на прикладном уровне. На нижнем уровне поддерживается только крупномасштабное распределенное хранение данных за счет использования, например, Amazon S3.
Согласованность на среднем уровне достигается путем применения распределенных протоколов типа тех, которые предлагаются в [15]. Отсутствует какой-либо объект, контролирующий весь доступ к данным. Вместо этого, все серверы приложений, которые производят доступ к данным, придерживаются общих соглашений при чтении и обновлении данных, хранимых на нижнем уровне.
На всех уровнях можно использовать дешевую аппаратуру. Все уровни разрабатываются в расчете на возможность масштабирования до тысяч, если не миллионов машин. Архитектура в целом разрабатывается таким образом, что в любой момент времени допускается выход из строя любого узла. В нижнем звене отказоустойчивость достигается за счет репликации данных и предоставления гарантий только слабой согласованности (согласованности "рано или поздно", eventual consistency). На верхних уровнях машины работают без сохранения состояния, так что худшее, что может произойти при выходе машины из строя, – это потеря работы транзакций, активных к этому времени.
По существу, в архитектуре с рис. 2 исчезает традиционная СУБД. Основные функциональные средства СУБД, т.е. управление транзакциями и обработка запросов, переносятся на прикладной уровень.
Можно выполнять программные средства прикладного уровня и уровня представления на машине конечного пользователя. Процессы, выполняемые на обоих этих уровнях, не сохраняют состояние, и допускается аварийное завершение любого из этих процессов в любой момент времени.
Эта архитектура реализована компанией в продукте Sausalito.