Год облачных СУБД

В 2011 году обозреватель Inforworld Дэвид Линтикам в статье «Почему 2013 год будет годом облачных баз данных?» предсказал массовую миграцию СУБД в облака, объяснив ее двумя тенденциями: ростом объемов баз данных и требований к их производительности — считая, что только в облаке организации смогут удовлетворять эти растущие потребности. На исходе 2013 года нельзя сказать, что корпоративные заказчики стремительно несут свои базы в облака, но, тем не менее с облачными СУБД в уходящем году связано немало знакового [1].

Прежде всего в этом году началась консолидация поставщиков облачных СУБД. Rackspace — один из системообразующих хостинг-провайдеров и создатель фактического стандарта в области программного управления инфраструктурными облаками OpenStack, приобрел 1 марта 2013 года компанию ObjectRocket, предоставляющую по подписке доступ к документо-ориентированной СУБД MongoDB, а 9 октября было объявлено о слиянии двух разработчиков облачных СУБД: TransLattice и StormDB. Обе эти компании строили бизнес вокруг оснащения PostgreSQL возможностью горизонтального масштабирования в условиях транзакционных нагрузок — каждая нашла свое оригинальное решение этой давней проблемы и вела свою ветвь расширений: PostgresR и PostgresXC.

Другим ключевым событием стал выпуск Oracle Database 12с, позиционируемой (суффикс «c» — cloud) как средство для построения облачных систем управления базами данных. Облачность Oracle Database 12c — это не просто ярлык от службы маркетинга, а новая возможность создавать в рамках одной контейнерной базы данных, управляющей пулом ресурсов, множественные «подключаемые базы» (pluggable database), каждая из которых «выглядит» как полноценная база данных, притом такие базы данных можно вживую переводить между различными контейнерами —  это как раз то, что требуется для организации мультиарендного и управляемого в рамках пула ресурсов сервиса предоставления СУБД.

Наконец, весьма примечательным событием 2013 года стала остановка сервиса Xeround, который в 2006 году называли самым многообещающим израильским стартапом, — год за годом компания получала многомиллионное финансирование, а в 2011 году ей удалось запустить облачную СУБД, «выглядящую снаружи» для подписчиков как обычная MySQL, но внутри реализованную как распределенное по множеству виртуальных вычислительных узлов хранилище в оперативной памяти. Но взять в аренду СУБД от Xeround можно было на хостингах Amazon EC2, Rackspace и Heroku лишь до 15 мая 2013 года. Как знать, может быть, израильская компания еще удивит мир облачных СУБД, но нынешний уход Xeround в новые поиски при, казалось бы, уже коммерчески эксплуатируемом сервисе — намек на то, что о полной определенности с отправкой СУБД в облака говорить пока еще рано.

Тем не менее все эти события свидетельствуют о достижении рынком уровня взросления, который на «циклах зрелости» Gartner отмечается как «преодоление недостатков», и, следуя за первыми разочарованиями фазы «избавления от иллюзий», он предшествует «плато продуктивности».

DBaaS

В 2011 году Национальный институт стандартов и технологий США (NIST) опубликовал рекомендацию за номером SP 800-145, в которой было дано четкое и простое определение облаков, указан перечень их существенных характеристик, классифицированы модели обслуживания и развертывания (рис. 1). Все популяризуемые в то время многочисленные решения, образованные по признаку «нечто как сервис» (… as a service), подчинены в определении NIST строго трем моделям: инфраструктурной (IaaS), платформной (PaaS) и прикладной (SaaS). Ссылаясь на это определение, можно характеризовать любую СУБД, предоставляемую по подписке со всеми подобающими характеристиками — DBaaS (database as a service), как облачную технологию в рамках платформной модели обслуживания. Есть, конечно, и несогласные — в частности, авторы StormDB относят свой продукт к модели IaaS, но если следовать документу NIST, отводящему инфраструктурному уровню только фундаментальные вычислительные ресурсы, такие как сети хранения и передачи данных, вычислительные узлы, то проще считать несогласных «уклонистами» и все же классифицировать DBaaS как PaaS.

Рис. 1. Благодаря рекомендации NIST установилось ясное представление об облаках и их содержании

