Год эпохи перемен в технологии баз данных

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

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

2.2. Клермонтский отчет

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

• Future Directions in DBMS Research – The Laguna Beach Participants. SIGMOD Record 18(1): 17-26, 1989. Пересказ на русском языке: Будущие направления исследований в области баз данных: десять лет спустя.
• Abraham Silberschatz, Michael Stonebraker, and Jeffrey D. Ullman. Database Systems: Achievements and Opportunities. CACM 34(10): 110-120, 1991.
• Abraham Silberschatz, Michael Stonebraker, Jeffrey D. Ullman. Database Research: Achievements and Opportunities Into the 21st Century. SIGMOD Record 25(1): 52-63 (1996). Перевод: Базы данных: достижения и перспективы на пороге 21-го столетия.
• Avi Silberschatz, Stan Zdonik et al., Strategic Directions in Database Systems – Breaking Out of the Box. ACM Computing Surveys, Vol. 28, No. 4 (Dec 1996), 764-778. Перевод: Стратегические направления в системах баз данных.
• The Asilomar Report on Database Research. SIGMOD Record 27(4): 74-80, 1998. Перевод: Асиломарский отчет об исследованиях в области баз данных.
• The Lowell Database Research Self-Assessment. CACM 48(5): 111-118, 2005. Пересказ на русском языке: Крупные проблемы и текущие задачи исследований в области баз данных.

В мае 2008 г. состоялась новая встреча. Она проходила в отеле Claremont Resort в г. Беркли, Калифорния, и поэтому отчет получил название «Клермонтского». Джо Хеллерстейн (Joseph M. Hellerstein) подготовил и поддерживает специальный сайт, на котором и был опубликован первый вариант отчета: The Claremont Report on Database Research. Имеется его полный перевод: Клермонтский отчет об исследованиях в области баз данных.

Я не буду здесь подробно пересказывать отчет, а лишь отмечу те его места, которые имеют отношение к дальнейшему материалу этой статьи.

2.2.1. Проблемы архитектур серверов баз данных

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

…у современных развитых коммерческих систем реляционных баз данных имеются хорошо известные ограничения. Обеспечивая широкий набор возможностей, они показывают пиковую производительность только для очень ограниченного набора режимов. В последнее десятилетие появилось много популярных задач, связанных с обработкой больших объемов данных, для которых реляционные СУБД обеспечивают плохое соотношение «цена/производительность», и при решении которых от использования РСУБД пришлось отказаться.

Как видно, эти утверждения напрямую перекликаются с доводами Майкла Стоунбрейкера и его сторонников, рассмотренными в предыдущем подразделе.

С другой стороны, в отличие от общего «революционного» тона статей Стоунбрейкера и Ко, в отчете говорится, что

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

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

К числу наиболее важных исследовательских тем в этой области относятся:

1. разработка систем для кластеров многоядерных процессоров, в которых имеется ограниченный и неоднородный доступ к памяти вне кристалла;
2. использование удаленной основной и флэш-памяти в качестве среды персистентного хранения данных в дополнение к памяти на магнитных дисках;
3. разработка унифицированного подхода к постоянно выполняемой адаптации и самонастройке оптимизации запросов и физических структур хранения данных;
4. сжатие и шифрование данных на уровне хранения, интегрированное со структурой хранения и оптимизацией запросов;
5. разработка систем, опирающихся на нереляционные модели данных, вместо того, чтобы «впихивать» эти данные в таблицы;
6. нахождение компромиссов между согласованностью и доступностью для достижения лучшей производительности и масштабируемости до уровня тысяч машин;
7. разработка СУБД, учитывающих потребление энергии, которые ограничивают энергопотребление без ущерба для масштабируемости.

Для обсуждения в этой статье основной интерес в этом списке представляет п. 6. Из остальных наиболее актуальным мне кажется п.2. В этой статье он подробно не обсуждается, но совершенно очевидно, что бурное развитие технологии флэш-памяти и «твердотельных дисков», доступность таких носителей с емкостью в сотни гигабайт создает новые перспективы для организации систем управления данными.

В связи с этим на меня произвела большое впечатление статья Гоца Грейфа «Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила» (оригинал: Goetz Graefe. The Five-minute Rule: 20 Years Later and How Flash Memory Changes the Rules, ACM QUEUE, July/August 2008). В этой статье автор, в частности, задает вопрос:

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

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

2.2.2. Декларативное программирование

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

…актуальность этой проблемы возрастает буквально экспоненциально, поскольку программисты нацеливаются на все более сложные среды, включая многоядерные микропроцессоры, распределенные службы и платформы «облачных вычислений» (cloud computing). Неквалифицированным программистам требуется возможность легко писать надежные программы, масштабируемые при возрастании числа процессоров как в слабосвязанных, так и в сильносвязанных архитектурах.

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

