Реляційні бази даних на основі SQL, такі як MySQL, PostgreSQL та Oracle, широко використовуються завдяки своїй високій консистентності, відповідності стандарту ACID та структурованому управлінню даними. Однак, коли мова йде про масштабованість, ці бази даних зазвичай є вертикально масштабованими, а не горизонтально масштабованими. У цій статті ми пояснимо, чому SQL бази даних зазвичай краще підходять для вертикального масштабування, та розглянемо виклики, з якими вони стикаються при горизонтальному масштабуванні.
1. Відповідність ACID та управління транзакціями
Однією з основних переваг SQL баз даних є їх відповідність властивостям ACID: Атомарність, Консистентність, Ізоляція та Довговічність. Ці властивості є критичними для того, щоб транзакції в базах даних виконувалися надійно, навіть у випадку відключення електрики або збоїв системи. Однак досягнення відповідності ACID у розподіленій системі (тобто горизонтальне масштабування через кілька вузлів або серверів) є складним завданням.
У горизонтально масштабованій системі управління розподіленими транзакціями вимагає уважної координації між вузлами, що є ресурсомістким і збільшує затримку. Для підтримки властивостей ACID в розподіленому середовищі часто використовуються техніки, такі як Двохфазне підтвердження (2PC) або Paxos, які можуть уповільнити роботу. Складність підтримки гарантій ACID у розподіленому середовищі є однією з причин того, чому традиційні SQL бази даних більш підходять для вертикального масштабування.
2. Схема та з'єднання (Joins)
SQL бази даних використовують фіксовану схему для зберігання даних, де кожна таблиця повинна відповідати заздалегідь визначеній структурі. Ця структура забезпечує цілісність даних, але також ускладнює розподіл даних по кількох вузлах.
У горизонтально масштабованих системах підтримка схеми на кількох серверах вимагає додаткових ресурсів для синхронізації та реплікації даних. Крім того, SQL бази даних підтримують складні запити з з'єднаннями (joins) між кількома таблицями.
Розподіл даних між кількома вузлами, одночасно зберігаючи ефективність виконання з'єднань між таблицями, є великою проблемою. Коли пов'язані дані знаходяться на різних серверах, базі даних потрібно або переміщати дані між серверами, або виконувати розподілені з'єднання, що може призвести до значного сповільнення роботи. Це робить горизонтальне масштабування в SQL базах даних складнішим за замовчуванням.
3. Вертикальне масштабування: Традиційний підхід
SQL бази даних були розроблені з урахуванням вертикального масштабування, тобто вони спочатку оптимізувалися для роботи на одному сервері з достатньою кількістю процесора, пам'яті та місця на диску.
Вертикальне масштабування працює шляхом покращення апаратного забезпечення сервера для підвищення його продуктивності — чи це додавання нових ядер процесора, збільшення пам'яті або розширення сховища. Цей метод є простішим і більш економічним для багатьох випадків, оскільки не потребує складнощів з розподілом даних між кількома вузлами. Вертикальне масштабування дозволяє SQL базам даних обробляти більше даних та працювати з більшою кількістю одночасних користувачів без необхідності складного розподілу даних, реплікації або механізмів підтримки консистентності.
Також легше керувати можливістю індексації, кешування та оптимізації запитів в монолітній, вертикально масштабованій базі даних. Не потрібно хвилюватися про розподіл даних чи затримки мережі, що робить вертикальне масштабування кращим вибором для багатьох додатків, які не потребують величезного обсягу зберігання даних або розподіленої архітектури.
4. Складність шардингу (Sharding)
Шардинг — це процес поділу бази даних на менші, більш керовані частини (шарди) і розподілу цих частин між кількома вузлами або серверами. Хоча шардинг можливий в SQL базах даних, він приносить з собою кілька складнощів:
- Вибір ключа шарду: Вибір відповідного ключа шарду критичний для рівномірного розподілу даних між кількома серверами.
Погано вибрані ключі шарду можуть призвести до гарячих точок даних (data hotspots), коли деякі сервери обробляють більше даних і трафіку, ніж інші, що призводить до вузьких місць у продуктивності. - Консистентність даних: Підтримка консистентності даних між шардовими системами, водночас забезпечуючи відповідність транзакцій стандарту ACID, є надзвичайно складною. Управління цією консистентністю в розподіленому середовищі вимагає складних алгоритмів і координації між вузлами.
- Перебалансування: Зі зростанням даних шард потрібно перерозподіляти або перебалансувати між вузлами. Цей процес займає багато часу і може вимагати простою або складних алгоритмів для перенесення даних з одного шару в інший без переривання роботи сервісу.
Отже, хоча шардинг дозволяє SQL базам даних масштабуватися горизонтально, він приносить певний рівень складності, який не так поширений в NoSQL базах даних, спроектованих із урахуванням горизонтального масштабування.
5. Реплікація "майстер-раб" і її обмеження
SQL бази даних часто використовують реплікацію "майстер-раб" або мультимайстерну реплікацію для масштабування читання та забезпечення високої доступності. Однак ці методи реплікації мають обмеження, що ускладнюють справжнє горизонтальне масштабування:
- Реплікація "майстер-раб": У такій конфігурації один вузол (майстер) обробляє всі операції запису, тоді як кілька вузлів-рабів обробляють операції читання. Це дозволяє масштабувати читання, але створює єдину точку відмови для операцій запису. Крім того, з ростом додатків, що обробляють багато записів, вузол-майстер стає вузьким місцем, обмежуючи здатність бази даних обробляти великий обсяг записів.
- Мультимайстерна реплікація: Це дозволяє виконувати записи на кількох вузлах, але вводить значну складність у забезпечення консистентності даних між усіма вузлами. Розв'язання конфліктів і синхронізація даних між вузлами може призвести до збільшення затримок та додаткових витрат.
6. Торг між консистентністю та доступністю (Теорема CAP)
SQL бази даних надають перевагу консистентності над доступністю та толерантністю до розбиття, як це описано в Теоремі CAP. Теорема CAP стверджує, що в розподіленій системі база даних може одночасно надавати лише дві з трьох таких гарантій: Консистентність, Доступність та Толерантність до розбиття.
Більшість SQL баз даних розроблені для надання переваги консистентності для забезпечення цілісності даних. Однак це означає, що, коли база даних масштабується горизонтально (розподіляється по кількох вузлах), забезпечення консистентності між усіма вузлами може призвести до зменшення доступності та довших часів відгуку.
Натомість NoSQL бази даних часто проектуються з поступовою консистентністю, надаючи перевагу доступності та толерантності до розбиття над суворою консистентністю. Такий підхід робить NoSQL бази даних більш придатними для горизонтального масштабування, оскільки вони можуть обробляти великі обсяги даних і трафіку без таких же витрат на підтримку суворої консистентності.
7. Спадок і монолітна архітектура
SQL бази даних існують вже кілька десятиліть і були побудовані з монолітною архітектурою. Це означає, що база даних передбачає, що всі операції можуть виконуватися на одному сервері, що робить її ефективною в налаштуваннях з одним вузлом, але менш гнучкою при горизонтальному масштабуванні.
Хоча сучасні SQL бази даних можуть підтримувати горизонтальне масштабування до певної міри, їх спадковий дизайн та складність адаптації до розподілених систем роблять їх менш придатними для великомасштабного горизонтального масштабування порівняно з альтернативами NoSQL, які були спроектовані з самого початку для розподілених та горизонтально масштабованих систем.
Висновок
SQL бази даних більш вертикально масштабовані, ніж горизонтально, головним чином через їх відповідність ACID, структуру схеми, залежність від складних з'єднань (joins) і монолітний дизайн. Вертикальне масштабування, що передбачає оновлення апаратного забезпечення одного сервера, є простішим і більш ефективним для багатьох випадків використання.
Однак, коли попит зростає і стає необхідним горизонтальне масштабування, SQL бази даних стикаються з такими викликами, як складність шардингу (sharding complexity), консистентність даних між вузлами (data consistency across nodes) та обмеження реплікації (replication limitations).
Хоча можливо горизонтально масштабувати SQL бази даних, це вимагає значних архітектурних змін і вводить складнощі, які є менш суттєвими для NoSQL баз даних, спроектованих з урахуванням горизонтального масштабування як основного принципу. Як результат, SQL бази даних краще підходять для застосунків, які не потребують масивного горизонтального масштабування, тоді як NoSQL бази даних часто вибираються через свою здатність обробляти великі, розподілені системи.
Перекладено з: Why SQL Databases are More Vertically Scalable than Horizontally Scalable