Як обрати хмарного провайдера для реляційної бази даних — порівнюємо Azure та AWS

Привіт. Мене звати Костя Макаренко. Я Data Engineer у компанії SMART business. Понад 10 років працюю у сфері інформаційних технологій, зокрема з базами даних.

Останні роки в моїй роботі акцент поступово змінюється з on-prem баз даних на їхні хмарні проєкції. З кожним роком пропозиція хмарних баз даних збільшується, і стає дедалі важче серед них орієнтуватися.

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

Наразі більше ніж 50% ринку хмарних обчислень припадає на Azure та AWS, відповідно ці провайдери є лідерами світового ринку і пропонують найширший діапазон типів і варіацій реляційних баз даних.

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

Загальний огляд реляційних баз даних Azure та AWS

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

Представлення реляційних баз даних в хмарах

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

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

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

Таким чином, RDS здебільшого повторює і реалізує повноцінні СУБД, і під час вибору та налаштування користувачі керуються знаннями про наземні повноцінні реалізації.

Це дає змогу зберігати повну сумісність з наземними екземплярами, що полегшує міграцію за певних сценаріїв та надає доступ на рівні операційної системи.

СУБД в Azure виділені в окремі сервіси

Cервіси в Azure переважно надають змогу сконцентруватись на розробці додатків та рішень «з нуля», можуть використовуватись під різні типи навантажень з можливістю змінювати технічні характеристики залежно від інтенсивності навантажень, типу або умов. Такі зміни технічних характеристик можуть відбуватись на вимогу, автоматично або за регламентом, і ці можливості описують рівень масштабованості сервісів.

Вища здатність до масштабованості зумовлена тим, що керування інфраструктурою в більшості сервісів СУБД повністю виноситься на рівень відповідальності Microsoft, а на рівні користувача залишається тільки управління даними та додатком.

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

Хмарні сервіси СУБД в Azure мають свої підходи, підтримують повну сумісність коду, але не забезпечують повну сумісність з повноцінною версією СУБД, проєкцією якої вони є.

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

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

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

Приклад: Гранулярність — невичерпна кількість можливих сервісів та факторів ціноутворення

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

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

При цьому все одно багато адміністративних питань будуть залишатися на стороні Microsoft.

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

Може здатися, що вже в цьому буде певна надмірність та виникатимуть складнощі під час вибору типу, але це ми розберемо в наступній статті. Все ж таки в RDS більше технічних, а не бізнесових деталей.

Пропоную докладніше розглянути пропозиції Azure та AWS.

Що пропонує Microsoft у рамках Azure SQL

Моделі розгортання в Azure SQL

Що пропонує AWS

Реляційна база даних — це віртуальна машина з встановленим MS SQL Server. Між SQL Server on Azure Virtual Machines — повний мепінг, тобто приймаємо, що це тотожні сервіси (IaaS).

Далі AWS пропонує згадуваний RDS з МS SQL Server (SaaS).

Тут ви не будете керувати віртуальною машиною, але будете її обирати з-поміж багатьох типів. Необхідно розбиратися не тільки в простих та головних показниках ефективності бази даних, а саме IOPS, memory, CPU — потрібно буде розуміти характеристики віртуальних машин. Так, звісно, існує документація, але ця історія буде складнішою для чистих розробників чи аналітиків, а не профільних адмінів.

Знову ж таки, Azure також надає можливість тонко підходити до питання.

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

Узагальнюючи:

Azure

AWS

Віртуальні машини (IaaS)

MS SQL Server on VM

MS SQL Server on EC2

Послуги (SaaS) (Hybrid)

Managed Instance

MS SQL Server on RDS

Послуги (SaaS)

Azure SQL Single Database

При цьому забезпечується стандарт T-SQL для всіх версій.

Для прикладу, варіанти вибору параметрів віртуальної машини (ec2) для RDS.

Name

Instance Type

Memory

Storage

Processor

vCPUs

Network Performance

Arch

M1 General Purpose Medium

db.m1.medium

3.75 GiB

1×410

intel Xeon Family

1 vCPUs

Moderate

64-bit

M1 General Purpose Small

db.m1.small

1.7 GiB

1×160

intel Xeon Family

1 vCPUs

Low

64-bit

M3 General Purpose Medium

db.m3.medium

3.75 GiB

1×4 SSD

Intel Xeon E5-2670 v2 (Ivy Bridge/Sandy Bridge)

1 vCPUs

Moderate

64-bit

T1 Micro

db.t1.micro

0.613 GiB

0 GiB (EBS only)

Variable

1 vCPUs

Very Low

64-bit

T2 General Purpose Micro

db.t2.micro

1 GiB

0 GiB (EBS only)

Intel Xeon Family

1 vCPUs

Low to Moderate

64-bit

T2 General Purpose Small

db.t2.small

2 GiB

0 GiB (EBS only)

Intel Xeon Family

1 vCPUs

Low to Moderate

64-bit

M1 General Purpose Large

db.m1.large

7.5 GiB

2×420

Intel Xeon Family

2 vCPUs

Moderate

64-bit

M2 High Memory Extra Large

db.m2.xlarge

17.1 GiB

1×420

Intel Xeon Family

2 vCPUs

Moderate

64-bit

Позицій — сотні. Кожен інстанс має свої додаткові характеристики. Окремо обираються диски, які не корелюють з частиною інстансів.

