У який момент одна база даних на кожного клієнта стає нездійсненою?

Для однієї з наших систем ми маємо чутливі клієнтські дані і зберігаємо дані кожного клієнта в окремій базі даних. У нас є близько 10-15 клієнтів для цієї системи.

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

Будь-які думки з цього приводу?

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

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

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

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

• Обробка зростаючої кількості орендарів у архітектурі баз даних багатьох орендарів

• База даних з багатьма орендарями за допомогою SQL Server 2008?

• Автоматизація резервного копіювання великої кількості баз даних

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

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

• окремі БД
• окремі схеми
• спільна схема

Зараз ви перебуваєте на етапі окремих баз даних, який пропонує найкращий поділ (ізоляцію між орендарями), але це найскладніше в управлінні. Коли ви переростете в сотні орендарів, ви зрозумієте, що логістика адміністрування 100-ти БД далеко не банальна. Подумайте про відновлення резервного копіювання (розташування резервних файлів, робочих місць, графіків тощо). Подумайте, як ви будете контролювати та керувати розподілом файлів, використовуваним простором на диску та ростом бази даних у сотнях БД. Подумайте, яким буде ваш сценарій з високою доступністю / відновлення після аварій у найближчому майбутньому з 1000 орендарем? 1000 дзеркальних БД, 1000 сеансів доставки журналів? Подумайте, що якщо через 6 місяців ваша команда розробників прийде до вас і скаже «Я знаю, як надати цю приголомшливу особливість нашому продукту, ми використаємо транзакційну реплікацію!», Що ви скажете? "звичайно, дозвольте мені створити 500 видавців,"! Неможливо керувати сотнями БД, але якщо ви плануєте, краще відшліфуйте свої навички PowerShell і перестаньте користуватися інструментами управління користувальницьким інтерфейсом прямо зараз .

Додатково потрібно врахувати, що декілька (сотні) БД мають вимірний вплив на продуктивність та вартість:

• фізичне простір на диску менш ефективно використовується (кожна база даних повинна мати деяку запасну кімнату, ви будете мати цю запасну кімнату , помноженої на кількість блоків даних)
• Ні в якому разі не можна створити виділений журнальний диск для інтенсивних записів, вам доведеться перемістити всі ці LDF на один (або більше) SSD-накопичувачів
• Запис у журнал буде менш ефективним у частих комісіях, оскільки вони розповсюджуватимуться на безліч записів окремих блоків журналу та сукупності в один (ви отримаєте недовикористані блоки журналів). Дивіться, що таке LSN: Номер послідовності журналу, щоб зрозуміти, про що я говорю.

Окремі БД мають деякі переваги, хоча через ізоляцію, головна перевага - незалежне резервне копіювання / відновлення.

Сценарій, як ваш, хоча є ідеальним кандидатом для баз даних SQL Azure . Ніяке адміністрування дискового простору, не потрібно надавати HA / DR, зростати до сотень / тисяч БД тощо.

На моїй попередній роботі ми розмістили не одну базу даних на кожного клієнта - у більшості випадків це було більше ніж! Коли я пішов, в одному кластері MariaDB працювало понад 4500 баз даних, майже 7000 в іншому (за іронією долі меншому) кластері та 4 "осколки" (повністю окремі, незалежні сервери веб-серверів та баз даних, навіть у повністю окремому центрі обробки даних) на кожному хостінгу 200-500 баз даних на одному сервері MySQL. І ця компанія все ще зростає на хорошому кліпі.

Довго і коротко, що успіх цієї компанії доводить, що така архітектура справді здійсненна. (Caveat: На відміну від очевидних здобутків в ізоляції за допомогою окремих баз даних, до всіх даних можна було отримати доступ до трійки щільно зв'язаних додатків, які використовували один і той же користувач бази даних / пропуск! Я підозрюю, що продуктивність може зазнати незрозумілих втрат, якщо кожен клієнт мав окремого користувача / пропуск, але лише незначно.)

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

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