Базы данных уходят в облака. Как это получилось и какое будущее их ждет23.09.2019 12:30

23.09.2019, Пн, 12:15, Мск

На облачные базы данных в прошлом году пришлось более двух третей роста рынка СУБД. По оценке Gartner, к 2022 г. 75% всех баз данных будут развернуты в облаках или перенесены на облачную платформу из локальных дата-центров.

Рынок облачных СУБД (Cloud Database Management Systems, CDBMS) стремительно растет. По оценке аналитиков Gartner, в 2018 г. мировой рынок СУБД в целом увеличился на 18,4%, до $46 млрд., причем 68% роста пришлось на облачные СУБД. И к 2022 г. 75% баз данных либо уже станут облачными, либо будут пребывать в процессе миграции в облако. Ожидается, что особый интерес к CDBMS проявят компании, занимающиеся современными приложениями, такими как машинное обучение и аналитика.

Рост популярности CDBMS существенно изменил расстановку на консервативном, в целом, рынке СУБД.

Ранжирование производителей СУБД по доле рынка

Источник: Gartner, 2019

Видно, что за короткий срок в первой десятке появилось три новых, чисто облачных игрока — Amazon (замыкает первую тройку), Alibaba и Google. Подбирается (если можно применить такое слово к почти вертикальному взлету) к десятке и Tencent.

Как все начиналось

Столь стремительный рост популярности облачных СУБД стал возможен благодаря двум удачно совпавшим по времени обстоятельствам. Исторически базы данных строились исходя из единственно возможного в то время представления о вертикальном масштабировании (scale-up), предполагавшем использование все более и более мощных серверов. В начале 2000-х годов апогеем этой линии развития в этом направления стали несколько мощных СУБД (Oracle, DB2 и др.), работавших на многопроцессорных Unix-серверах. Но с появлением в те же годы тонких серверов (высотой 1–2 U) и особенно серверов-лезвий, вертикальное масштабирование стало постепенно уступать свое место более дешевому горизонтальному масштабированию (scale-out), где серверная мощность наращивается за объединения в кластеры относительно маломощных серверов стандартной архитектуры x86. В итоге базы данных «пересели» на кластерные конфигурации, собранные из серверов стандартной архитектуры, или на гиперконвергентные системы.

Еще лет через пять появились облака, заметной частью компьютерного ландшафта они стали к 2010 г. И тут оказалось, что версии СУБД, изначально рассчитанные на кластеры, оказалось заранее подготовленными к портированию на инфраструктуры, предоставляемые провайдерами в виде облачных сервисов.

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

И сейчас все ведущие разработчики СУБД имеют облачную версию своих систем. Если посмотреть на последнюю Forrester Wave, посвященную рынку облачных СУБД, среди «лидеров» и их «сильных преследователей» — знакомые все лица: Oracle, Microsoft, IBM, SAP. С которыми, не без успеха, соперничают и чисто облачные вендоры. Находится в облаках место и бесплатным СУБД (хотя, конечно, их «бесплатность» еще более условна, чем при размещении в корпоративном ЦОДе) — MongoDB, которая смогла даже выйти в лидеры по версии Gartner, Redis («преследователь») популярная в России PostreSQL и некоторые другие.

Лидеры рынка облачных СУБД, 2 кв., 2019

Источник: Forrester Research, 2019

Размер кружка на диаграмме означает коммерческий успех продуктов вендора в данной области.

Два типа облачных СУБД

Новизна облачных СУБД (Сloud DBMS, CDBMS), как и другого облачного программного обеспечения, состоит в отказе от традиционной «продуктовой» формы распространения. Пользователь избавлен от необходимости инвестировать средства в приобретение требуемого комплекта аппаратных и программных ресурсов, вместо этого он получает доступ к аналогичным ресурсам, размещенным в ЦОДах, принадлежащих облачному провайдеру. На данный момент реализуется два основных подхода к реализации CDBMS.

Во-первых, можно воспользоваться сервисом «Инфраструктура как сервис» (IaaS), арендовать необходимые инфраструктурные ресурсы. Облачная платформа позволяет зарезервировать на желаемое пользователем время необходимое количество экземпляров виртуальной машины, поддерживающих работу распределенной на них на СУБД. При этом клиент может сам установить на арендованных виртуальных машинах избранную им СУБД. Во втором он использует заранее заготовленные машинные образы, предоставляемые производителями СУБД совместно с облачным провайдером, например, Oracle Database 11g EE on Amazon EC2.