В качестве первого примера подобного подхода рассматривается MapReduce. Отмечается, что

…в подходе Map-Reduce привлекает его простота; он основывается на языковых методах и методах распараллеливания по данным, известных в течение десятилетий. Для исследователей баз данных значимость подхода Map-Reduce состоит в том, что он демонстрирует преимущества программирования с распараллеливанием по данным новым классам разработчиков.

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

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

Наконец, третий пример происходит из области программирования корпоративных приложений. Сближению сред программирования и управления данными, устранению проблемы потери соответствия (impedance mismatch) способствует возникновение новых языковых расширений, таких как LINQ и Ruby on Rails. Однако в отчете отмечается, что

… в этих пакетах пока серьезно не решается проблема программирования с использованием нескольких машин. Для корпоративных приложений ключевым решением распределенной разработки является разделение логики приложения и данных между несколькими «звеньями» («tier»): Web-клиентами, Web-серверами, серверами приложений и серверной СУБД. Особо ценной здесь является независимость данных, позволяющая создавать программы без предварительного принятия долговременных решений о физическом размещении программ и данных в разных звеньях.

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

2.2.3. Управление данными в «облачной» инфраструктуре

Как отмечается в отчете, облачные сервисы могут повысить эффективность поставщиков приложений за счет сокращения объема требуемых начальных вложений и сокращения стоимости владения. Доступен ряд разнообразных облачных сервисов, включая прикладные сервисы (salesforce.com), сервисы хранения (Amazon S3), вычислительные сервисы (Google App Engine, Amazon EC2, и сервисы данных (Amazon SimpleDB, Microsoft SQL Server Data Services, Google’s Datastore.

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

Следующая проблема – достижение высокого уровня управляемости. Решение этой проблемы для систем в облачной среде осложняется ограниченным человеческим вмешательством, сильно изменчивыми рабочими нагрузками и разнообразием совместно используемых инфраструктур. При решении проблемы требуется учитывать наличие различных подходов к виртуализации ресурсов – от виртуализации аппаратных средств до использования в службе данных одной СУБД для управления несколькими базами данных с разными схемами. Для достижения управляемости требуется развивать и совершенствовать методы самоуправления системами.

Серьезную проблему представляет масштабируемость будущих облачных систем управления данными. Технология, применяемая при разработке современных SQL-ориентированных СУБД, просто не позволяет масштабировать их до 1000 узлов. По всей видимости, в будущих системах нужно ограничивать требования к их транзакционности или учитывать семантику данных. Дополнительные исследования нужны для понимания реальной масштабируемости облачной инфраструктуры. В связи с этим см. разд 3 и 4 настоящей статьи.

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

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

3. MapReduce и параллельные системы баз данных

Молодежи свойственно увлекаться новыми идеями. Идея MapReduce (см. основополагающую статью Jeffrey Dean, Sanjay Ghemawat «MapReduce: Simplifed Data Processing on Large Clusters», Proceedings of the Sixth Symposium on Operating System Design and Implementation, San Francisco, CA, December, 2004), выдвинутая и реализованная сначала Google, а потом и сообществом open source в проекте Hadoop почти мгновенно овладела молодыми массами. Причем даже теми представителями компьютерной молодежи, которые получили хорошее образование и последующий практический опыт в области систем управления базами данных.

Мне неоднократно приходилось слышать от молодых коллег, что они считают достоинствами MapReduce отсутствие схемы данных (в том числе, и отсутствие поддержки типов данных) и даже потребность в явном программировании конструкций, которые испокон веков поддерживались в СУБД на уровне высокоуровневых языковых конструкций языка SQL. Дополнительным стимулом к применению MapReduce была привязка этой технологии к «облачным» вычислениям, возможность практически бесплатно арендовать виртуальный кластер с большим числом узлов и развернуть на нем свою MapReduce программу, почти автоматически достигнув громадной производительности своего приложения.

До поры до времени представители старшего и среднего поколений сообщества баз данных ограничивались ворчанием в адрес MapReduce, что, в свою очередь, еще больше привлекало молодежь к использованию соответствующих средств. Действительно, раз «старики» ворчат, значит, они не понимают, что средства управления данными их поколений просто устарели, и нужно переходить к использованию новых, прогрессивных технологий. Больше других ворчали (и получали достойную отповедь от молодежи) Майкл Стоунбрейкер и Дэвид Девитт (David J. DeWitt), что, в частности, проявилось в написании и публикации ими в январе 2007 г. в коллективном блоке Database Column заметок «MapReduce: A major step backwards» и «MapReduce II».

И вот, в 2008 г. ворчание стариков выразилось в инициировании ими чрезвычайно интересного проекта по практическому сравнению технологии MapReduce с технологиями параллельных СУБД категории sharing nothing. Результатам этого проекта посвящена статья «Сравнение подходов к крупномасштабному анализу данных» (оригинал: Andrew Pavlo, Erik Paulson, Alexander Rasin, Daniel J. Abadi, David J. DeWitt, Samuel Madden, Michael Stonebraker. A Comparison of Approaches to Large-Scale Data Analysis. Proceedings of the 35th SIGMOD International Conference on Management of Data, 2009, Providence, Rhode Island, USA).

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

Эксперименты, описываемые в этой статье, основывались на выполнении нескольких несложных аналитических задач на кластере из ста узлов с использованием двух параллельных СУБД категории sharing-nothing (применялись СУБД Vertica и некоторая СУБД с традиционным построчным хранением данных, именуемая в статье СУБД-X) и реализации MapReduce от Hadoop. Очень интересно, как авторы обосновывают свой выбор для экспериментов относительно небольшого кластера, тогда как сторонники MapReduce обычно говорят об абсолютных преимуществах этой технологии при использовании кластеров с тысячами узлов.

Как утверждается в статье, такая масштабная аппаратура не требуется современным высокоэффективным параллельным СУБД даже при поддержке предельных в настоящее время по объему петабайтных баз данных. Например, в конфигурации СУБД Teradata, применяемой в eBay, 72 узлов (в каждом узле два четырехъядерных процессора, 32 гигабайта основной памяти и 104 300-гигабайтных диска) оказывается достаточно для управления реляционными данными объемом около 2,4 петабайт. Так что с самого начала статьи, по сути дела, утверждается, что сверхвысокая масштабируемость параллельных СУБД в действительности не требуется (заметьте, как это перекликается с тезисом Клермонтского отчета о невозможности должного масштабирования современных СУБД в облачной инфраструктуре).

При том, что авторы статьи уделили тщательное внимание программированию тестовых аналитических задач для среды MapReduce, на кластере из 100 узлов СУБД-X показала среднюю производительность, большую соответствующего варианта для MapReduce в 3,2 раза, а СУБД Vertica оказалась в 2,3 раза быстрее СУБД-X. Авторы предполагают, что те же относительные соотношения сохранились бы и на кластере с 1000 узлами, хотя такое оборудование просто не требуется для поддержки параллельными системами баз данных актуальных сегодня баз данных петабайтного масштаба.

3.2. В чем причины?

Преимущество в производительности, демонстрируемое параллельными параллельными СУБД, оказывается возможным за счет использования технологий, совершенствуемых в течение десятилетий:

• индексация на основе B-деревьев для оптимизации выборки данных;
• новые механизмы хранения данных (в частности, поколоночное хранение);
• эффективные методы сжатия данных, позволяющие выполнять операции прямо над сжатыми данными;
• параллельные алгоритмы выполнения операций над реляционными данными.

С другой стороны, при использовании MapReduce потребовалось существенно меньше времени на загрузку данных: иногда это происходило в три раза быстрее, чем в случае Vertica, и в 20 раз быстрее, чем для СУБД-X (в основном, из-за отсутствия схемы данных). Существенно проще происходит установка и конфигурирование MapReduce, чем аналогичные действия для параллельных СУБД. Авторы статьи приходят к выводу, что это является одним из основных факторов, привлекающих к MapReduce разработчиков приложений. Другими факторами является простота использования (SQL часто оказывается слишком сложным для начинающих программистов аналитических приложений; с другой стороны примитивность MapReduce приводит к росту трудозатрат на разработку приложений) и большая устойчивость к сбоям отдельных узлов кластера.

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

Общим выводом статьи является потребность в совершенствовании обеих технологий. MapReduce нуждается в более выразительных средствах программирования, чтобы можно было снизить упомянутые выше трудозатраты на разработку. В параллельных СУБД требуются более совершенные методы распараллеливания определяемых пользователями функций. Первыми признаками грядущей интеграции SQL и MapReduce являются системы Greenplum (см. разд. 6) и nCluster компании Aster Data (см. статью Eric Friedman, Peter Pawlowski, John Cieslewicz «SQL/MapReduce: A practical approach to selfdescribing, polymorphic, and parallelizable userdefined functions», Proceeding of the VLDB ’09 August 2428, 2009, Lyon, France). Хочу также заметить, что в августе 2009 г. поддержка MapReduce появилась и в компании Vertica, являющейся, как уже говорилось, детищем ранее неутомимого борца с этим подходом Майкла Стоунбрейкера.

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