При этом ничто не мешает развернуть DBaaS в рамках сети одной организации или даже скомбинировать так, чтобы часть ресурсов получать из Интернета, а часть — спрятать во внутренних сетях.

Обеспечение облачности

Первое, что должен обеспечить всякий облачный провайдер, следуя существенной характеристике «самообслуживания по требованию», — это автоматизировать развертывание и свертывание сервиса. При этом есть особенность, присущая именно DBaaS, — при свертывании сервиса арендатор зачастую не желает удалить свои базы данных навсегда, а хочет их лишь «заморозить» до лучших времен, а поставщикам облачных СУБД приходится продумывать, как это обеспечить — базы данных надо в каком-то виде заархивировать и сохранить, притом сделать это экономично. Когда речь идет о небольших базах, это вопрос несложный: в Сети немало мест, где любезно предоставят ресурс файлового хранения на несколько десятков гигабайт, а вот в случае с терабайтами приходится подбирать решение. Интересный вариант на этот счет есть у Amazon: облачный файловый архив Glacier на ленточных библиотеках, предоставляемый заказчикам по цене 1 цент за гигабайто-месяц, с бесплатной загрузкой, бесплатной выгрузкой в сервисы Amazon (в той же географической зоне), но отнюдь не бесплатной выгрузкой через Интернет (первые 10 Тбайт — 1200 долл.). Но если все эти терабайты обрабатывать только облачными СУБД, предоставляемыми Amazon, то экономика  может оказаться привлекательной, правда «разморозка» данных (англ. glacier — «ледник», «глетчер») может длиться несколько часов.

В случае универсального доступа по сети, особенно в условиях Интернета, провайдерам облачных СУБД важно снабдить сервис как можно более простыми протоколами доступа и естественными средствами вызова из других платформ и приложений. В принципе, клиент-серверные сетевые протоколы реляционных СУБД — это тоже в каком-то смысле универсальный сетевой доступ (благодаря JDBC и ODBC), но все же, говоря о «совсем универсальном», повсеместном доступе, в современных условиях подразумевают доступ через инфраструктуру Всемирной паутины, то есть посредством HTTP в стиле REST. Поэтому создатели новых СУБД изначально реализуют свои продукты как доступные по HTTP через REST API, а адаптирующие традиционные СУБД к облакам — снабжают системы этой возможностью.

Наиболее сложная характеристика, которую необходимо обеспечить создателю облачной СУБД, — это эластичность, возможность «аренды» оперативно расти и уменьшаться в зависимости от потребностей. Рост и сжатие для СУБД может измеряться объемом базы данных, количеством операций, ею обрабатываемых в единицу времени, количеством одновременных сессий и пропускной способностью. При этом эластичность тесно связана с еще одним облакообразующим требованием — учетом потребления: в идеальной картине облачного сервиса все потребляемые ресурсы, связанные с затратами провайдера, учтены для каждой аренды в виде метрик, соответствующих логике сервиса, и в этой же логике сервис «растягивается» или «сжимается» в зависимости от потребностей. Создатели ныне существующих сервисов облачных СУБД уже сейчас используют разнообразные метрики потребления — от самых очевидных, вроде объемов хранения в мегабайтах или количестве записей, количества пользователей или транзакций за период, вплоть до таких нетривиальных, как число операций ввода-вывода (Google Cloud SQL). Метриками потребления являются и гарантированные уровни обслуживания (Service Level Agreement, SLA), измеренные числовыми показателями, — например, Amazon RDS стоит по-разному в зависимости от взятых у провайдера обязательств по поддержанию скорости операций ввода-вывода, измеренной в IOPS.

Исследования

В научном сообществе интерес к теме облачных СУБД впервые проявился в Клермонтском отчете (2008 год) —  последнем на данный момент из серии отчетов о состоянии отрасли, составляемых ведущими исследователями в области баз данных. Судя по всему, вот-вот должна состояться еще одна такая встреча, но по состоянию на текущий момент Клермонтский отчет — последний (рис. 2). В нем нечто близкое к облачным СУБД под названием «облачные службы данных» зачислено в перспективные направления исследований, но никакой существенной конкретики приведено не было: все-таки в 2008 году было еще невозможно выдать какие-то точные формулировки.

