Хмарні бази даних. Детальна інструкція, як застосовувати сучасний IT-підхід

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Мене звати Ілля Резников, я Europe Lead of Cloud Practice в Svitla Systems. Разом із польським колегою Arkadiusz Ryszewski, Senior Fullstack Engineer, написали статтю, де проведемо вас від «початківця до майстра» у всьому, що пов’язано з хмарними базами даних.

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

Історія появи баз даних

Поняття бази даних існувало задовго до появи комп’ютерів, але з їх появою, звісно, бази даних стали значно ефективніші.

Історія комп’ютерних баз даних бере свій початок з перших двох прикладів: у 1960-х роках Чарльз Бахман створив першу комп’ютеризовану базу даних. Початкова база даних називалася Integrated Data Store (IDS). Після цього компанія IBM представила свою систему баз даних, яка отримала назву Information Management System.

У 1970-х роках відбулася одна з найважливіших подій в історії баз даних: було опубліковано статтю «Реляційна модель даних для великих спільних банків даних», написану Е. Ф. Коддом (E. F. Codd). Це дослідження популяризувало термін «реляційна база даних» і спонукало до створення інноваційного підходу до зберігання та пошуку даних.

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

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

При цьому кожен сервіс має свої переваги і область застосування: для невеликих вебзастосунків, зберігання великих об’ємів даних, чи аналітики в режимі реального часу.

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

Що таке хмарні бази даних

Хмарні бази даних (Cloud Database) — це сервіси баз даних, створені та доступні через хмарну платформу, які можуть бути реалізовані у різних моделях розгортання та підтримувати різні механізми баз даних.

Аналогічно до взаємозаміни «класичних» визначень база даних (БД) та система керування базами даних (СКБД), означення послуга хмарних баз даних та хмарна база даних можуть використовуватись як синоніми.

Також, як синонім до послуги хмарних баз даних можна використовувати термін база даних як послуга (Database-as-a-Service). Він описує ідею про те, що постачальники послуг розгортають інфраструктуру та виконують деякі завдання з керування та обслуговування СКБД, що дозволяє користувачам використовувати базу даних, надану як послуга.

Термін керовані бази даних використовують для опису баз даних чи сервісів баз даних, розгорнутих у моделі програмне забезпечення як послуга (SaaS).

В цьому випадку хмарні провайдери пропонують сервіси із різними механізмами SQL та NoSQL баз даних, що дозволяє клієнтам вибрати БД, яка в точності відповідає їхнім потребам, і тому їх називають спеціально побудовані або спеціально створені бази даних.

Моделі розгортання баз даних

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

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

Розгляньмо основні моделі розгортання баз даних:

• інфраструктура як послуга,
• платформа як послуга,
• програмне забезпечення як послуга та
• безсерверні служби.

Модель розгортання — інфраструктура як послуга (IaaS)

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

Гарним прикладом цієї моделі є сервіс SQL Server on Azure Virtual Machines від Microsoft Azure.

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

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

У цьому випадку базова операційна система вже налаштована, але користувачі так само повинні подбати про доступ до мережі та правила безпеки.

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

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

Служба база даних у моделі IaaS не дає суттєвих переваг порівняно з БД, що розміщена на серверах організації. Різниця полягає в моделі ціноутворення та інтеграції з хмарними сервісами:

• Користувачі платять за спожитий час роботи віртуальної машини та за комерційну ліцензію, якщо така є. Можливі варіанти авансового платежу за віртуальну машину, але авансовий платіж за використання бази даних не передбачено. Щомісячна плата за фактичну оренду хмарної бази даних стає операційними витратами.
• Сховище та обчислювальні потужності хмарних баз даних стають еластичними, що дає користувачам більше можливостей у міру зростання робочого навантаження.
• Оскільки сервіс бази даних розміщується в хмарі, він може бути легко інтегрований з різними хмарними сервісами.

Недоліки цієї моделі розгортання досить очевидні:

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

Модель розгортання платформа як послуга (PaaS)

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

Ця модель об’єднує економічно ефективну, масштабовану ємність сервера баз даних промислового рівня з перевагами повністю керованої, сучасної платформи як послуги. Прикладом такої моделі розгортання є Amazon RDS Service від AWS.

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

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

Модель розгортання бази даних PaaS може бути використана в таких сценаріях міграції, як повторна покупка (Repurchase) та повторна покупка платформи (Replatform).

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

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

Цей підхід дає більше переваг для клієнтів, ніж модель розгортання IaaS:

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

