web-dev-qa-db-ja.com

プラットフォームの設計：1つのデータベースまたは複数のデータベース？

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

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

単一のデータベース

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

複数のデータベース

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

運用の観点からすると、このプラットフォームの各サービスが独自のデータベースを取得する方が有利ですか、それともすべて同じデータベースに格納する方が有利ですか？この質問への回答を提供する主な要因は何ですか？

database-designdeployment
31
Nick Chammas

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

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

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

あなたの質問のいくつかのポイントに対処します：

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

これは真実ですが、おそらくこれらのサービスをより適切に分離して、これが問題にならないようにする方法について考えるべきです。または、複数のデータベース間で同期を確実にする方法があります SQL Serverのトランザクションマーク など。

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

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

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

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

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

18
Mark Storey-Smith