Рис. 2. Раз в несколько лет ведущие исследователи баз данных формулируют отчет о состоянии дел и перспективах в отрасли

Начиная с этого времени исследователи весьма активно включились в изучение проблематики облачных баз данных, с 2009 года в рамках ACM CIKM (конференции ACM по информационному менеджменту и управлению знаниями) проводится ежегодный семинар под названием CloudDB, а к концу 2013 года только в цифровой библиотеке ACM было зафиксировано более 200 публикаций, содержащих упоминание облачных СУБД, мультиарендных СУБД, СУБД в модели PaaS. Кроме того, облачные аспекты (например, мультиарендность и REST API) и в значительной степени относящиеся к облачным СУБД проблемы (такие как горизонтальная масштабируемость в условиях транзакционных нагрузок или живая миграция) освещаются и в общих публикациях по управлению базами данных. Самые популярные темы исследовательских публикаций: описание проекта облачной СУБД или особого облачного языка для СУБД, реляционные и нереляционные модели в условиях облачности, учет потребления и экономические аспекты облачных СУБД, безопасность и разграничение доступа в условиях мультиарендности, научные базы данных в облаках.

Среди всех исследователей есть ученый, получивший признание именно на поприще исследований облачных СУБД,  — это Судипто Дас, выпустивший работу «Масштабируемые и эластичные транзакционные хранилища данных для платформ облачных вычислений». В инициированном Дасом проекте СУБД Elastras [2] сконцентрирована большая коллекция практичных и осуществимых идей и техник для создания СУБД общего назначения с поддержкой SQL и транзакционности, доступных множеству подписчиков. Такие решения из Elastras, как использование в качестве слоя хранения HDFS, разделение аренд на «малые» (размещаемые на одном узле) и «большие» (распределяемые), распределение баз данных с использованием ключей секционирования в зависимости от конструкции модели данных и тактики ее выявления, наверняка вскоре станут стандартными и для коммерческих DBaaS-решений.

Таксономия

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

Лежащий на поверхности способ классифицировать облачные СУБД — это отразить антагонизм последних лет между традиционными реляционными СУБД и тем, что скрывается за движением NoSQL. Нельзя говорить и о том, что за NoSQL скрывается какая-то конкретная технология, — движение объединило обычные хранилища «ключ — значение», документо-ориентированные СУБД, графовые СУБД, XML-системы и даже выходцев из 60-х: Pick, Mumps и порожденную ими Cache. Всех их объединяет отрицание, но не языка SQL, а реляционной модели. В последние пару лет (как считается — с подачи аналитика исследовательской группы 451 Research Мэтью Аслета) говорят еще и о NewSQL — компромиссе между классическими реляционными и нереляционными решениями. Термин «пошел в народ», возможно, еще и потому, что в нем слышится еще и New School («новая школа»), в противовес «школе старой» (Old SQL). Фактически получается, что называют новым словом два направления: построение из реляционных движков решений со свойствами, характерными для распределяемых NoSQL-решений и оснащение NoSQL-систем возможностью задавать им SQL-запросы, поэтому проще пока остановиться на бинарной классификации: SQL —  NoSQL (рис. 3).

Рис. 3. Классификация облачных СУБД

Следующий классифицирующий признак — по модели предоставления. Есть решения, сделанные только для одного сервиса, и программы реализации таких облачных СУБД существуют в единственном продуктивном экземпляре. Некоторые из них, такие как Database.com или Amazon RDS, доступны из публичного облака широкому кругу потребителей, а другие предоставляют сервис только внутри одной организации, в частной модели, и о них мы узнаем только из статей, написанных разработчиками, — таковы многие проекты, в том числе Megastore и Spanner. Но есть еще и решения типа «сделай DBaaS сам» — комплекты тиражируемого программного (а иногда еще и аппаратного) обеспечения для самостоятельного развертывания сервиса облачных баз данных: Oracle Database 12c, аппаратно-программные комплексы от Clustrix и StormDB — все это тиражируемые облачные СУБД.

