Довгий час реляційна база даних була досить стандартним рішенням для різних (і майже всіх) випадків використання програмного забезпечення, які мали вирішувати великі чи малі компанії.
Сьогодні варіативність набагато більша завдяки ширшій доступності баз даних NoSQL, баз даних у пам’яті або озера даних. Але незважаючи на це, щоразу, коли приймається рішення перенести поточні локальні бази даних у хмару, реляційна база даних як ціль залишається найпростішим варіантом для цього переходу.
Ми детальніше розглянемо наступні бази даних, які можуть бути частиною такої ініціативи:
- Оракул
- Аврора
- Microsoft SQL Server
- MySQL і PostgreSQL
- MariaDB
Я поясню, чим вони відрізняються від інших і чим вони відрізняються, включаючи їхні недоліки. Потім я наведу їх у контекст, продемонструвавши на типовому прикладі реального використання. Нарешті, я поділюся своїм поглядом на вибір між різними базами даних для вашого випадку.
БД AWS Oracle
Джерело: aws.amazon.com
БД Oracle, безсумнівно, була найпоширенішою комерційною базою даних за останні кілька десятиліть. Щоразу, коли компанії потрібно було надійне та високопродуктивне рішення для баз даних, Oracle DB був першим вибором. І з багатьох вагомих причин.
Чим це відрізняється
Oracle — це надійна та багатофункціональна платформа, яка може обслуговувати величезну кількість навіть абсолютно різних установок і вимог. Згодом ця БД стала найкращим рішенням, якщо вам потрібна найсучасніша надійність, масштабованість і придатність до обслуговування на локальній апаратній інфраструктурі.
Основні переваги
Ось деякі з основних переваг, які ви отримуєте, обираючи таку зрілу систему баз даних, як Oracle:
✅ Чудова підтримка та можливості для ефективного резервного копіювання та відновлення.
✅ Широкий спектр можливостей для налаштування продуктивності рішення БД всередині системи. Навіть через довгий час рішення вже у виробництві. Підтримку та технічне обслуговування на цій платформі дуже легко налаштувати, і вони дуже ефективні.
✅ Висока налаштованість рішення БД. Оскільки Oracle DB підтримує велику кількість функціональних можливостей на вибір, ви як системний інтегратор маєте багато варіантів для створення надійної системи, що складається саме з тих функціональних можливостей, які потрібні вашій платформі (продумані тригери, розділи, підрозділи, автоматизовані послідовності первинних ключів, представлення , знімки, обмеження даних, унікальні ключі, комбіновані ключі, зовнішні ключі, складені індекси тощо). Він підтримує все.
✅ Просте адміністрування діяльності та процесів бази даних. Спеціальні адміністративні консолі та інформаційні панелі, а також багато інструментів, створених Oracle і призначених виключно для адміністраторів, які можна використовувати з коробки.
✅ Підтримка багатокористувацьких середовищ. Якщо потрібно підтримувати тисячі окремих активних користувачів одночасно, Oracle є відповіддю.
Основні недоліки
Oracle DB дуже гнучкий щодо вертикального масштабування продуктивності. Але менше, коли вам потрібне сильне горизонтальне масштабування. Це означає, що можна легко оновити до потужнішого ЦП, більше пам’яті та місця для зберігання в базі даних кластера.
Але якщо ваші дані суттєво збільшаться за короткий проміжок часу – що зазвичай буває з даними в хмарі, вузькі місця продуктивності стануть помітнішими, і їх важче вирішити. Розповсюдження даних між кількома кластерами та очікування їх динамічного зростання стане головною вимогою в майбутньому. У цьому випадку ви можете виявити, що Oracle DB буде більше обмежувати, ніж задовольняти ваші майбутні потреби.
Іншим можливим недоліком може бути вартість. Oracle DB підтримує багато функцій, але багато з них мають певну ціну. Тим більше, якщо на місці є кілька кластерів і необхідно покращити фізичну продуктивність. Це означає, що програмне налаштування моделі даних вже недостатнє. Щоб отримати більше адміністративних інструментів і функцій, вам потрібно буде придбати корпоративну ліцензію. Це ще більше збільшить і без того високі витрати.
Нарешті, Oracle DB не є рідною службою AWS DB, а це означає, що ви не очікуєте повної підтримки від AWS. Скоріше орієнтуйтеся на підтримку Oracle. Але потім вирішуйте проблеми Oracle і AWS паралельно з двома різними групами підтримки.
Коли вибрати
Вибір хмарного аналога Oracle DB є найприроднішим рішенням, коли ваше поточне локальне рішення вже використовує Oracle DB. Це також спростить міграцію та перехід на хмарне рішення.
Тому вибирайте AWS Oracle DB у випадку:
- Ви очікуєте, що хмарна БД підтримуватиме ті самі процеси та функції, що й локальний варіант у доступному для огляду майбутньому.
- Ви не плануєте дуже швидко інтегрувати БД із великою кількістю рідних служб AWS.
- Ви не очікуєте, що поточний обсяг даних значно зросте за короткий проміжок часу.
- Вам потрібна підтримка величезної кількості функціональних можливостей. Тобто при переході на хмару було б важко втратити деякі з них, які зараз є.
- Ваша система повинна підтримувати сотні активних користувачів одночасно (або більше).
Приклад використання
- Великі телекомунікаційні системи для білінгу, CRM і даних проміжного програмного забезпечення.
- Спеціальні реалізації БД для автомобільних систем баз даних, інтегровані з кількома різними спеціальними інструментами або інструментами сторонніх постачальників.
- Пакетні системні рішення для банківської індустрії, де Oracle вже є фіксованою частиною пакетного рішення від постачальників і з часом інтегрує додаткові спеціальні компоненти БД в одну комплексну реалізацію.
AWS Aurora DB
Джерело: aws.amazon.com
Багато в чому Aurora є прямою протилежністю Oracle, навіть якщо це все ще реляційна база даних.
Чим це відрізняється
Autora DB — це рідна служба баз даних в AWS. AWS надає йому повну підтримку та постійний розвиток, а також глибоко інтегрує його з рештою екосистеми сервісів AWS.
Aurora DB не досягає такого рівня диверсифікації функціональності, який вже має Oracle. Але він народився в хмарі (на відміну від Oracle). Оскільки AWS продовжує розвивати Aurora, розрив функціональності в майбутньому може бути меншим, ніж сьогодні.
Багато в чому Aurora вже випереджає Oracle, особливо щодо інтеграції з іншими хмарними сервісами AWS. І оскільки Amazon створив Aurora з урахуванням хмарної екосистеми, Aurora готова до величезного прибутку від даних і збільшення з часом, тому горизонтальне масштабування є сильною властивістю.
Основні переваги
Основними перевагами Aurora DB я б назвав:
✅ Дуже гнучка можливість розширення екземплярів копій БД лише для читання. Ті, які ви можете створити за лічені секунди. Екземпляри лише для читання спільно використовують ті самі журнали БД основної бази даних, з якої вони походять. Це означає, що створення нової бази даних лише для читання не потребує синхронізації всіх даних; це робиться автоматично шляхом спільного використання існуючих.
✅ Готовність до збільшення обсягу даних – горизонтальне масштабування є важливою особливістю Aurora DB. Додавання нових кластерів і розширення можливостей масштабування в різних зонах доступності є настільки простими, як це можливо. Тоді Aurora дуже ефективно вибирає великі обсяги даних дуже швидко.
✅ Ви можете вибрати, чи використовувати серверний або безсерверний режим Aurora DB. Деякі функції будуть відсутні в безсерверному режимі. Але ви отримуєте велику гнучкість і оптимізуєте витрати, обираючи безсерверний режим.
✅ Автоматичне резервне копіювання та легке повернення на певний момент часу. Ще одна особливість полягає в тому, що Aurora DB може виконувати щоденне резервне копіювання, а відновлення повної бази даних до будь-якого моменту часу набагато простіше. Тут можна поєднати всі переваги хмарного середовища, як завжди доступний вільний простір, швидкі внутрішні операції AWS і спеціальну функцію Aurora DB, яка націлена на швидке відновлення та короткий час простою.
✅ Підтримка механізму баз даних MySQL або PostgreSQL, тому ви можете вибрати той, який вам підходить.
Основні недоліки
- Незважаючи на те, що Aurora, мабуть, є найбільш багатофункціональною рідною реляційною базою даних, яку ви можете вибрати в AWS, вона все ще відстає від Oracle у цьому відношенні. Це зрозуміло; У Oracle було набагато більше часу для розробки цих функцій у минулому. Факт залишається фактом, що з кожним випуском Aurora DB стає сильнішою та ближчою.
- Немає еквівалента Aurora DB у локальному просторі. Ви можете стверджувати, що старі бази даних, створені в базах даних MySQL або PostgreSQL, дуже схожі, і з точки зору сумісності вони точно є. Але вони не є строгим еквівалентом. Це означає, що міграція буде не такою простою. Вам потрібно буде налаштувати та запровадити процеси міграції, щоб гарантувати, що вони будуть передавати дані з локальної системи та зберігати їх у базі даних Aurora у правильному форматі моделі даних.
- Різні обмеження AWS, особливо жорсткі, є фактором, який у деяких випадках може перешкодити вибору цієї БД як цілі для просування вперед. Дуже ймовірно, що ви зможете обійти їх усі, але для деяких вам знадобляться серйозніші інвестиції в рефакторинг, що зрештою може збільшити загальні витрати на міграцію порівняно з іншою цільовою базою даних.
Коли вибрати
У двох словах, вибір Aurora DB як реляційної бази даних goto на платформі AWS ніколи не є поганим рішенням, але зробіть це, особливо якщо:
- Ви створите хмарну систему з нуля навколо реляційної бази даних.
- Ви очікуєте найвищого рівня сумісності та цілісності з якомога більшою кількістю різних рідних служб AWS.
- Ви очікуєте, що обсяг ваших даних значно зросте протягом короткого часу.
- Ви плануєте розпочати кілька додаткових проектів перевірки концепції (POC), де ви зможете використовувати всі переваги безсерверної версії реляційної бази даних.
Приклад використання
- Безсерверна платформа для аналізу великих обсягів даних зображень інфраструктури.
- Використання моделей машинного навчання для обробки інформації про озеро даних і створення бізнес-прогнозів для вашого бізнесу.
- Netflix використовує Aurora DB для швидкого паралельного виконання запитів над даними свого каталогу.
AWS Microsoft SQL БД
Джерело: aws.amazon.com
Цю базу даних в деякому роді можна порівняти з Oracle. Він також був створений задовго до того, як хмара стала справою, і є багато поточних локальних користувачів, які планують перейти на хмару, використовуючи базу даних MS SQL як джерело.
Чим це відрізняється
Незважаючи на ці подібності, БД MS SQL все ще залишається тією, яка раніше використовувалася набагато менше, ніж БД Oracle.
Принаймні судячи з точки зору мого особистого досвіду. Я брав участь у багатьох проектах Oracle протягом останніх двох десятиліть, але лише в кількох випадках, коли була задіяна база даних MS SQL. І, відверто кажучи, я не любив мати справу з цим десь так сильно, як з Oracle DB.
У будь-якому випадку, я все ще визнаю, що великий сегмент компаній використовує базу даних MS SQL як основну базу даних, яка є єдиною точкою істини для всіх даних.
Основні переваги
Основні переваги, якими володіє БД MS SQL:
✅ Гарна інтеграція з іншими службами та програмним забезпеченням Microsoft, якщо ця функція є важливою для вашої справи.
✅ Легке налаштування за допомогою спеціальних розширень коду, переважно у формі модулів коду Javascript. Це може бути корисним, коли ви маєте справу зі складнішими бізнес-процесами та завданнями, які плануються через базу даних.
✅ Досить простий з точки зору адміністрування (принаймні порівняно з Oracle DB).
✅ Можливо, це має набагато більше сенсу в хмарній екосистемі Azure, оскільки там вона вважається рідною системою реляційної бази даних, набагато більш сумісною з іншими хмарними службами.
Основні недоліки
- Подібно до випадку з Oracle DB, як нерідна база даних у просторі хмари AWS, уся підтримка та вирішення проблем мають здійснюватися через окремі виділені групи підтримки MS SQL.
- Менша диверсифікація функціональних можливостей загалом, якщо порівнювати її з Oracle DB або Aurora DB.
- Не підходить для великої кількості активних користувачів.
- Горизонтальна масштабованість є ще більшою проблемою, ніж у випадку з Oracle DB.
Коли вибрати
База даних MS SQL найкраще підходить, якщо ви хочете перенести наявну локальну базу даних MS SQL у хмару з якомога меншою кількістю відволікаючих факторів. Крім того, ви не очікуєте значної інтеграції з іншими хмарними службами AWS.
Тоді база даних MS SQL буде жити в хмарі AWS як повністю керована база даних з необмеженим сховищем і розширеними параметрами для горизонтальної масштабованості та високої доступності порівняно з локальною альтернативою.
Приклад використання
- Виступає в якості середньої платформи для індивідуальної інтеграції різних систем баз даних (може бути навіть іншого типу, наприклад, Oracle DB).
- Різноманітні проекти меншого масштабу, де варто враховувати вартість рішення бази даних, а бюджет більш обмежений (і не дозволяє вибрати повноцінне рішення Oracle DB).
AWS MySQL і PostgreSQL БД
Джерело: aws.amazon.com
Ці бази даних є відкритими за походженням (хоча зараз уже куплені більшими компаніями), що зрештою дає їм як переваги, так і недоліки.
Вони також не такі багаті на функції, як інші альтернативи, особливо у рідній формі. І хоча ви все ще можете використовувати їх обидва в інфраструктурі AWS у такому вигляді, я сумніваюся, що це все ще має надто великий практичний сенс.
Чим це відрізняється
Під час міграції локальної БД (будь то MySQL або PostgreSQL) до хмари AWS ви можете просто використовувати Aurora з механізмом MySQL або PostgreSQL як ціль і таким чином отримати всі додаткові переваги, які може запропонувати Aurora DB.
Звичайно, це означатиме додаткові зусилля на етапі міграції порівняно з випадком, коли буде обрана нативна альтернатива. Але ці додаткові зусилля будуть незначними.
Їх головна перевага полягає у вартості та тому, що вони найкраще підходять для невеликих проектів, де надійність не є темою.
Основні недоліки
- Обидва мають досить обмежені підтримувані функції, і ви повинні бути готові до обмежених можливостей обслуговування та адміністрування.
- Не підходить для масштабних проектів з великою кількістю активних користувачів.
- Не найкраще підходить для високопродуктивних рішень і там, де постійне налаштування продуктивності є сильною вимогою.
Коли вибрати
- Якщо вартість є основною темою, а бюджет дуже обмежений.
- Якщо проектна ініціатива невелика.
- Якщо обсяг даних досить малий і немає планів щодо значного зростання.
Приклад використання
- Ініціативи особистих проектів, де вартість інфраструктури має бути якомога мінімальною.
- Невеликі POC, які б довели, що запропонована концепція може бути реалізована.
- Проекти невеликих компаній з невеликими обсягами даних.
- Для невеликих проектів SaaS, які не вимагають значного завантаження бази даних, все, що справді потрібно, — це лише зберігання даних у спосіб реляційної моделі даних.
AWS MariaDB
Джерело: aws.amazon.com
MariaDB все ще є повністю відкритою базою даних, створеною колишніми розробниками MySQL (після придбання MySQL компанією Oracle).
З точки зору сумісності, будь-яка база даних MySQL буде нормально працювати в MariaDB.
Чим це відрізняється
З точки зору функцій, відмінностей від MySQL небагато, але властивість відкритого вихідного коду є родзинкою.
Технічно існує досить багато корисних функцій, які доступні в MariaDB, але не в MySQL.
Основні недоліки
Дуже схоже на випадок MySQL.
Коли вибрати
- Якщо вам дуже подобається ваша поточна локальна реалізація MariaDB і ви не хочете переходити на Aurora DB з будь-якої причини.
- Якщо ви хочете залишатися по-справжньому відкритим із вашим рішенням бази даних у хмарній екосистемі AWS.
Приклад використання
Дуже схоже на випадок MySQL.
Заключні слова
Подібним чином, оскільки Oracle DB був рішенням у локальному світі, здається, що Aurora DB займає це місце в хмарному світі AWS. Принаймні з точки зору наборів функцій, це найкраще, що ви можете отримати.
І навіть якщо ви не дуже зацікавлені в головних зацікавлених сторонах, корисно знати, що все одно існують досить прості варіанти перенесення наявної бази даних у хмару AWS.
А ще краще – за допомогою цього перемикача ви автоматично отримаєте функції, яких, швидше за все, не вистачало до того часу. Найважливіше те, що кращі можливості розширення сховища, висока доступність і горизонтальна масштабованість є рідними властивостями хмарного середовища.