私たちは、それぞれが基礎となるデータを持つ複数のサービスを組み込んだWebプラットフォームを構築しています。これらのサービスは、Service-Oriented Architectureの原則に従って独立して構築されていますが、潜在的に関連するデータに対して処理します。これらのサービスが1つの大きなデータベースを共有するか、それぞれが独自のデータベースを持つかを検討しています。（Windows 2008クラスターでSQL Server 2008 Enterpriseを使用する予定です。）

すでに検討した各アプローチの利点には次のものがあります。

単一のデータベース

• 異なるサービスからのデータを関連付けることは、外部キーの制約によって結び付けることができます
• 分析抽出は、作成が簡単で実行が高速です
• 災害が発生した場合、プラットフォームを一貫した状態に復元する方が簡単です
• 複数のサービスによって参照されるデータの場合、あるサービスによってキャッシュされたデータは、すぐに別のサービスによって使用される可能性が高い
• 管理と監視は前もって簡単で安価です

複数のデータベース

• メンテナンス作業、ハードウェアの問題、セキュリティ侵害などは、必ずしもプラットフォーム全体に影響を与えるとは限りません
• 各データベースが個別のハードウェア上にあると仮定すると、複数のマシンをスケールアップすると、1つの大きなマシンをスケールアップするよりもパフォーマンス上のメリットが大きくなります

運用の観点から、このプラットフォームの各サービスが独自のデータベースを取得すること、またはそれらがすべて同じデータベースに配置されることは、より有利ですか？この質問の答えを伝える重要な要因は何ですか？

私の意見では、真のSOAシステムの重要な差別化要因は（疑似SOA、ユビキタスになりつつあるntier /分散システム上）、個別のサービス間の相互作用はゼロであるべきだということです。これが達成される場合、これらのサービスから構成するアプリケーションは、一貫性のある部分の障害に耐えるように構築できます。障害は機能を低下させますが、サービスは維持されます。

このシナリオでは、各サービスの基礎となるデータベースを分離することが論理的または必要です。ただし、相互に依存するサービスがある場合、分割から得られるものはほとんどありません（おそらく何もありません）。

決して失敗しないタイプのWebサイトで採用されているアーキテクチャを掘り下げるHighScalability.comなどのサイトを読むことをお勧めします。最近の私のお気に入りの1つは、コーディングホラーで言及されたNetflix Chaos Monkeyの話でした。

質問のいくつかのポイントに対処する：

災害が発生した場合、プラットフォームを一貫した状態に復元する方が簡単です。

これは事実ですが、これらのサービスをより適切に分離して、これが問題にならないようにする方法を検討する必要があります。または、複数のデータベース間で同期を確保する方法（SQL Serverのトランザクションマークなど）があります。

複数のサービスによって参照されるデータの場合、1つのサービスによってキャッシュされたデータは、すぐに別のサービスによって使用される可能性があります。

ここでは分散キャッシュソリューション（memcachedなど）が役立ちますが、サービスの独立性の原則に違反することになります。これは、2つのサービスが互いに直接通信すること、またはさらに悪いことに、サービスが別のデータストアにアクセスして、サービスインターフェイスを完全にバイパスすることに匹敵します。当然、データは関連し、呼び出しプラットフォームによってサービス間で渡されます。慎重な判断は、どのサービスがどのデータを所有するかによって決まります。StackOverflowまたはProgrammersサイトは、より一般的なSOAの問題を解決するのに適している場合があります。

各データベースが別々のハードウェア上にあると仮定すると、スケールアップによりパフォーマンスが向上します。

確かに、単一のマシンをスケールアップするよりも、複数の低スペックのマシンにスケールアウトする方が安価です。ただし、追加の開発努力と運用の複雑さのソフトコストを考慮すると、ハードウェアコストの低下は総所有コストに比べてd小になります。

これがSOAではなく、このプラットフォームのコンポーネントサービスがロジスティック上の理由で異なるチーム/サプライヤによって構築されている場合、単一のデータベースに固執し、上記のすべてを完全に無視してください！:)