Другое существенное подразделение в мире облачных СУБД связано с моделью обработки. Здесь нужно отметить в добавление к классическим моделям OLTP и OLAP появление еще одной очень востребованной, вместе с популяризацией идей о Больших Данных, схемы обработки — пакетной аналитики. Google Big Query или сервис Amazon Elastic MapReduce (включающий практически всю экосистему вокруг Hadoop) относятся именно к этому классу. Типичный конечный пользователь в приложениях над такими системами — не оператор, набивающий транзакции, и не «крутящий кубы» аналитик, а некий data scientist, постоянно ищущий в данных что-то, выражаемое на языке формул и алгоритмов, преобразующий их и запускающий все эти манипуляции в виде пакетных заданий.

Наконец, хотя все DBaaS и являются «базами данных по требованию», но некоторые из них используются, как правило, в связке с конкретной облачной платформой (например, Database.com используют в основном для разработки приложений на облачной платформе Force.com), а есть сделанные исключительно для конкретного набора приложений (такие как F1 от Google, предназначенная специально для собственных рекламных приложений). И это тоже показательный классифицирующий признак.

Amazon, Google, Salesforce.com и Big Red

Первые три компании по праву считаются основателями и законодателями облачной моды (рис. 4): в Amazon первыми запустили хостинг-продукт по облачным принципам и с облачным названием — Elastic Сomputing Сloud (ECC); Google голосом Эрика Шмидта первой провозгласила всеобъемлющий переход к облакам, а Salesforce.com первой абсолютизировала облачную стратегию, объявив весь свой бизнес облачным. Oracle («красный гигант», Big Red — так все чаще называют Oracle) еще несколько лет назад была их главным антагонистом: из одних только высказываний Ларри Эллисона в период  2007–2009 годов можно собрать томик афоризмов и колкостей про облачные вычисления (наиболее язвительно критиковалась «облачная риторика» Salesforce.com, особенно в контексте того, что «земные» Oracle Database и Oracle Fusion Middleware они используют как базовое программное обеспечение для своей облачной CRM-системы). Включение Big Red в облачную гонку в последние годы — сначала неловкое в виде названий (выпущенный в конце 2010 года аппаратно-программный комплекс Exalogic снабдили туманной припиской «Elastic Cloud», на что тут же отреагировал бессменный лидер Salesforce.com Марк Бенеф — «облака не бывают в коробке»), но совершенно осознанное в очередных версиях связующего ПО, запуске публичного облака (в котором есть и СУБД по требованию), методичной скупке SaaS-компаний и, наконец, выпуске Database 12c — явление, фундаментальное для рынка облачных СУБД.

Рис. 4. Реализации облачных СУБД

Amazon, без сомнения, является самым коммерчески значимым провайдером публичных облачных СУБД. Может быть, их Relational Database Service (RDS), в котором подписчики могут получить экземпляры MySQL, Oracle Database или MS SQL, и не был исторически первым управляемым хостингом СУБД, но именно этот сервис стал классикой организации публичной облачной СУБД. Его деловая и техническая модель, включающая организацию географически разнесенного горячего или холодного резерва (в зависимости от желания «арендатора»), возможность приобрести лицензию на собственническую СУБД или «принести свою» («bring your own license»), продуманные сервисы по восстановлению и заморозке, метрики потребления были ориентиром для других облачных провайдеров в вопросах организации сервиса.

Облачной СУБД можно считать и сервис Amazon Elastic MapReduce (EMR). Вопрос, наверное, дискуссионный, можно ли сервис по предоставлению Hadoop-кластера из виртуальных узлов вообще считать СУБД, но в случае той экосистемы, которую предлагает Amazon, наверное, можно: решение, включающее такие средства, как Hive и Pig, отправляющие в распределенную среду пакетные задания, сформулированные в терминах баз данных, по праву может называться СУБД. Особенность лишь в том, что это особый тип обработки данных — пакетный.

Если все прочие облачные СУБД в облаках от Amazon были разработаны на стороне и лишь снабжены провайдером соответствующими свойствами, то DynamoDB — полностью самостоятельный продукт, доступный только в режиме облачной СУБД. DynamoDB оказала огромное влияние на всю отрасль и на движение NoSQL в целом — например, довольно успешный проект Riak написан с нуля на Erlang практически целиком по образу и подобию DynamoDB.