Недоліки моделі розгортання PaaS полягають у наступному:

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

Безсерверні служби баз даних (Serverless)

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

У такому сценарії хмарний провайдер, як і раніше, відповідає за всю інфраструктуру, але на відміну від моделі PaaS, розробники не можуть вибирати конкретні параметри сервера (розмір сховища, параметри процесора тощо).

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

Тому під «безсерверною базою даних» ми маємо на увазі БД, яка здатна автоматично запускатися, вимикатися та масштабуватися відповідно до потреб вашого застосунку.

Найвідомішим сценарієм використання безсерверного підходу є хмарні обчислення, чудовими прикладами яких є AWS Lambda або GCP Cloud Functions. Це інструменти, що виконують код при спрацюванні налаштованих тригерів.

Розробнику виставляється рахунок лише за використану обчислювальну потужність. Хмарний провайдер відповідає за забезпечення високої доступності сервісу та його масштабування за потреби.

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

Прикладами хмарних безсерверних баз даних є Amazon Aurora Serverless та serverless compute tier for Azure SQL Database. Оскільки жоден з параметрів сервера не є фіксованим, тарифікація базується на фактичному використанні.

Наприклад, у випадку з сервісом Aurora, ціноутворення базується на обсязі сховища, що використовується для основної бази даних, екземплярів та резервних копій, а також на кількості операцій вводу-виводу та передачі даних.

З точки зору вартості або обслуговування, безсерверний підхід успадковує всі свої плюси і мінуси від моделі PaaS.

З додаткових переваг зазначу такі:

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

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

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

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

Модель розгортання програмне забезпечення як послуга (SaaS)

Використання моделі розгортання програмне забезпечення як послуга або SaaS звільняє користувачів від багатьох трудомістких завдань, пов’язаних з обслуговуванням інфраструктури та самої бази даних: розгортання базового апаратного та програмного забезпечення, встановлення, виправлення, оновлення та резервне копіювання.

Оскільки хмарний провайдер повністю керує відповідною СКБД, такі хмарні сервіси називаються повністю керованими послугами з управління базами даних (fully-managed database services).

При цьому всі сервіси у моделі SaaS є безсерверними, і демонструють найкращі переваги хмарних сервісів: надійність, доступність, гнучкість, масштабування. Прикладом таких сервісів баз даних є Firestore від Google Cloud Provider чи Amazon DynamoDB від AWS.

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

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

Користувачам потрібно лише кілька клацань мишкою, щоб почати користуватися такими сервісами.

Хмарні сервіси керованих баз даних можна використовувати у таких сценаріях міграції, як повторна покупка (Repurchase) та переробка застосунку (Refactor).

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

Для покращення прикладної системи, БД можуть бути перенесені до хмарної керованої бази даних, що дозволяє звільниться від задач управління інфраструктурою, або дані можуть бути перенесені до NoSQL баз даних, що також надаються сервісами баз даних за моделлю SaaS.

Хмарні керовані бази даних мають багато переваг:

• Непотрібно піклуватися про всі завдання з управління базами даних, розробники можуть зосередитися на бізнес-завданнях.
• Користувачам не потрібно прогнозувати навантаження та налаштовувати продуктивність сервісів баз даних, що надаються в моделі SaaS, оскільки вони масштабуються автоматично хмарними провайдерами.
• Користувачі отримують додаткові хмарні функції «з коробки», такі як міжрегіональні репліки, висока доступність, інтеграція з іншими сервісами, автоматичне резервне копіювання.
• Вартість користування послугами баз даних у моделі SaaS зазвичай оцінюється на основі споживання ресурсів або кількості запитів, а не кількості вузлів кластера чи розміру попередньо визначеного сховища.

Недоліки цих сервісів здебільшого є протилежністю переваг:

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

Різні механізми хмарних баз даних

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

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

Реляційні бази даних

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

Однак, такий тип бази даних важко масштабувати, аналізувати великі обсяги даних і він не є ефективним для деяких складніших запитів. Деякі з популярних рішень у цій категорії — Microsoft SQL Server, Postgres, MySQL та Oracle Database.

Існують також хмарні рішення, які було розроблено спеціально для хмарних середовищ, наприклад, Azure SQL Database чи Amazon Aurora.

Бази даних типу «ключ-значення»

Механізм бази даних типу «ключ-значення» (key-value database) є дуже простою концепцією. Вона зосереджена на єдиній таблиці, де кожен рядок має ключ, а значення описується наперед визначеним або динамічним набором стовпців.

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

