У цьому пості ми поділимося досвідом реалізації гібридної та динамічної системи багатокористувацької бази даних для одного з проектів, у яких ми брали участь. Якщо вам незнайомі деякі з цих концепцій, не хвилюйтеся — ми розглянемо їх детальніше.
Розуміння багатокористувацької архітектури бази даних
Щоб краще зрозуміти багатокористувацькість бази даних, давайте спершу розглянемо одиничну оренду, яка є її протилежністю.
Одинична оренда
Одинична оренда (Single tenancy) — це архітектура програмного забезпечення, де кожен клієнт (орендар) має свою окрему інстанцію програмного забезпечення та відповідну йому базу даних. Такий підхід забезпечує ізоляцію між клієнтами, але потребує більших ресурсів та витрат на обслуговування.
Багатокористувацька оренда
Багатокористувацька оренда (Multitenancy), в свою чергу, є архітектурою, де кілька клієнтів (орендарів) використовують одну й ту ж інстанцію програмного забезпечення, при цьому їхні дані логічно відокремлені, що може включати одну або кілька баз даних.
Цей підхід є більш ефективним з точки зору використання ресурсів і простіший в обслуговуванні, але може мати потенційні ризики для безпеки та продуктивності.
Переваги та недоліки
Переваги багатокористувацької оренди включають економічність, ефективне використання ресурсів, простоту обслуговування та масштабованість. Недоліки багатокористувацької оренди полягають у потенційних ризиках для безпеки та проблемах з продуктивністю через спільне використання ресурсів.
Гібридна багатокористувацька оренда: рівні гранулярності
Для сегрегації даних орендарів в межах домену даних можна використовувати різні рівні гранулярності. Важливо пам’ятати, що одна й та сама інстанція програми завжди є спільною. Ці рівні включають:
Рівень бази даних
Кожен орендар має власну базу даних. Цей підхід забезпечує найвищий рівень безпеки та простоту створення резервних копій, але супроводжується вищими витратами: дорожчий, потребує більше часу розробників для приєднання нового клієнта та вищого споживання ресурсів.
Рівень схеми
Орендарі використовують одну й ту ж базу даних, але мають власну спеціалізовану схему PostgreSQL.
Цей рівень забезпечує певний ступінь ізоляції даних, але керування резервними копіями може бути складним.
Рівень рядків
Орендарі використовують одну й ту ж базу даних і схему, але їхні дані розділяються на рівні рядків за допомогою ідентифікатора орендаря. Це найекономічніший підхід, але він може призвести до проблем з продуктивністю та слабшої ізоляції даних.
Гібридний
Цей підхід дозволяє вибирати між ексклюзивною базою даних або спільною базою даних, залежно від конкретних вимог кожного орендаря. Така гнучкість дає розробникам можливість знаходити баланс між витратами, продуктивністю та ізоляцією даних відповідно до потреб.
Динамічна багатокористувацька оренда: втручання програміста та виконання
Динамічна багатокористувацька оренда дозволяє додавати орендарів до системи під час виконання без необхідності ручного втручання програміста. На відміну від цього, нединамічні рішення вимагають від програмістів налаштовувати нових орендарів вручну.
Наприклад, при використанні Ruby on Rails 6.0 для шардінгу (sharding), програміст має змінити файл database.yml і впровадити оновлену конфігурацію для кожного нового орендаря (tenant).
Впровадження динамічного багатокористувацького середовища (multitenancy) дозволяє розробникам автоматизувати процес додавання нових орендарів до додатка, зменшуючи навантаження і потенційні помилки, що можуть виникнути під час ручної настройки. Такий підхід дозволяє швидше приєднувати нових клієнтів і покращує загальну масштабованість системи, хоча це може не мати сенсу, якщо система має лише кілька клієнтів і низький рівень додавання нових клієнтів.
Багатокористувацьке середовище (Multitenancy) з Ruby on Rails та PostgreSQL: популярні рішення
Два з найбільш популярних рішень для реалізації багатокористувацького середовища в Rails додатках з використанням PostgreSQL — це гем Apartment та вбудований шардінг (sharding) в Ruby on Rails 6.0.
Почесне згадування заслуговує гем actastenant, який забезпечує багатокористувацьке середовище (multitenancy) на рівні рядків.
Гем Apartment
Найпопулярніший гем для багатокористувацького середовища в Rails називається Apartment. Він добре побудований і має багато функцій, але його офіційну підтримку припинили три роки тому, і він офіційно не підтримує Rails 6.0. Однак є форк, який продовжує підтримувати цей гем. Хоча він підтримує багатокористувацьке середовище на рівні схеми (schema-level) та бази даних (database-level), він не дозволяє використовувати обидва підходи одночасно, тобто це не "гібридне" рішення. Проте гем Apartment є динамічним.
Вбудований шардінг (Sharding) в Ruby on Rails 6.0
Вбудований шардінг (sharding) в Ruby on Rails 6.0 підтримує гібридну модель, оскільки вимагає визначення підключення до бази даних, що включає інформацію як про базу даних, так і про схему.
Однак це не є динамічним рішенням, оскільки потрібно визначити орендарів (tenants) у файлі database.yml і впровадити цю конфігурацію, щоб додати нових орендарів.
Підсумовуючи, при виборі між гему Apartment і вбудованим шардінгом (sharding) в Rails 6.0 для реалізації багатокористувацького середовища (multitenancy) в Rails додатках з PostgreSQL, слід враховувати бажаний рівень деталізації та чи потрібне динамічне або статичне рішення.
Гібридне і динамічне багатокористувацьке середовище з Ruby on Rails і PostgreSQL: практичне рішення
Щоб реалізувати гібридне і динамічне багатокористувацьке середовище за допомогою Ruby on Rails і PostgreSQL, ми будуємо на основі вбудованого шардінгу (sharding) в Ruby on Rails 6.0, який вже забезпечує гібридну основу. Завдання полягає в тому, щоб зробити це рішення динамічним, замінивши статичну конфігурацію в файлі database.yml на рішення, яке працює під час виконання.
Наш підхід полягає в використанні публічної схеми, де ми зберігаємо конфігурації підключення до бази даних для кожного орендаря. Коли робітник (worker) запускається, він завантажує ці конфігурації з бази даних.
З мінімальними зусиллями Rails створює пул підключень для кожного орендаря (tenant), з якого ми можемо отримувати підключення. Крім того, нам потрібно перезавантажити робітників (workers) щоразу, коли додається новий орендар, щоб він став доступний для всіх робітників.
Завдяки впровадженню цього практичного рішення, ми успішно інтегрували гібридне і динамічне багатокористувацьке середовище бази даних з Ruby on Rails і PostgreSQL. Результат — це гнучка, ефективна та масштабована архітектура, яка відповідає унікальним вимогам кожного орендаря, водночас максимально використовуючи ресурси.
У наступному пості ми реалізуємо гібридне і динамічне багатокористувацьке середовище, побудоване на основі шардінгу (sharding) Ruby on Rails 6.0, слідкуйте за оновленнями!
Перекладено з: Hybrid and Dynamic Database Multitenancy with Ruby on Rails