Як створити базу даних для багатьох орендарів із спільними структурами таблиці?

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

Поки що я бачив три варіанти:

• Багатозахисна база даних (кожен орендар отримує свою власну - майже стільки ж, скільки 1 сервер на клієнта)
• Багатосхема (недоступна в MySQL, кожен орендар отримує власну схему у спільній базі даних)
• Спільна схема (наш сучасний підхід, можливо, з додатковою ідентифікаційною записом у кожному стовпчику)

Мульти-схема - моя улюблена (враховуючи витрати). Однак створення нового облікового запису та здійснення міграцій здається досить болючим, тому що мені доведеться перебирати всі схеми та змінювати їх таблиці / стовпці / визначення.

Q: Начебто, багатосхемові системи розроблені так, щоб вони мали дещо різні таблиці для кожного орендаря - я цього не хочу. Чи є якісь RDBMS, які дозволяють мені використовувати мульти-схему для багатоорендарів, де структура таблиці поділяється між усіма орендарями?

PS Під мульті я маю на увазі щось на кшталт ультра-мульти (10 000+ орендарів).

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

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

Існує цікава стаття MSDN під назвою Архітектура даних Multi-Tenant , яку ви, можливо, захочете перевірити. Ось як автори зверталися з оманою до спільного підходу:

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

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

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

• Скільки потенційних орендарів ви очікуєте націлити? Можливо, ви ніде не зможете оцінити потенційне використання з повноваженнями, але подумайте з точки зору порядку: ви будуєте заявку на сотні орендарів? Тисячі? Десятки тисяч? Більше? Чим більше ви очікуєте, що ваша база орендарів буде, тим більше шансів, що вам захочеться розглянути більш спільний підхід.

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

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

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

ОНОВЛЕННЯ: Далі про оновлення щодо очікуваної кількості орендарів.

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

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

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

• Довірені підключення до бази даних
• Фільтр перегляду орендарів
• Шифрування даних орендаря

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

ОНОВЛЕННЯ 2: Очевидно, хлопці Microsoft переїхали / створили нову статтю з цього приводу, оригінальне посилання вже відсутнє, і це нове: моделі оренди баз даних SaaS з кількома орендарями (кудо Шай Кереру)

Мій досвід (хоча і SQL Server) полягає в тому, що багатозахисна база даних - це шлях, де кожен клієнт має свою базу даних. Тож хоча у мене немає досвіду mySQL або Ruby On Rails, я сподіваюся, що мій внесок може додати певної цінності.

Причини:

1. безпека даних / відновлення після аварій. Дані кожної компанії зберігаються повністю окремо від інших, що знижує ризик компрометації даних (такі думки, як якщо ви введете помилку коду, що означає, що щось помилково дивиться на дані інших клієнтів, коли це не повинно), мінімізує потенційний збиток для одного клієнта, якщо такий конкретна база даних пошкоджується і т.д. Очікувані переваги для безпеки для клієнта ще більше (додатковий бонусний ефект!)
2. масштабованість. По суті, ви б розділили свої дані, щоб забезпечити більшу масштабованість - наприклад, бази даних можна розміщувати на різних дисках, ви можете підключити декілька серверів баз даних в Інтернеті і перемістити бази даних, щоб простіше розподілити навантаження.
3. налаштування продуктивності. Припустимо, у вас є один дуже великий клієнт і один дуже маленький. Моделі використання, обсяги даних тощо можуть сильно відрізнятися. Ви можете налаштувати / оптимізувати простіше для кожного клієнта, якщо вам потрібно.

Я сподіваюся, що це дійсно пропонує корисний внесок! Причин більше, але мій розум затуманився. Якщо це знову відкриється, я оновлю :)

Редагувати:
Оскільки я опублікував цю відповідь, зараз зрозуміло, що ми говоримо про 10 000+ орендарів. Мій досвід полягає у сотнях великих масштабних баз даних - я не думаю, що 10 000 окремих баз даних будуть занадто керованими для вашого сценарію, тому я зараз не віддаю перевагу багатодюймовому підходу для вашого сценарію. Тим більше, що зараз зрозуміло, що ви говорите про невеликі обсяги даних для кожного орендаря!

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

Нижче наводиться посилання на докладну інформацію про Salesforce.com про те, як вони реалізують багаторічні послуги:

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

Вони мають 1 величезну таблицю з 500 рядками стовпців (Value0, Value1, ... Value500). Дати і номери зберігаються у вигляді рядків у такому форматі, щоб їх можна було перетворити на рідні типи на рівні бази даних. Існують мета-таблиці даних, які визначають форму моделі даних, яка може бути унікальною для орендаря. Є додаткові таблиці для індексації, відносин, унікальних значень тощо.

Чому клопоту?

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

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

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

Більш масштабований підхід - це абсолютно те, що орендарі розподіляються випадковим чином, зберігаються в одній базі даних, але в різних логічних фрагментах (або таблицях ). Залежно від вашої мови існує низка бібліотек, які можуть допомогти у цьому. Якщо ви використовуєте Rails, у бібліотеці є бібліотека для забезпечення оренди acts_as_tenant, це допомагає забезпечити, щоб ваші запити орендарів лише відтягували ці дані. Існує також дорогоцінний камінь apartment- хоча він використовує модель схеми, але він допомагає при міграції всіх схем. Якщо ви використовуєте Django, є номер, але, здається, одна з найбільш популярних схем перебуває у схемах . Усе це більше допомагає на рівні програми. Якщо ви шукаєте щось більше на рівні бази даних безпосередньо, Citus зосереджується на створенні цього типу штрихуваннябагатоорендна робота більше працює з Postgres.