Ми будуємо веб-платформу, яка включає в себе кілька сервісів, кожен з яких має свої базові дані. Ці служби будуються незалежно, керуючись принципами сервісно-орієнтованої архітектури , але вони вступають у відповідь на потенційно пов'язані дані. Ми розглядаємо, чи повинні ці сервіси мати одну велику базу даних чи кожен має свою базу даних. (Ми плануємо використовувати SQL Server 2008 Enterprise на кластері Windows 2008.)

Деякі з переваг кожного з розглянутих нами підходів включають:

Єдина база даних

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

Кілька баз даних

• Роботи з технічного обслуговування, проблеми з обладнанням, порушення безпеки та інше не обов'язково впливають на всю платформу
• Якщо припустити, що кожна база даних працює на окремому апаратному забезпеченні, масштабування кількох машин дає більше переваг від продуктивності, ніж масштабування однієї великої

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

На мою думку, ключовим диференціатором справжніх систем SOA (над псевдо SOA, ntier / розподіленими системами, які стають всюдисущими) є те, що між дискретними службами повинна бути нульова взаємодія. Якщо це досягнуто, будь-яка програма, яку ви складаєте з цих служб, може бути та має бути побудована для допущення відмови будь-якої складової. Помилка знижує функціональність, але сервіс підтримується.

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

Я б рекомендував читати сайти, такі як HighScalability.com, які копаються в архітектурі, прийняті на веб-сайтах типу " невдалий" . Одним із моїх улюбленців пізнього часу була історія про Netflix Chaos Monkey, яку згадували у програмі Кодування жахів .

Адресуючи декілька пунктів у вашому запитанні:

У разі катастрофи відновити платформу до стійкого стану простіше.

Це правда, але, можливо, ви повинні задуматися над тим, як краще роз’єднати ці послуги, щоб це перестало бути проблемою. Крім того, існують методи, що забезпечують синхронізацію в декількох базах даних, наприклад, знаки транзакцій у SQL Server .

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

Тут можуть допомогти розподілені рішення кешу (memcached et al), але ви порушите принципи незалежності служби. Це було б порівняно з тим, що два сервіси безпосередньо спілкуються один з одним, або ще гірше, що служба має доступ до іншого сховища даних, взагалі минаючи сервісний інтерфейс. Дані неминуче будуть пов’язані між собою і передаватимуться між службами телефоном, що викликає виклик; складні рішення, як правило, полягають у тому, яка служба матиме власні частини даних. Сайти StackOverflow або програмістів можуть бути краще для вирішення більш загальних проблем SOA.

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

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

Якщо це не SOA, і ви просто маєте випадок, коли компоненти послуг цієї платформи будуються різними командами / постачальниками з логістичних причин, дотримуйтесь єдиної бази даних і повністю ігноруйте все вище! :)