Недавно запущенный сервис Amazon Redshift — результат договоренности с компанией Actian, купившей в этом году производителя аппаратно-программных комплексов реляционных хранилищ данных без разделяемых ресурсов ParAccel, прямого конкурента Teradata и Netezza (последняя поглощена в 2010 году корпорацией IBM). Теперь подписчики Amazon имеют возможность получить из облака масштабные массово-параллельные реляционные хранилища — например, можно построить кластер из 100 шестнадцатиядерных узлов с суммарной емкостью хранения 1,6 Пбайт по цене 680 долл. в час.

Если Amazon в мире облачных СУБД — самый коммерчески значимый провайдер, то Google — главный евангелист и исследователь. У этой компании множество проектов (рис. 5), которые можно считать облачными СУБД, но из них лишь три доступны широкому кругу подписчиков: BigQuery, Cloud Datastore и Cloud SQL. Про все остальные мы узнаем лишь из конференций и научной периодики — компания активно делится информацией со своими разработчиками и всем сообществом, в котором с трепетом относятся к каждому такому раскрытию информации, а практически каждая публикация порождает более или менее успешный проект с открытым кодом. Напомним, что публикации о MapReduce и BigTable послужили прототипом для проектов экосистемы Apache Hadoop. В настоящее время в Google работают над механизмом, реализующим SQL-запросы для MapReduce-инфраструктуры, под названием Tenzing, призванным заменить многочисленные экземпляры MySQL, используемые в настоящий момент для задач интерактивной аналитики. По задумке, Tenzing во многом сходен с проектом Impala фирмы Cloudera, флагмана коммерциализации Hadoop. К сожалению, не всегда из таких публикаций удается уяснить все детали реализации, а иногда не получается даже понять и некоторые основополагающие принципы, возможно, из-за трудности передать в сжатом материале весь «культурный слой» исследовательских лабораторий, а может быть, и из соображений конфиденциальности. Например, сложно сказать, как же будет работать один из последних проектов облачных СУБД от Google — Spanner, ведь масштабы, заявленные разработчиками, поистине исполинские: в статье в ACM Transactions on Computing Systems за подписью 26 сотрудников корпорации эта система охарактеризована как «созданная для работы с триллионами записей на миллионах узлов в сотнях ЦОД».

Рис. 5. Взаимосвязь СУБД-проектов Google

Открытие публичного облака в домене database.com в 2010 году, вслед за платформой разработки force.com, закрепило за Salesforce.com роль важного поставщика на рынке публичных PaaS в целом. Стив Бобровский [3] и Курт Монаш раскрыли тайну устройства этой мультиарендной СУБД — физически это одна база данных под управлением Oracle Database, а практически все данные всех аренд хранятся в одной реляционной таблице. А то, что делает database.com реляционной базой данных: таблицы, представления, ссылочную целостность, поддержку SQL, триггеры, хранимые процедуры — все это в Salesforce.com написали в собственном движке. Интересно, что решение, сделанное на основе такого откровенного «антипаттерна» проектирования, работает быстро и устойчиво, важно тут еще и то, что один из «арендаторов» Database.com — это главный продукт компании, CRM-система, ставшая в 2012 году лидером всего рынка, опередив здесь SAP и Oracle.

Другие

В первую очередь это Microsoft со своей публичной платформой Azure, из которой подписчикам можно получить SQL Server, но не простой, а приближенный к облачной современности, — SQL Azure с доступом к распределяемым по узлам хранилищам «ключ — значение» (в Microsoft их называют Tables) и распределяемым двоичным данным, монтируемым как NTFS-тома (Blobs), и, конечно же, REST API. А то, что сейчас в Microsoft Research над проектом под названием Cloud SQL трудятся Филип Бернштейн, один из крупнейших исследователей систем управления базами данных, и Судипто Дас, автор проекта Elastras [4], позволяет надеяться, что этот ИТ-гигант построит выдающийся сервис DBaaS, а возможно, и создаст тиражируемый продукт.

