SaaSアプリケーションがさまざまな方法でホストされているのを見てきました。機能とモジュールを複数のデータベースに分割することをお勧めしますか?たとえば、あるDBにUserテーブル、別のDBに機能/アプリ固有のテーブル、別のDBに他の一般的に共有されているテーブルなどを配置しますか?
10 に答える
1つのデータベースから始めます。プロジェクトで必要な場合は、データ/機能を分割します。
LinkedInから学べることは次のとおりです。
- 単一のデータベースは機能しません
- 参照整合性は不可能になります
- データの損失は問題です
- 適度に効果的な場合でも、キャッシングは良好です
- 成長軌道を過小評価しないでください
ソース:
High Scalabilityは、SaaSアプリケーションをスケーリングするための優れたブログです。前述のように、提案したようにデータベース間でテーブルを分割することは、一般的に悪い考えです。ただし、同様の概念はシャーディングであり、同じ(または同様の)スキーマを保持しながら、データを複数のサーバーに分割します。たとえば、ユーザー1〜5000はserver1にあり、ユーザー5000〜10000はserver2にあります。アプリケーションが使用するクエリによっては、効率的なスケーリング方法になる場合があります。
SaaSアプリケーションの場合、複数のテナントに複数のデータベースを使用しますが、通常はモジュールごとに分割しません。
これは、SaaSアプリケーションの設計で見た中で最も一般的なモデルです。基本スキーマは、アプリケーションに追加するテナントごとに複製されます。
外部キーを使用できるため、単一のデータベースを持つことがデータの整合性に最適です。データを複数のデータベースに分割する場合、この組み込みのデータ整合性を実現することはできません。データが関連していない場合、これは問題ではありませんが、関連している場合、あるデータベースに別のデータベースと矛盾するデータが含まれている可能性があります。この場合、データベースをスキャンして一貫性のないデータを定期的にスキャンし、適切に処理できるようにするコードを作成する必要があります。
ただし、サイト/アプリケーションを高度にスケーラブルにする必要がある場合(インターネット規模など)、複数のデータベースが必要になる場合があります。たとえば、各データベースを異なる物理サーバーでホストできます。
必要性を示唆する強力な証拠が見られない限り、データベースを特徴ごとに分割することはお勧めできません。多くの場合、1 つのトランザクションの一部として 2 つのデータベースを更新する必要がありますが、分散トランザクションを扱うのははるかに困難です。さらに、データベースを分割する必要がある場合は、シャーディングを使用できる場合があります。
自問してみてください。すべてを別々のデータベースに移動することで何が得られますか?
管理の面で多くの苦痛は私の推測でしょう。私は個人的にすべてを単一のデータベースに入れたいと思っています。後で単一のデータベースでは解決できない問題が発生した場合は、データを複数のデータベースに移行します。
自然なデザインに保ちます (必要なだけ非正規化し、必要なだけ正規化します)。DB モデルをモジュールに分割し、サービス (データを所有する) をデータの前面に配置することで、サービス指向の原則を念頭に置きます。
データベースを使用する理由
Hadoop、Voldemort (project-voldemort.com が開発し、LinkedIn が使用) などの分散ストレージ システムを使用するのは良い考えだと思います。
money operations のような重要なデータには db が適していると思いますが、それ以外の場合は分散ストレージを使用できます。