Второй подход к CDBMS имеет в основе схему SaaS, «Программное обеспечение как сервис», где в качестве ПО используется СУБД, поэтому ему дано собственное название DBaaS (Database as a Service). Предоставляя сервисы DBaaS, провайдеры избавляют клиентов от необходимости в каких-либо самостоятельных действиях с экземплярами виртуальных машин. Эти функции провайдер берет на себя, как и всю ответственность за инсталляцию и поддержание базы. В таком случае пользователю остается лишь пользоваться готовым решением и оплачивать его работу. Например, Amazon Web Services предлагает интерфейс с СУБД MySQL.

Первый вариант обладает хорошо известными достоинствами и недостатками облачных решений. К достоинствам относятся экономическая эффективность; неограниченные (по крайней мере — в теории) возможности масштабирования; отсутствие каких-либо проблем с обновлением оборудования при возникновении новых требований; большая гибкость и надежность. Недостатки — клиент не может контролировать безопасность данных, ограниченную соглашением об уровне обслуживания; неполадки в сетях передачи данных могут привести к остановке работы; размещение данных и программного обеспечения в ЦОДе провайдера вызывает привязанность к нему.

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

При выборе любого из двух вариантов следует, прежде всего исходить из масштабов стоящих перед предприятием проблем. Для малого и среднего бизнеса в современных условиях предпочтительнее DBaaS, для более крупного может быть достаточной аренда оборудования IaaS, ну, а немногочисленным очень крупным предприятиям, работающим с огромными объемами данных, все же разумнее размещать базы данных на собственных площадях и на собственном оборудовании.

Ну и, конечно, многое зависит от задач, которые надо решать. Если брать задачи «обычные», то для выбора провайдера можно воспользоваться оценкой аналитиков Gartner о состоянии дел на рынке операционных СУБД (ODBMS). Это СУБД, предназначенные для решения широкого спектра корпоративных транзакционных приложений (ERP, CRM и т. д.).

Ситуация на рынке операционных СУБД

Источник: Gartner, 2018

Видно, что в «лидерском» квадрате находятся те же компании, что и в топе облачных рейтингов. Квадранта этого года в широком доступе пока нет, но положение дел на июнь 18-го сходно почти до степени смешения с положением на ноябрь 17-го, и вряд ли за год кто-то смог потеснить первую пятерку.

СУБД в собственном ЦОД: еще не все потеряно

В отношении будущего «необлачных», on-premise, дата-центров и, соответственно, необлачных СУБД, аналитики выражают скепсис. Однако пока дела у них обстоят не так уж плохо. Их продажи растут не так быстро, как облачных СУБД, но «треть роста» для устоявшегося рынка — тоже не так уж плохо. И хотя, как отмечают в Gartner, лишь 5% пользователей в 2025 г. захотят вернуть свои СУБД из облака в ЦОД, для традиционных баз данных еще не все потеряно.

Известен эффект «притяжения данных» (data gravity) — чем больше объемы данных, тем сильнее они притягивают к себе сервисы и приложения, которые становятся все совершеннее. Это обстоятельство работает на пользу CDBMS. Однако есть и другой эффект, незаметный на терабайтных объемах, но становящийся существенным, когда речь заходит о петабайтах: возникают проблемы, связанные с транспортировкой данных.

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

Впервые с этой проблемой столкнулась компания Google, когда решила строить «зеркала» на разных континентах. Тогда компания решила возить данные морскими контейнерами. Странная, на первый взгляд, идея оказалась продуктивной, к тому же она стимулировала создание контейнерных ЦОДов.

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

И после переезда, как и в случае переезда реальных объектов, требуется немалого потрудиться на новом месте, снова перенося данные в облако.

Соответствующие проблемы тоже надо учитывать, принимая решение о том, заводить ли СУБД в облаке или «по старинке», в собственном дата-центре.

Что дальше?

Как бы не значительны успехи облачных СУБД, их нынешнее состояние можно сравнить с тем, как выглядели автомобили столетней давности. Они были безлошадными, но сохраняли облик гужевых экипажей. В своем нынешнем виде CDBMS является непосредственным «отражением» корпоративного ЦОД на облако. В результате остается привязанность клиента к конкретному дата-центру конкретного провайдера, что ставит его в зависимое положение, ограничивает надежность работы и сопровождается большими затратам на перемещение данных. Выходом из положения могут стать мультиоблачные решения (multi-cloud, или еще их называют polynimbus от латинского poly — много и nimbus — облако). Например, можно распределить базу данных между Microsoft Azure и Amazon AWS, возможно создание и более сложных конфигураций с целью оптимизации архитектуры ИТ-систем и географического распределения хранения больших объемов данных.

Полный текст статьи читайте на CNews