Недавно мы рассматривали концепции облачных СУБД и Database as a Service (DbaaS, “СУБД как сервис”). Теперь давайте разберёмся, на какие основные моменты надо обратить внимание в процессе выбора подходящего вам варианта.

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

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

Начинаем с локальной версии?

При детальном рассмотрении далеко не очевидным становится и выбор между локальной и облачной СУБД — с какой начать? На первый взгляд кажется, что всегда проще воспользоваться готовым внешним сервисом, нежели возиться с установкой и настройкой собственной СУБД. Однако облачные провайдеры, как ни удивительно, в серьёзных проектах рекомендуют начинать с использования собственной локальной СУБД и только после запуска прототипа адаптировать систему к DbaaS. Дело в том, что при переводе крупной системы с DBaaS на локальные СУБД можно столкнуться со множеством технических проблем, связанных с сокрытием исходно неведомых сложностей эксплуатации СУБД. При этом систему с локальными СУБД сложнее масштабировать, обходится она дороже и несёт полный набор типовых административных проблем, которые придётся неожиданно решать за свой счёт. А вот переход с локальной версии в облака, как показывает практика, проще буквально на порядок. Впрочем, если речь идёт о некритичных проектах уровня СМБ, то тут, конечно, можно сразу брать любое готовое облачное решение.

Облачные парадоксы

Ещё одна необычность выбора — это часто более высокие надёжность, масштабируемость и универсальность облачной СУБД/DbaaS (в частности, за счёт унифицированного API) в сравнении с локальной. По крайней мере, это официальная позиция многих облачных вендоров. Так это или нет, в каждом конкретном случае надо выяснять отдельно. Любой CIO наверняка владеет информацией о средних простоях различных подсистем в своём ИТ-отделе, и вот тут можно сравнить эти показатели с SLA провайдера. Например, для Amazon RDS простой составляет 0,05% — 22 мин в месяц, что для критически важной системы, конечно, недопустимо.

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

Из кого выбираем

К списку нацелившихся на облачный рынок аналитики Forrester относят почти всех ведущих вендоров — Amazon, IBM, Microsoft, Saleforce.com, а также более мелкие специализированные фирмы — EnterpriseDB, LongJump, Elastra. Интересно, что лидером тут несколько неожиданно названа Microsoft, рядом — Amazon, чуть подальше — Database.com и EnterpriseDB.

Пока Forrester принципиально не считает участниками данного облачного рынка Oracle и Google. Oracle не учитывается лишь потому, что у неё пока нет public-сервиса (хотя СУБД Oracle-как-сервис доступна через Amazon RDS), но её самостоятельное появление на этом рынке, конечно, не исключено. А технология Google Cloud SQL (фактически MySQL в виде сервиса) не учтена потому, что она тесно интегрирована с PaaS-платформой Google App Engine.

Но прикладных пользователей эти терминологические игры и формальные придирки не интересуют. Давайте сравним основные тарифные модели облачных и DbaaS-провайдеров. В их разделении будем исходить из определения Стива Бобровского (www.pcweek.ru/infrastructure/article/detail.php?ID=154194), который делает акцент на том, за что надо платить: если деньги взимаются за использование именно СУБД, причём с явной технической спецификой, то это модель DbaaS. Сервисы же облачных СУБД значительно больше похожи на сервисы IaaS.

Практически все провайдеры предлагают как платные, так и бесплатные услуги. Но из бесплатных вариантов, пожалуй, только Amazon RDS позволяет запустить минималистичный действующий проект, а версии остальных явно предназначены только для ознакомления. В Amazon можно получить RDS для MySQL и Oracle (в образе виртуальной системы с ОЗУ 613 Мб, дисковым пространством 20 Гб и 10 млн. операций ввода-вывода в месяц).

В бесплатной поставке Google Cloud SQL объем ОЗУ виртуальной машины уже и не назывался (известно только, что он маленький), а предоставлялось 500 Мб дискового пространства. Но с 1 июня 2013 г. и эта “халява” закончилась, и теперь доступны только платные сервисы. Ещё более аскетические модели у DbaaS-провайдеров: например, 20 Мб диска и четыре подключения к БД для ClearDB.

В платном режиме различие в подходах ещё более выражено, что тоже серьёзно влияет на процесс выбора нужного сервиса: крупные облачные провайдеры исходят из параметров, характерных скорее для IaaS (ОЗУ, трафик), а DbaaS-провайдеры ориентируются на количество подключений. Например, Amazon RDS с ОЗУ 3,75 Гб и диском 5 Гб будет стоить 130 долл. в месяц, вариант Google чуть подороже: 2 Гб ОЗУ и 5 Гб диска за 175 долл. в месяц. Вариант Jupiter от ClearDB обойдётся в 100 долл. в месяц: будет доступна БД объёмом 10 Гб, но всего на 40 подключений.

Перспективы облачных сервисов СУБД

Наибольшая облачная активность наблюдается в отношении СУБД MySQL, что понятно: она сегодня остаётся главной общедоступной платформой в мире для создания веб-систем. Разработчикам масштабных систем понравятся сервисы Amazon RDS for MySQL и Google Cloud SQL, обеспечивающие все плюсы облачной модели, в частности возможность быстро и бесхитростно запустить множество “инстансов” MySQL с практически неограниченным масштабированием.

DbaaS-провайдеры предлагают более специализированные варианты, обычно отличающиеся в лучшую сторону от массовых решений конкретными техническими характеристиками. Кроме того, подобные сервисы далеко не всегда базируются на какой-нибудь известной виртуальной платформе — они вполне могут работать в собственном мини-ЦОДе без виртуальной прослойки. Но, на мой взгляд, DbaaS-услуги по формату предоставления все же будут постепенно уходить в сторону облачных СУБД на базе массовых виртуальных хостингов. Пример тому DbaaS-сервис Xeround, работавший с 2005 г. В 2011 г. он оставался единственным коммерческим облачным сервисом MySQL, который бесшовно работал и на Amazon EC2, и на RackSpace. Однако вместо развития клиентского сервиса менеджеры попытались поддерживать собственное фоновое NoSQL-хранилище для работы “клиентских” MySQL в облаках, в итоге же оно не смогло достичь нужной гибкости, и этой весной проект фактически закрылся.

Но пока и тех и других вариантов на рынке имеется удовлетворительное количество, представлены почти все ведущие СУБД, перечень услуг, как минимум, достаточен для большинства облачных проектов. Если же подходящей СУБД как формально поставляемого сервиса не обнаруживается, уж точно её можно найти в рамках какой-нибудь PaaS-услуги.

Особо бурного роста ожидать пока не приходится, потому что три-пять ведущих брендов СУБД в любом случае охватят 80% типовых потребностей рынка, однако тренды NoSQL и Big Data породят множество специализированных ниш.