Транзакционные данные в облаках – синергия идей СУБД и распределенных систем

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

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

Майкла Стоунбрейкера и др. и
,
Джо Хеллерстейна и др. ,
Эрика Фридмана и др. ,
Ави Зильбершаца и др. .

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

По поводу второго направления мы тоже публиковали переводы наиболее интересных статей:

Майкла Стоунбрейкера и др. и
,
Даниелы Флореску и Дональд Коссмана .

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

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

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

Мы называем этот подход рационализацией согласованности (Consistency Rationing) по аналогии с рационализацией запасов (Inventory Rationing). Рационализация запасов – это стратегия управления запасами, при которой запасы отслеживаются с разной точностью в зависимости от наличного числа инвентарных объектов. Следуя этой идее, мы разделяем данные на три категории (A, B и C) и обращаемся с каждой категорией по-своему в зависимости от обеспечиваемого уровня согласованности.

Категория A содержит данные, нарушение согласованности которых привело бы к крупным убыткам. К категории C относятся данные, (временная) несогласованность которых является приемлемой (т.е. либо несогласованность данных вызовет лишь небольшие убытки, либо в действительности несогласованность не возникает). Категория B включает все данные, требования к согласованности которых изменяются во времени в зависимости, например, от реальной доступности некоторого элемента. Обычно такие данные параллельно изменяются многими пользователями и часто являются узким местом в системе. В этой статье мы фокусируемся на категории B. Именно для этой категории можно добиться оптимального соотношения расходов на выполнение операций и обеспечиваемого уровня согласованности. Мы описываем несколько сценариев использования, обосновывающих выделение такой категории данных B. Затем мы излагаем модель стоимости системы и обсуждаем различные стратегии динамического изменения уровней согласованности в зависимости от потенциальных убытков. Эти стратегии направлены на минимизацию общей стоимости выполнения операций над "облачной" системой хранения данных. Наши эксперименты с "облачным" сервисом, реализованным поверх службы S3 компании Amazon, показывают, что динамические политики, которые описываются в этой статье, могут принести значительную экономию затрат. Основным вкладом статьи является следующее:
- Вводится понятие рационализации согласованности (Consistency Rationing), позволяющее приложениям получать требуемые уровни согласованности с наименьшими возможными затратами.
- Определяется и анализируется ряд политик для изменения протоколов согласованности во время выполнения. Наши эксперименты показывают, что политики динамического выбора уровня согласованности оказываются эффективнее политик статического назначения гарантий согласованности.
- Вводится понятие вероятностых гарантий согласованности (т.е. процентили) с использованием темпоральных статистик числовых и нечисловых данных. Такие статистические гарантии очень важны с точки зрения соглашений об уровне обслуживания (service level agreement), хотя, насколько мы знаем, в нашей работе вероятностные гарантии согласованности подробно исследуются впервые.
- Представляется законченная реализация концепции рационализации согласованности на основе S3 компании Amazon. Мы приводим данные о показателях (денежной) стоимости и производительности пропуска тестового набора TPC-W для нескольких категорий согласованности, смеси категорий и различных политик категории B. Результаты этих экспериментов обепечивают правильное представление о стоимостных характеристиках таких систем, о стоимостной структуре каждой операции и о том, как можно оптимизировать эти стоимостные показатели с использованием соответствующих моделей стоимости.
Основная часть статьи организована следующим образом. В разд. 2 описываются сценарии использования рационализации согласованности в "облачных" средах. В разд. 3 обсуждаются родственные работы. В разд. 4 рассматриваются рационализация согласованности, приводится анализ категорий A, B и C и обсуждается, как можно обеспечить смешанные гарантии согласованности. В разд. 5 представляются альтернативные стратегии для управления данными категории B. В разд. 6 описывается реализация рационализации согласованности в "облачной" среде. В разд. 7 приводится сводка результатов экспериментов с использованием тестового набора TPC-W. Разд. 8 содержит заключение.

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