Как выбрать облачного провайдера для реляционной базы данных – сравним Azure и AWS

Общий обзор реляционных баз данных Azure и AWS

Ниже есть общая таблица, основываясь на ней, мы видим, какие СУБД представлены в облаке как сервисе (SaaS).

Представление реляционных баз данных в облаках

СУБД в AWS представлены в рамках единого сервиса RDS

На самом деле, при создании экземпляра базы данных в RDS (relational data service) вы будете встречать особенности конкретных СУБД, а не общего сервиса RDS.

То есть, если вы разворачиваете MS SQL Server, вам необходимо выбрать тип лицензирования — Enterprise, Standard, Express или Web edition, выбрать версию (2012-2019), диски и мощности виртуальной машины, на которой будет развернут экземпляр, и сконфигурировать инфраструктуру. Если работа будет с другими видами СУБД, то соответственно все конфигурируется под конкретную СУБД со всеми ее особенностями.

Таким образом, RDS в большинстве своем повторяет и реализует полноценные СУБД, и при выборе и настройке пользователи руководствуются знаниями о наземных полноценных реализации.

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

СУБД в Azure выделены в отдельные сервисы

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

Способность к масштабируемости обусловлена ​​тем, что управление инфраструктурой в большинстве сервисов СУБД полностью выносится на уровень ответственности Microsoft, а на уровне пользователя остается только управление данными и приложением.

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

Облачные сервисы СУБД в Azure имеют свои подходы, поддерживают полную совместимость кода, но не обеспечивают полной совместимости с полноценной версией СУБД, проекцией которой они являются.

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

Условно говоря, функционал MS SQL Server в облаке может быть разделен на отдельные услуги, обладающие собственными принципами ценообразования.

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

Пример: Гранулярность – неисчерпаемое количество возможных сервисов и факторов ценообразования.

Кроме того, Azure имеет более широкую линейку предложений вариантов баз данных, относящихся к типам СУБД MS SQL server. На самом деле это неудивительно, поскольку Azure – это Microsoft, и SQL server – это тоже Microsoft.

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

При этом все равно многие административные вопросы будут оставаться на стороне Microsoft.

Многое то, что умеет делать RDS с базами данных SQL server, будет уметь и Azure, но дополнительно он будет предлагать еще больше гибридных версий под разных пользователей и под разные кейсы.

Предлагаю подробнее рассмотреть предложения Azure и AWS.

Что предлагает Microsoft в рамках Azure SQL

Модели развертывания в Azure SQL

Что предлагает AWS

Реляционная база данных – это виртуальная машина с установленным MS SQL Server. SQL Server on Azure Virtual Machines – это тождественные сервисы (IaaS).

Далее AWS предлагает упоминаемый RDS из MS SQL Server (SaaS).

Здесь вы не будете управлять виртуальной машиной, но будете ее выбирать из многих типов. Необходимо разбираться не только в простых и главных показателях эффективности базы данных, а именно IOPS, memory, CPU – нужно будет понимать характеристики виртуальных машин. Да, конечно, существует документация, но эта история будет более сложной для чистых разработчиков или аналитиков, а не профильных админов.

Опять же, Azure также дает возможность тонко подходить к вопросу.

Azure имеет managed instance, тип Azure SQL, наиболее соответствующий RDS, где также выбирается виртуальная машина. Нужно понимать ее особенности и конфигурационные детали, но дополнительно Azure SQL single database, действительно работающая как услуга, наиболее очищена от инфраструктурных вопросов и является «чистым» database engine.

При этом обеспечивается стандарт T-SQL для всех версий.

Например, варианты выбора параметров виртуальной машины (ec2) для RDS.

Часть параметров, которые конфигурируются: Allocated storage, Architecture settings, Auto minor version upgrade, Availability zone, AWS KMS key, Backup replication, Backup retention period, Backup target, Backup window, Character set, Collation, Copy tags to sna Database management type, Database port, DB engine version, DB instance class, DB instance identifier, DB parameter group, DB subnet group, Deletion protection, Encryption, Enhanced Monitoring, Engine type, Initial database name, License, Log exports, Mainten Master password, Master username, Microsoft SQL Server Windows Authentication, Multi-AZ deployment, National Character Set (NCHAR), Network type, Option group, Performance Insights, Provisioned IOPS, Public access, Storage autoscaling, Storage type, Time zone, Virtual Private Cloud (VPC),VPC Security Group (Firewall).

Для некоторых параметров есть свои вложенные параметры.

В противоположность варианты для создания Azure SQL

Azure SQL имеет две общие модели развертывания, классифицируемые более компактно (их подробно опишу в следующих статьях об облачных базах).

Первая модель

Вторая модель:

То есть выбор сервиса унифицирован к типам нагрузки с постепенным масштабированием.

Если Vcore – 1, 2, 4, 8, 16, 32 и так далее. Если DTU – 20, 50, 100, 200, 500, 1000 и так далее.

Конечно, существует множество деталей в выборе типа Azure SQL, большая часть которых имеет бизнес-контекст. Четкое понимание бизнес-потребностей очень важно, ведь технические детали интегрированы в бизнес-определение для облегчения понимания того, какую БД вам необходимо выбрать, если вы не администратор БД, а разработчик или владелец стартапа.

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