Додатково — конфігурація самої 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 snapshots, Database authentication, 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, Maintenance window, 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 має дві загальні моделі розгортання, які класифікуються більш компактно (їх детально опишу в наступних статтях про хмарні бази).

Перша модель

Basic

Standard

Premium

Target workload

Development and production

Development and production

Development and production

Uptime SLA

99.99%

99.99%

99.99%

Maximum backup retention

7 days

35 days

35 days

CPU

Low

Low, Medium, High

Medium, High

IO throughput (approximate)

1-5 IOPS per DTU

1-5 IOPS per DTU

25 IOPS per DTU

IO latency (approximate)

5 ms (read), 10 ms (write)

5 ms (read), 10 ms (write)

2 ms (read/write)

Columnstore indexing

N/A

S3 and above

Supported

In-memory OLTP

N/A

N/A

Supported

Maximum DTU

5

3000 (S12)

4000 (P15)

Maximum Storage Size

2 GB

250 GB

1 TB

Друга модель:

General Purpose

Bussiness Critical

Compute

1 to 16 vCore

1 to 80 vCore

Storage

Premium Remote storage, max 4 TB

Premium Remote storage, max 4 TB

IO throughput

500 IOPS per VCore

5000 IOPS per DTU VCore

Backups

RA-GRS, 7 — 35 days

RA-GRS, 7 — 35 days

Тобто вибір сервісу уніфікований до типів навантаження з поступовим, за необхідності, масштабуванням.

Якщо Vcore — 1, 2, 4, 8, 16, 32 і так далі. Якщо DTU — 20, 50, 100, 200, 500, 1000 і так далі.

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

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

Питання порівняння ціноутворення в залежності від продуктивності та функціональності планую розкрити у наступних статтях.

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую! Було корисно

Автор, а где aws aurora? Serverless?
А это что ?

Наголошую, що майже все те, що вміє робити RDS з базами даних SQL server, буде вміти і Azure,

Sql Server продукт MS. На этом стоило бы и закончить демагогию.

Вы кроме ms sql что то видели?

Як обрати хмарного провайдера для реляційної бази даних

Автор, ця стаття ствердження чи питання донас.
Відповіді і поради не знайшов.

А що вас цікавить в контексті даної тематики? Конкретна порада може бути під конкретний кейс.

Та набор бесцельных предложений. Сам не понял что автор хочет.

Відповіді і поради не знайшов.

В реальному житті буде ось так: «У клієнта вже є N сервісів в AWS, хм а де ж нам розгорнути реляційну базу даних для ще одного проєкта? О! А давайте в AWS!» :)

Про Azure хотелось бы еще добавить что DTU у базы данных при необходимости можно менять.

Так, дякую. Насправді, в більшості випадків і треба змінювати) Бо як правило, є або дефіцит або профіцит ресурсів. І це не тільки про azure , а взагалі про бд. І якщо так на землі, то в будь-якому разі це не оптимальне використання коштів — переплата за невикористані ресурси або недоотриманий непрорахований потенційний прибуток за сповільнення бізнесу, що очікує звіт, чи через затримки та блокування транзакцій, які взагалі можуть призвести до зупинки процесів. Про що я? треба не забувати, а продумувати регламенти масштабування бд в хмарі, автоматизувати це, і використовувати такі переваги на всі 100, один з сенсів хмари. Але попередньо все рахувати.

В Azure масштабироваться надо тоже аккуратно, Потому что

Changing the service tier and/or performance level of a database creates a replica of the original database at the new performance level, and then switches connections over to the replica. No data is lost during this process but during the brief moment when we switch over to the replica, connections to the database are disabled so some transactions in flight may be rolled back. This window varies but is on average under 4 seconds, and in more than 99% of cases is less than 30 seconds. If there are large numbers of transactions in flight at the moment connections are disabled, this window may be longer.

Проще говоря в момент ресайза база на какое-то время отваливается. И еще теоретически может быть очень больно, если для каких-то расчетов DTU подняли раз в 10, расчет сбойнул и DTU обратно не уменьшили.

100%, тому й пишу — продумувати регламент, автоматизовувати, прораховувати) Не має панацеї насправді, треба до всього підходити з аналізом та з головою. До речі, azure sql перемикається досить швидко все одно при всіх рівних , порівнюючи з тим же managed instance чи rds, не кажу про serverless чи hyper scaling, там свої деталі і в ціноутворенні в тому числі.

А там як виявилося можна було перворманс подивитися і індекс добавити
А не тір піднімати

Пассивно-агрессивный комментарий о том, как же мы сами не догадались сначала планы запросов проверить.

Нажаль, стрілочка SSAS ще може вести до Azure Analysis Services, яка не є повноцінною заміною SSAS

Погоджуюсь, насправді десь про це я пишу, у мс прослідковується намагання за рахунок хмарних SaaS та PaaS, зменшити технічне навантаження на користувача. І в питанні того, що в хмарі не має molap, як сервіса, доводить це. З досвіду, люди з бізнесу більш швидко адаптуються в роботі з tabular model, з dax ніж з mdx, а більшість бізнес задач можливо реалізувати. Конфігурація, супровід та розробка вимагає менше зусиль при всіх рівних. Але як мінімум, це є блокер при редизайні кубів з on-prem та їх міграції, тобто швидко все спростити та перейти в супермасштабовані хмарні сервіси зовсім без проблем не вийде, якщо використовувались molap.

Підписатись на коментарі