それぞれ独自の基礎データを持つ複数のサービスを組み込んだWebプラットフォームを構築しています。これらのサービスは Service-Oriented Architecture の原則に従って独立して構築されていますが、関連する可能性のあるデータに対してトランザクションを実行します。これらのサービスが1つの大きなデータベースを共有するべきか、それともそれぞれが独自のデータベースを持つべきかを検討しています。 (SQL Server 2008 EnterpriseをWindows 2008クラスターで使用する予定です。)
私たちがすでに検討した各アプローチの利点には、次のものがあります。
運用の観点からすると、このプラットフォームの各サービスが独自のデータベースを取得する方が有利ですか、それともすべて同じデータベースに格納する方が有利ですか?この質問への回答を提供する主な要因は何ですか?
私の意見では、真のSOAシステム(疑似SOA、ユビキタスになったntier /分散システム)の主な差別化要因)は、個別のサービス間に相互作用がないことです。これが達成される場所、これらのサービスから作成するアプリケーションは、一貫性のある部分の障害を許容するように構築でき、構築する必要があります。障害により機能が低下しますが、サービスは維持されます。
このシナリオでは、各サービスの基盤となるデータベースを分離することが論理的または必須です。ただし、相互に依存しているサービスがある場合、分割から得られることはほとんどありません(おそらく何もありません)。
絶対に失敗しないタイプのWebサイトで採用されているアーキテクチャを詳しく調べる HighScalability.com などのサイトを読むことをお勧めします。最近の私のお気に入りの1つは、 コーディングホラー で言及された Netflix Chaos Monkey のストーリーでした。
あなたの質問のいくつかのポイントに対処します:
災害が発生した場合、プラットフォームを一貫した状態に復元する方が簡単です。
これは真実ですが、おそらくこれらのサービスをより適切に分離して、これが問題にならないようにする方法について考えるべきです。または、複数のデータベース間で同期を確実にする方法があります SQL Serverのトランザクションマーク など。
複数のサービスによって参照されるデータの場合、1つのサービスによってキャッシュされたデータは、すぐに別のサービスによって使用される可能性があります。
分散キャッシュソリューション(memcachedなど)はここで役立ちますが、サービスの独立性の原則に違反することになります。これは、2つのサービスが互いに直接通信すること、またはサービスが別のデータストアにアクセスして、サービスインターフェイスを完全にバイパスすることに相当します。必然的にデータは関連付けられ、呼び出し元のプラットフォームによってサービス間で渡されます。トリッキーな決定は、どのサービスがどのデータを所有するかということです。 StackOverflowやProgrammersのサイトは、より一般的なSOA問題に役立つように配置する方がよいでしょう。
各データベースが別々のハードウェア上にあると仮定すると、スケールアップにより、パフォーマンスが向上します。
確かに、単一のマシンをスケールアップするよりも、スペックの低い複数のマシンにスケールアウトする方が安上がりです。ただし、追加の開発作業と運用の複雑さのソフトコストを考慮に入れると、ハードウェアコストの削減は総所有コストに比べて小さくなります。
これがSOAではなく、このプラットフォームのコンポーネントサービスがロジスティック上の理由で異なるチーム/サプライヤーによって構築されている場合は、単一のデータベースを使用し、上記のすべてを完全に無視してください。 !:)