Все более широкое распространение сервис-ориентированной архитектуры приложений, коммунальных компьютерных служб и "облачных" сред приводит, с одной стороны, к возрастающей привлекательности этих подходов для разработчиков и пользователей приложений баз данных, а другой стороны (возможно, в качестве следствия) – к повышающейся интенсивности соответствующих исследований в сообществе баз данных. В этих исследованиях развиваются и/или пересматриваются многие идеи, методы и алгоритмы, которые использовались при организации систем баз данных в течение десятилетий, и все это представляется мне потрясающе интересным.
По сути дела, такие исследования ведутся в двух направлениях, которые, судя по публикациям, развиваются практически независимо: "облачные" средства управления аналитическими данными и "облачные" системы поддержки транзакционных приложений баз данных. Первому направлению, в частности, посвящены статьи
,
Джо Хеллерстейна и др. ,
Ави Зильбершаца и др. .
Я старался комментировать свои переводы этих статей, по поводу одной из них написал отдельную заметку , частично обсуждал предлагаемые подходы в статье , но, похоже, что следует провести специальный анализ этого направления, постараться более подробно классифицировать и сравнить имеющиеся подходы.
По поводу второго направления мы тоже публиковали переводы наиболее интересных статей:
,
Даниелы Флореску и Дональд Коссмана .
В этой статье нас интересуют возможности реализации средств типа систем баз данных поверх "облачного" хранения данных. В этом контексте невозможно избежать уровня строгой согласованности. Основное наблюдение, на котором основывается исследование, описываемое в статье, состоит в том, что не все данные требуется обрабатывать на одном и том же уровне согласованности. Например, в Internet-магазине для информации о кредитных картах и состоянии счетов, естественно, требуются более высокие уровни согласованности, а данные о предпочтениях пользователей (например, пользователи, покупающие данный товар, также покупают то-то и то-то) можно обрабатывать на более низких уровнях согласованности.
Это разграничение является важным, поскольку в облачной системе хранения данных согласованность означает не только корректность данных, но и реальный размер расходов на выполнение транзакций.
Стоимость конкретного уровня согласованности можно измерить в терминах числа системных вызовов, требуемых для его поддержки. Поскольку существующие платформы обеспечивают только базовые гарантии, дополнительные уровни согласованности (значительно) повышают стоимость выполнения каждой операции. Аналогично, стоимость несогласованности данных можно измерить в терминах процентного соотношения числа некорректных операций, выполняемых из-за поддержки более низких уровней согласованности. Это процентное соотношение часто можно точно отобразить в соответствующие денежные расходы (например, убытки в связи с компенсацией ущерба от ошибочно выполненных заказов или потерей заказчиков). Объемы таких расходов обычно хорошо известны компаниям, предоставляющим подобные услуги.
Нахождение правильного баланса между стоимостью, согласованностью и доступностью является нетривиальной задачей. В крупномасштабных системах обеспечение высокого уровня согласованности приводит к высокой стоимости транзакций и сниженному уровню доступности , но позволяет избежать убытков от некорректно выполненных операций. Низкий уровень согласованности означает более низкую стоимость выполнения операций, но может привести к большим убыткам (например, при продаже товаров в Internet-магазине сверх имеющихся запасов). Эта ситуация усложняется тем, что упомянутый баланс зависит от нескольких факторов, включая семантику приложений. В этой статье мы предлагаем путь к обходу этой дилеммы за счет использования динамической стратегии поддержки согласованности: снижение требований к согласованности, когда это возможно, (например, это не приведет к большим убыткам) и повышение их, когда это разумно (например, убытки могут оказаться слишком большими). Такая адаптация управляется моделью стоимости и разными стратегиями, которые диктуют требуемое поведение системы.
Мы называем этот подход рационализацией согласованности (Consistency Rationing) по аналогии с рационализацией запасов (Inventory Rationing). Рационализация запасов – это стратегия управления запасами, при которой запасы отслеживаются с разной точностью в зависимости от наличного числа инвентарных объектов. Следуя этой идее, мы разделяем данные на три категории (A, B и C) и обращаемся с каждой категорией по-своему в зависимости от обеспечиваемого уровня согласованности.
Категория A содержит данные, нарушение согласованности которых привело бы к крупным убыткам. К категории C относятся данные, (временная) несогласованность которых является приемлемой (т.е. либо несогласованность данных вызовет лишь небольшие убытки, либо в действительности несогласованность не возникает). Категория B включает все данные, требования к согласованности которых изменяются во времени в зависимости, например, от реальной доступности некоторого элемента. Обычно такие данные параллельно изменяются многими пользователями и часто являются узким местом в системе. В этой статье мы фокусируемся на категории B. Именно для этой категории можно добиться оптимального соотношения расходов на выполнение операций и обеспечиваемого уровня согласованности. Мы описываем несколько сценариев использования, обосновывающих выделение такой категории данных B. Затем мы излагаем модель стоимости системы и обсуждаем различные стратегии динамического изменения уровней согласованности в зависимости от потенциальных убытков. Эти стратегии направлены на минимизацию общей стоимости выполнения операций над "облачной" системой хранения данных. Наши эксперименты с "облачным" сервисом, реализованным поверх службы S3 компании Amazon, показывают, что динамические политики, которые описываются в этой статье, могут принести значительную экономию затрат. Основным вкладом статьи является следующее: