Рационализация согласованности в облаках

       

Сценарии использования


Потребность в разных стратегиях поддержки согласованности данных легко выявляется в различных приложениях и уже исследовалась в других контекстах (например, в , ). Ниже мы представляем различные сценарии, в которых можно было бы применить рационализацию согласованности.

Internet-магазин. Допустим, что на основе "облачной" службы хранения построен традиционный Internet-магазин. Программное обеспечение типичного Internet-магазина сохраняет различные виды данных . Например, имеются данные о профилях пользователей и информация о кредитных картах, данные о продаваемых продуктах и записи о предпочтениях пользователей (например, "пользователи, покупающие данный товар, также покупают то-то и то-то"), а также журнальная информация. Эти примеры уже показывают, что имеются разные категории данных в зависимости от их значимости и потребности в согласованности. Информация о кредитных картах пользователей и ценах товаров должна поддерживаться очень тщательно. В то же время, данные о предпочтениях пользователей и журнальная информация могут быть утрачены без какого-либо серьезного вреда (например, если возникает аварийный отказ системы, и данные из кэша не выталкивались на диск).

Разработчики такого Internet-магазина могли бы использовать рационализацию согласованности следующим образом:

  1. Учетная информация считается относящейся к категории данных A, и доступ к таким данным осуществляется при соблюдении гарантий строгой согласованности (т.е. сериализуемости).

  2. Данные о наличном количестве товаров относятся к категории данных B. При наличии достаточно больших запасов система допускает некоторую несогласованность данных. Если объем запасов становится ниже некоторого порога, доступ к данным производится с соблюдением гарантий строгой согласованности, чтобы избежать продаж сверх имеющихся запасов.

  3. Предпочтения покупателей и журнальная информация классифицируются, как данные категории C. Системе не требуется видеть последнее по времени состояние большинства таких данных, а для их изменения не обязательно нужно предоставлять монопольный доступ к ним.


Поскольку общая стоимость поддержки функционирования такого Internet-магазина в "облачной" среде определяется стоимостью выполнения отдельных операций, применение рационализации согласованности непременно снизит общую стоимость за счет использования во всех возможных случаях более дешевых операций, минимизируя в то же время затраты, вызываемые несогласованностью данных.

Той же модели функционирования, что и Internet-магазины, следуют системы резервирования билетов в театры и кино, а также системы бронирования авиабилетов. Единственным отличием является то, что затраты на устранение последствий несогласованности (например, продаж лишних билетов) могут оказаться гораздо более высокими, чем в случае Internet-магазина. Преимущество рационализации согласованности состоит в том, что она позволяет разработчикам согласовать функцию стоимости и стратегии адаптации для оптимизации общих операционных расходов. В нашем подходе транзакции не обязаны работать с данными только одной категории, а могут охватывать несколько категорий данных (подраздел 4.4). Это позволяет разделять (рационировать) данные для оптимизации общих расходов с использованием любой схемы разделения.

Система поддержки проведения аукционов. Для онлайновой системы поддержки проведения аукционов типичным является то, что предмет, продаваемый с аукциона, набирает популярность на финальных стадиях своей продажи. Наибольший интерес для аукционеров представляют последние минут продажи предмета с аукциона. В этот период времени текущая цена предмета должна точно соответствать последнему предложению аукционеров, и она должна изменяться при соблюдении гарантий строгой согласованности. Если до конца продажи предмета с аукциона остается еще несколько суток, то предлагаемая цена может изменяться с использованием более низких уровней согласованности без оказания на систему какого-либо эффекта.

В системе проведения аукционов эту информацию можно использовать для реализации различных стратегий для поддержки актуальных данных о предмете, продаваемом на аукционе.


Если аукцион заканчивается в ближайшем будущем (например, через один или два часа), для этих данных должна обеспечиваться строгая соглсованность. И наоборот, если до конца аукциона остается еще много времени, для данных об предмете аукциона достаточно соблюдение более низких гарантий согласованности.

Различие между сценариями системы поддержки аукциона и Internet-магазина состоит в том, что выбор протокола согласованности производится на основе времени, а не значимости данных. В данном случае именно время используется в качестве порога, определяющего, какого рода гарантии согласованности следует выбрать. В отличие от этого, в примере с Internet-магазином в качестве порога использовалась значимость элемента данных.

Совместное редактирование. Средства совместного редактирования (Collaborative Editing) позволяют людям одновременно работать над одними и тем же документами или исходными текстами программ (к таким средствам относятся, например, Google Docs, системы управления версиями, Wiki и т.д.). Основная функциональность такой системы состоит в выявлении конфликтов, возникающих в процессе редактирования, и отслеживании истории изменений. Традиционно такие системы работают на уровне строгой согласованности. Если система обнаруживает конфликт, то от пользователя обычно требуется его устранение. Только после устранения конфликта пользователю предоставляется возможность внести изменение, если к этому времени не образовался какой-либо другой конфликт. Хотя в реальных ситуациях могут иметься некоторые части документа, часто изменяемые участниками процесса редактирования (например, цитаты из какой-либо статьи), люди обычно стараются организовать материал таким образом, чтобы избегать конфликтов с самого начала. Поэтому для большинства частей документа конфликты маловероятны, и не требуется никакого управления параллелизмом. В отличие от этого, для тех частей, которые часто изменяются несколькими участниками, лучше всего было бы соблюдать гарантии строгой согласованности, чтобы избежать всех конфликтов.

В отличие от предыдущих примеров, в данном случае выбор протокола согласованности основывается на вероятности конфликтов, в не на значимости или времени. В нашей общей политике, описываемой в подразделе 5.1, проблемы этого случая разрешаются путем автоматического применения стратегии, основанной на частоте обновлений.


Содержание раздела