Деякі хмарні рішення такого типу також пропонують можливість розповсюдити одну базу даних по всьому світу в декількох фізичних датацентрах. Прикладами таких баз даних є Azure Cosmos DB або Amazon DynamoDB.

Бази даних в пам’яті

Бази даних такого типу є протилежністю тому, що люди зазвичай очікують від бази даних, коли ви запитуєте їх про загальну ідею. Найголовніше: бази даних в пам’яті (in-memory database) не мають можливості зберігати дані протягом тривалого періоду часу, і тому всі дані втрачаються при перезавантаженні сервера.

Це пов’язано з принципом побудови баз даних в пам’яті. Такі бази даних здебільшого використовуються для тимчасового зберігання зчитаної інформації або даних в режимі реального часу, тобто створюються для забезпечення максимальної продуктивності застосунку.

У таких сценаріях стійкість не настільки важлива. Найпопулярнішими механізмами баз даних в пам’яті є Redis та Memcached, а також спеціальні хмарні реалізації, такі як GCP Memorystore та IBM Cloud^® Databases for Redis.

Бази даних документів

У деяких випадках, наприклад, коли використовується доменно-орієнтований дизайн, бази даних документів (document database) стають у пригоді. Цей механізм призначено для зберігання великих масивів текстових даних, наприклад, цілих рахунків-фактур.

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

Існують також хмарні реалізації, наприклад, MongoDB-сумісна база даних від AWS — Amazon DocumentDB або від IBM — IBM Cloud^® Databases for MongoDB.

Бази даних графів

Реляційні бази даних дозволяють користувачам легко керувати відношеннями між даними та реалізовувати додаткові структури даних, які формують власні зв’язки.

Однак у певний момент стало зрозуміло, що не всі типи даних і не всі зв’язки можуть бути зручно відображені у наборі таблиць. Це відбувається тому, що іноді відносини є настільки ж динамічними, як і самі дані.

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

Саме тому було створено новий механізм баз даних — бази даних графів (graph database). Вони дозволяють легко відстежувати зв’язки між окремими об’єктами, а головне — ефективно аналізувати ці зв’язки.

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

Найпопулярнішими прикладами механізмів баз даних графів є Neo4J Cloud, IBM Compose for JanusGraph та Amazon Neptune.

Бази даних часових рядів

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

Це формує новий механізм баз даних, який називається базами даних часових рядів (time-series database). Це бази даних, які організовують дані в серії подій, впорядковані за часом їх виникнення.

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

Прикладами таких служб баз даних є InfluxDB та Amazon Timestream.

Бази даних з реєстром

Бази даних з реєстром (ledger database), більш відомим як журнал транзакцій або блокчейн, — це БД, призначені для зберігання історії змін у певному середовищі таким чином, що її не може змінити жодна зі сторін, які беруть участь.

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

Прикладами таких рішень є хмарний сервіс Blockchain Platform Cloud Service, що пропонується компанією Oracle, або Amazon Quantum Ledger Database (QLDB) який пропонується AWS.

Інші типи

Було б несправедливо не згадати про інші сервіси даних, які по суті не є базами даних з класичної точки зору.

Серед них — хмарні реалізації розподіленої пошуково-аналітичної системи ElasticSearch, сервіси фабрики даних чи озера даних — повністю керовані хмарні сервіси, які дозволяють автоматизувати ETL та ELT процеси.

Також згадаймо різноманітні OLAP-сервіси, що допомагають аналізувати структуровані та напівструктуровані дані в сховищах даних, оперативних базах даних та озерах даних.

Особливості провідних реляційних СКБД

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

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

Oracle Database в основному використовується для корпоративних мережевих обчислень і сховищ даних.

MySQL є найвикористовуванішою СКБД з відкритим початковим кодом у світі та другою за популярністю після Oracle Database, за твердженням DB-Engines. Facebook, Twitter, Netflix, Uber, Airbnb, Shopify та Booking.com — це лише деякі з популярних сайтів, які користуються MySQL.

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

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

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

Microsoft SQL Server — це реляційна СКБД від компанії Microsoft, яка пропонується в різних редакціях, зокрема для персональної розробки, для великих компаній та хмарних сервісів, і призначених для використання в різних сценаріях — від невеликих локальних застосунків до великих корпоративних систем з багатьма одночасними користувачами.

Оскільки історія Microsoft SQL Server сягає більш як 30 років, крім надійності, масштабування, продуктивності, шифрування даних, СКБД пропонує вбудовані аналітичні можливості та може використовуватись з різними мовами програмування та у різних середовищах.