Нельзя не упомянуть и других колоссов ИТ-отрасли, запустивших в 2013 году серию публичных DBaaS: SAP предоставляет подписчикам доступ через Интернет к СУБД в оперативной памяти HANA; у Teradata можно заказать в повременное использование через Сеть их знаменитые аппаратно-программные массово-параллельные комплексы для хранилищ данных; в облаке от IBM можно арендовать DB2 или Informix, притом практически на любой платформе; есть управляемый хостинг MySQL среди сервисов облака от HP.

MySQL в разных исполнениях и обертках — самая массовая основа DBaaS: например, MariaDB, ответвление от MySQL, можно взять в аренду прямо от разработчиков в сервисе под названием SkySQL (его технический директор — основатель и ключевой разработчик MySQL Микаэль Видениус). Есть также два нетривиальных геокластеризованных MySQL-облака от GenieDB и ClearDB.

Среди производителей тиражируемых DBaaS-решений есть и такой, чей сооснователь владеет патентом на создание продукта, характеризуемого как «эластичная облачная СУБД», — по идее, теперь все создатели эластичных облачных СУБД должны что-то этому человеку отчислять. Трудно сказать, воспользуется ли хитросплетениями патентного права эта молодая компания, но владелец патента — Джеймс Старки, один из ключевых разработчиков Interbase и фигура в мире СУБД довольно известная, поэтому гарантировано внимание к деятельности этой фирмы, которую сначала назвали NimbusDB, а недавно переименовали в NuoDB. В этом году они выпустили коммерческую версию своего продукта и обещают заказчикам горизонтально масштабируемую автоматически систему, способную в качестве слоя хранения использовать как произвольную доступную на операционной системе файловую систему, так и HDFS, и Amazon S3, и полностью поддерживающую SQL и транзакционность со всеми свойствами ACID.

Другой важный производитель тиражируемого DBaaS-решения — компания Clustrix, разработавшая аппаратно-программное решение горизонтально масштабируемой СУБД с поддержкой ACID, полностью совместимой с MySQL. Компания распространяет продукт в виде серверов x86-64 с 48 Гбайт памяти и 7 твердотельными накопителями (для функционирования распределенной СУБД требуется как минимум три узла), либо, как вариант, эти комплексы можно разместить на инфраструктурных хостингах Amazon или Rackspace. 

Примечательна также компания Cloudant, вдохновленная DynamoDB и CouchDB и решившая предоставить CouchDB подписчикам как сервис. Для этого ей пришлось сделать ответвление от проекта этой интересной документо-ориентированной СУБД, написанной на Erlang, назвав его BigCouch, — инструментарий можно скачать с Github и построить свой DbaaS.

***

Облачные СУБД стали сегодня одним из магистральных направлений в отрасли, а с ростом их коммерческой значимости они становятся драйвером в продвижении к решению таких общих и важных для всей индустрии ИТ вопросов, как построение горизонтально-масштабируемых транзакционных СУБД, конвергенция реляционных баз данных и движения NoSQL, внедрение технологий Больших Данных в СУБД. Растущий в последние годы интерес к Data Intensive Computing в контексте высокопроизводительных вычислений, вероятно, только поспособствует развитию направления, ведь идеальный массовый DBaaS — это как раз решение такого «суперкласса», обеспечивающее эффективное распределенное управление данными в гигантских масштабах, и многие технологические решения в рамках этих направлений наверняка будут общими.

Литература

1. Николаенко А. Облачные СУБД / 164-й семинар Московской секции ACM SIGMOD, октябрь 2013.
2. Das S., Agrawal D., El Abbadi A. ElasTraS: An elastic, scalable, and self-managing transactional database for the cloud. ACM Transactions on Database Systems, vol. 38, No. 1, Article 5 (April 2013), 45 p.
3. Bobrowski S. Optimal Multitenant Designs for Cloud Apps. Proceedings of the 2011 IEEE 4th International Conference on Cloud Computing (CLOUD ’11. Washington, DC), pp. 654-659.
4. Bernstein P., Das S. Rethinking eventual consistency. Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data (SIGMOD’13), p. 923-928. 

Андрей Николаенко (anikolaenko@acm.org) — системный архитектор, компания IBS (Москва). Автор выражает благодарность Михаилу Когаловскому за ценные советы при подготовке статьи.