Анализ альтернативных архитектур управления транзакциями в "облачной" среде

Дональд Коссман, Тим Краска и Саймон Лоузинг
Перевод: Сергей Кузнецов

Оригинал: Donald Kossmann, Tim Kraska, Simon Loesing. An evaluation of alternative architectures for transaction processing in the cloud. Proceedings of the 2010 International Conference on Management of Data (SIGMOD 2010), June 6-11, 2010, Indianapolis, Indiana, USA, pp. 579-590

This translation is a derivative of ACM-copyrighted material. ACM did not prepare this translation and does not guarantee that it is an accurate copy of the originally published work. The original intellectual property contained in this work remains the property of ACM.

Содержание

От переводчика

1. Введение

2. Родственные работы

3. Архитектуры распределенных систем баз данных

4. Облачные службы

5. Экспериментальная среда

6. Эксперименты и результаты

7. Заключение

8. Литература

От переводчика

Меня продолжают интересовать различные аспекты управления данными в новых условиях неограниченного горизонтального масштабирования аппаратных средств. В настоящее время эта область достаточно строго распадается на два направления: управление аналитическими данными и управление транзакционными данными. Наиболее интересным работам первого направления посвящены следующие статьи:

• Эндрю Павло, Эрик Паулсон, Александр Разин, Дэниэль Абади, Дэвид Девитт, Сэмюэль Мэдден, Майкл Стоунбрейкер. Сравнение подходов к крупномасштабному анализу данных
• Майкл Стоунбрейкер, Дэниэль Абади, Дэвит Девитт, Сэм Мэдден, Эрик Паулсон, Эндрю Павло и Александр Разин. MapReduce и параллельные СУБД: друзья или враги?
• Джеффри Коэн, Брайен Долэн, Марк Данлэп, Джозеф Хеллерстейн, Кейлэб Велтон. МОГучие способности: новые приемы анализа больших данных
• Эрик Фридман, Питер Павловски и Джон Кислевич. SQL/MapReduce: практический подход к поддержке самоописываемых, полиморфных и параллелизуемых функций, определяемых пользователями
• Азза Абузейд, Камил Байда-Павликовски, Дэниэль Абади, Ави Зильбершац, Александр Разин. HadoopDB: архитектурный гибрид технологий MapReduce и СУБД для аналитических рабочих нагрузок.
• Ю Ксу, Пекка Костамаа, Лайк Гао. Интеграция Hadoop и параллельной СУБД.

Возможно, заслуживает внимания и моя обзорная статья MapReduce: внутри, снаружи или сбоку от параллельных СУБД?

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

• Даниела Флореску, Дональд Коссман. Переосмысление стоимости и производительности систем баз данных;
• Тим Краска, Мартин Хеншель, Густаво Алонсо, Дональд Коссман. Рационализация согласованности в "облаках": не платите за то, что вам не требуется;
• Пэт Хелланд, Дейв Кэмпбел. Дом на песке.
• Майкл Стоунбрейкер, Сэмюэль Мэдден, Дэниэль Абади, Ставрос Харизопулос, Набил Хачем, Пат Хеллэнд. Конец архитектурной эпохи, или Наступило время полностью переписывать системы управления данными.
• Ставрос Харизопулос, Дэниэль Абади, Сэмюэль Мэдден, Майкл Стоунбрейкер. OLTP в Зазеркалье.
• Эван Джонс, Дэниэль Абади и Сэмуэль Мэдден. Управление параллелизмом с низкими накладными расходами для разделенных баз данных в основной памяти.

Сравнению этих подходов следовало бы посвятить отдельную статью, но пока ее нет, а в вводной заметке к переводу такое сравнение выполнить невозможно. Поэтому пока я просто продолжаю собирать интересные статьи про новые транзакционные системы управления данными и предлагаю вашему вниманию статью Дональда Коссмана и его коллег, в которой на основе тестового набора TPC-W сравниваются характеристики производительности и стоимости "облачных" систем управления данными от разных компаний и с разной архитекурой. Я считаю эту статью полезной и познавательной.

Сергей Кузнецов

Аннотация