Також Microsoft пропонує різноманітні додаткові сервіси для вирішення спеціалізованих задач, таких як сервіс машинного навчання, сервіс тиражування даних, підготовки звітів, відправки повідомлень, інтеграції з іншими джерелами даних тощо.

PostgreSQL — це передова реляційна система керування базами даних корпоративного рівня з відкритим початковим кодом, яка підтримує як реляційні, так і JSON (нереляційні) запити.

Ця СКБД розробляється спільнотою вже понад 20 років, що зробило її стабільною, стійкою, коректною та надійною. PostgreSQL як основна база даних використовується багатьма вебзастосунками, мобільними, геопросторовими та аналітичними програмами.

PostgreSQL має довгу історію підтримки стандартних, розширених та визначеним користувачем типів даних, і може використовуватись багатьма мовами програмування. Вона також підтримує той самий рівень оптимізації продуктивності, що й комерційні бази даних, такі як Oracle та MS SQL Server.

Переваги хмарних служб баз даних

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

Далі ми розглянемо деякі з найзначніших переваг хмарних баз даних, які поділимо на декілька категорій.

Переваги для бізнесу

Підтримка ІТ-інфраструктури більше не є проблемою. У світі хмарних баз даних хмарний провайдер відповідає за системну інфраструктуру, тому компанія може зменшити навантаження власного ІТ-відділу шляхом відключення непотрібних систем.
Крім того, зникає необхідність утримувати персонал, який підтримує базову інфраструктуру; співробітники можуть зосередитись на вирішенні високорівневих бізнес-задач.

Гнучкість бізнесу. Широкий спектр хмарних служб баз даних, заснованих на новітніх технологіях, дозволяє використовувати спеціально створені бази даних замість того, щоб намагатися вмістити будь-які моделі даних в реляційні БД.

На додаток, розробникам не обов’язково використовувати лише один механізм бази даних. Для різних частин програми та в залежності від робочих навантажень можна використовувати різні механізми.

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

Спрощення розробки. Доступ до даних хмарної бази даних можна отримати різними способами: через вебінтерфейс, API та SDK, що надаються провайдером, або командний рядок.

Крім того, ресурси служби бази даних можуть бути створені та керуватись інструментами для підтримки інфраструктури як код, такими як незалежний від хмарного провайдера продукт Terraform, чи, наприклад, Amazon CDK, що підтримує інфраструктуру конкретного хмарного провайдера.

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

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

Функції, пов’язані з хмарою

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

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

Нові функції можна використовувати швидше. Щоб отримати нові можливості та функції користувачам локальних баз даних зазвичай після виходу оновлення програмного забезпечення доводиться чекати поки IT-відділ встановить його.

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

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

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

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

Як додатковий рівень безпеки, користувачі можуть використовувати хмарні служби, щоб контролювати, хто має доступ до бази даних і самих даних.

Хмарне походження дозволяє зберігати дані в безпеці і обмінюватись ними з інтегрованими сервісами без необхідності проходження даних через загальнодоступний Інтернет.

Тиражування між географічними регіонами. Хмарні провайдери мають численні географічні регіони, щоб підтримувати клієнтів у всьому світі. Тому копії хмарних баз даних можуть зберігатись в кількох географічні регіонах.

Міжрегіональне тиражування є однією з найважливіших частин стратегій безперервності бізнесу та аварійного відновлення.

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

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

Балансування з’єднань за допомогою проксі-сервісу бази даних. Проксі-сервіс бази даних — це додатковий рівень перед службою бази даних, який можна використовувати як балансир навантаження. Він може керувати пулом з’єднань та надавати обмеження на доступ до даних.

Різні сценарії ціноутворення

Економія коштів. Загальні витрати компанії можна знизити, якщо скоротити капітальні витрати, експлуатаційні витрати центрів обробки даних та потреби в ІТ-об’єктах, а також якщо скоротити відповідний ІТ-персонал.

Різні сценарії оплати. Хмарні бази даних працюють за різними моделями ціноутворення, які можна адаптувати до потреб клієнтів. Популярні моделі оплати включають ліцензування, на вимогу, оплату в міру використання, оплату заздалегідь зі знижками, вартість залежно від використання тощо.

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

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

Як максимізувати використання хмарних сервісів БД

В еру цифрової трансформації компанії переходять від систем-монолітів, де використовується єдина велика реляційна база даних, до хмарної мікросервісної архітектури з сервісами спеціально побудованих баз даних.

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

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

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

Успіхів!