В качестве четвертого архитектурного варианта мы реализовали средства выполнения тестового набора прямо поверх S3. Этот вариант соответствует архитектуре распределенного управления, представленной на рис. 4. В S3 обеспечивается только низкоуровневый интерфейс put/get, так что все высокоуровневые службы типа обработки SQL-запросов и индексации на основе B-деревьев было необходимо реализовать как часть приложения. Мы включили эти средства в состав библиотеки, поддерживающей основные средства управления базами данных для поддержки выполнения тестового набора TPC-W. Для повышения производительности эта библиотека сохраняла несколько кортежей в одном объекте S3. Кроме того, в этой библиотеке был реализован протокол, синхронизующий паралельный доступ к одним и тем же объектам S3 от нескольких серверов приложений. Для этой цели мы использовали базовый протокол, предложенный в [3]. Этот протокол простым образом реализуется поверх S3. Как и в варианте AWS SimpleDB, протокол поддерживает только согласованность в конечном счете. Более высокие уровни согласованности можно реализовать с использованием других протоколов из [3], но в своем исследовании мы этим не занимались, чтобы не отклоняться от основной цели работы. Для улучшения производительности в серверах приложений выполнялось кэширование объектов S3. В частности, объекты S3, представляющие страницы индекса в виде B-дерева, сохранялись в кэше серверов приложений даже за пределами границ транзакций. Базовый протокол, описанный в [3], применим и для обеспечения корректности при кэшировании страниц данных и индексов.

В [3] для реализации основного протокола поддержки долговечности транзакций и согласованности данных в конечном счете использовалась служба поддержки персистентных очередей Amazon SQS (Simple Queue Service). В описываемом исследовании мы использовали этот подход и реализовали базовый протокол на основе собственной реализации очередей. Наши очереди поддерживались на переменном числе машин EC2 и EBS, чтобы обеспечить сохранность журналов очередей в случае отказов машин. В зависимости от рабочей нагрузки число машин EC2 изменялось от одной до пяти. Период TTL (time to live – время жизни) для кэширования устанавливался в 120 секунд, а интервал установки контрольных точек (определенный в [3]) – в 10 секунд. Установка контрольных точек производилась под воздействием сторожевого таймера (watchdog) [3].

В качестве интегрированного сервера Web, приложений и баз данных использовался сервер Tomcat и библиотека, в которой реализовывались основные контрукции SQL и поддержка согласованности. В заисимости от рабочей нагрузки изменялось число используемых машин EC2.