"Облачные" вычисления (cloud computing) сулят ряд преимуществ для развертывания приложений, насыщенных данными (data-intensive application). Одна из важных перспектив состоит в снижении расходов на основе использования бизнес-модели "платы по мере использования" (pay-as-you-go). Еще одной перспективой является (практически) неограниченная производительность, достигаемая путем увеличения числа серверов при возрастании рабочей нагрузки. В этой статье рассматриваются альтернативные архитектуры, поддерживающие "облачное" выполнение приложений баз данных, и приводятся результаты тщательного анализа существующих коммерческих "облачных" служб, которые основаны на этих архитектурах. В центре внимания этой работы находится обработка транзакций (т.е. рабочие нагрузки с чтением и обновлением данных), а не аналитические рабочие нагрузки, привлекающие в последнее время большое внимание исследователей. Полученные результаты неожиданны в нескольких отношениях. Наиболее важно то, что, как нам представляется, в "облачных" службах всех основных поставщиков применяются разные архитектуры. В результате стоимость и производительность этих служб существенно изменяются в зависимости от особенностей рабочей нагрузки.

1. Введение

В последнее время понятие "облачных" вычислений пользуется чрезвычайно большой популярностью. Компания Gartner ставит cloud computing в верхние строчки списка наиболее прорывных технологий ближайших лет [14]. Все основные поставщики программного обеспечения и многие начинающие компании примкнули к движению "в облака" и утверждают, что их продукты уже готовы или готовятся к использованию в "облачной" инфраструктуре.

"Облачные" вычисления сулят обеспечить несколько новых возможностей. Они сулят сократить время выхода на рынок за счет устранения или упрощения процессов планирования, приобретения и подготовки к использованию аппаратных средств. Они сулят обеспечить разные способы сокращения расходов. Во-первых, за счет перехода к использованию бизнес-модели "платы по мере использования" можно превратить капитальные вложения в текущие расходы. Во-вторых, "облачная" инфраструктура может обеспечить более высокий (близкий к 100%) коэффициент загруженности аппаратных ресурсов. Поэтому cloud computing часто считают важной технологией для обеспечения экологически безопасного использования вычислительных средств (green computing). Кроме того, при использовании "облачных" вычислений сокращаются эксплуатационные расходы и трудозатраты за счет автоматизации таких IT-задач, как обновление системы безопасности (security patch) и переключение на резервные мощности при отказе оборудования (fail-over). Что касается производительности, то cloud computing обещает (практически) неограниченную масштабируемость, так что IT-администраторам не требуется беспокоиться о поддержке пиковой рабочей нагрузки. Наконец, "облачные" вычисления сулят гибкость при использовании программных и аппаратных средств и при управлении ими, что позволяет сократить время выхода на рынок и уменьшить расходы.

К настоящему времени выпущен ряд продуктов. В частности, свои продукты предлагают три крупнейших участника IT-индустрии – Amazon, Google и Microsoft. Все эти продукты объединяет то, что они доступны широкой аудитории пользователей за счет оформления технологии cloud computing в виде сервисов, которые можно вызывать с любого персонального компьютера на основе интерфейса REST. Кроме того, все текущие предложения направлены на обеспечение всех основных преимуществ "облачных" вычислений, и они завоевывают все большее признание на IT-рынке.

Цель этой статьи состоит в том, чтобы заложить первую небольшую веху на пути к анализу упомянутых продуктов. С использованием базы данных и рабочей нагрузки тестового набора TPC-W мы произвели оценку предложений Amazon, Google и Microsoft и сравнили результаты этих экспериментов с результатами, полученными при прогоне тестового набора TPC-W на Java-сервере приложений с применением обычной системы реляционных баз данных. В частности, мы старались найти ответы на следующие вопросы:

• Насколько хорошо оцениваемые продукты масштабируются при возрастании рабочей нагрузки? Действительно ли можно достичь (практически) неограниченной производительности?
• Насколько дорогостоящими являются эти продукты, и как соотносятся коэффициенты их экономической эффективности (cost/performance ratio)?
• Насколько предсказуемы расходы с учетом возможных изменений рабочей нагрузки?

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

Как будет показано, наши эксперименты привели к ряду неожиданных результатов. Хотя многие службы со стороны выглядят очень похожими (например, матрицы цен Microsoft Azure и Amazon Web Services почти идентичны относительно пропускной способности сети, стоимости хранения данных и ресурса процессора), они очень различаются, когда речь идет о сквозной производительности (end-to-end performance), масштабируемости и стоимости использования. Может быть, еще более неожиданными оказались различия в архитектурах, поддерживающих управление крупномасштабными данными и транзакционные рабочие нагрузки в "облачной" инфраструктуре.

В то время как большинство (традиционных) систем баз данных общего назначения (например, DB2, MySQL, Oracle 11, Postgres, Microsoft SQL Server) основывается практически на одних и тех же "хрестоматийных" архитектуре и структурах данных (например, во всех них используются динамическое программирование, индексы на основе B-деревьев, упреждающая запись в журнал (write-ahead logging)) [26], различия в реализации "облачных" служб колоссальны. Хотя время хрестоматийной архитектуры "облачных" служб еще далеко не пришло, в этой статье мы пытаемся "заглянуть за кулисы", классифицировать варианты архитектуры и подготовить почву для сравнения различных вариантов архитектуры по отношению к производительности и стоимости.

Оставшаяся часть статьи структурирована следующим образом. В разд. 2 приводится обзор родственных работ. В разд. 3 описываются альтернативные архитектуры баз данных, предназначенные для обработки транзакций "в облаках". В разд. 4 кратко обсуждаются службы, используемые нами для экспериментов и представляющие различные архитектуры, которые описываются в разд. 3. В разд. 5 приводятся детальные данные о тестовом наборе и экспериментальной среде. В разд. 6 представлены результаты экспериментов. В разд. 7 содержатся заключительные замечания и планы будущих исследований.

2. Родственные работы

В описываемом исследовании мы следуем многолетней традиции сообщества баз данных подвергать тестовым испытаниям новые виды систем управления базами данных по мере появления на рынке новых продуктов. Первой работой в этом направлении был знаменитый Висконскинский эталонный тестовый набор (Wisconsin benchmark [10]), который с течением времени привел к появлению серии тестовых наборов TPC, предназначенных для оценки производительности и стоимости систем баз данных для различных рабочих нагрузок; например, TPC-C и TPC-E для рабочих нагрузок OLTP, TPC-H для рабочих нагрузок OLAP, TPC-W и TPC-App – для всего стека Web-приложений. Кроме того, разработан ряд тестовых наборов для специализированных систем баз данных; например, OO7 для объектно-ориентированных систем баз данных [6], Bucky для объектно-реляционных систем баз данных [7], XMark XML-ориентированных систем баз данных [21] и Sequoia для научных систем баз данных [25]. Конечно, также проводились многочисленные исследования производственных показателей различных аспектов серверов приложений, систем баз данных, распределенных систем баз данных и отдельных компонентов инфраструктуры cloud computing (например, DHT – Distributed Hash Table). В одной из недавних статей [16] исследуется производительность реляционных систем баз данных, выполняемых на некоторой виртуальной машине. Безусловно, все эти результаты являются существенными. Однако целью нашего проекта была не оценка отдельных компонентов, а измерение сквозной (end-to-end) производительности альтернативных архитектур на всем стеке Web-приложений.

Несколько исследований посвящалось оценке производительности и масштабируемости инфраструктур "облачных" вычислений. В недавнем исследовании, выполнявшемся в сообществе баз данных, производительность Hadoop сравнивалась с производительностью более традиционных (основанных на SQL) систем баз данных [19]. Это исследование фокусировалось на крупномасштабных аналитических рабочих нагрузках с доступом к данным только по чтению, в то время как наше исследование концентрируется на рабочих нагрузках OLTP. В [15] приводятся результаты родственного исследования соотношений "стоимость-согласованность" при выполнении рабочих нагрузок OLTP в "облачной" среде. Наиболее близкой нашему исследованию работой является проект Cloudstone из университета Беркли. В Cloudstone специфицируются база данных и рабочая нагрузка для изучения "облачных" инфраструктур [23], и определяются показатели производительности и стоимости, на основе которых сравниваются альтернативные системы. В своих экспериментах мы могли бы использовать рабочую нагрузку Cloudstone, но мы предпочли выбрать тестовый набор TPC-W по причине его популярности и широкого признания в сообществе баз данных. Описываемое исследование основывается на двух предыдущих статьях, в которых излагалась наша позиция. В [12] предлагалось в ходе экспериментов по изучению производительности обращать внимание не только на величины задержки и пропускной способности, но и на стоимость. В [2] описывалась серия экспериментов, направленных на оценку "облачных" инфраструктур. Данное исследование можно считать первым шагом к реализации программы, намеченной в [2]: мы выполнили эксперименты, предложенные в [2] для оценки "масштабируемости" и "стоимости". Эксперименты из [2] с "пиковой" рабочей нагрузкой и отказоустойчивостью остались на будущее. На нашу работу особенно повлияла классическая статья, посвященная клиент-серверным архитектурам баз данных [11].

Содержание Вперёд