データベースでのクエリに関して、どちらの方法がより効率的かを知りたいです。
マルチテナント データベースでは、クエリは問題の一部にすぎません。問題のその他の部分は、コスト、データの分離と保護、メンテナンス、および災害復旧です。これらは重要です。マルチテナント データベースでは、クエリの効率だけを考慮することはできません。
マルチテナント ソリューションは、テナントごとに 1 つのデータベース (何も共有しない) から、テナントごとに 1 つの行 (すべてを共有する) までさまざまです。
「何も共有しない」、「別のデータベース」、またはテナントごとに 1 つのデータベース
- クライアントごとに最も高価です。(多数のクライアントは、多数のサーバーを意味します。)
- 最高度のデータ分離。
- 1 つのテナントのディザスター リカバリーは、単純明快です。
- 変更はすべてのデータベースで実行する必要があるため、メンテナンスは理論的には困難です。しかし、dbms は、各データベースでのストアド プロシージャの実行を簡単にサポートする場合があります。(たとえば、SQL Server には文書化されていないシステム ストアド プロシージャ sp_msforeachdb があります。おそらく独自に作成できます。)
- 「Shared Nothing」も最も簡単にカスタマイズできますが、メンテナンスの問題も発生します。たとえば、各テナントには異なる使用パターンがある可能性があり、これは、各テナントには、他のテナントには必要のないいくつかのインデックスが必要になる可能性があることを示唆しています。それは「何も共有しない」ことと関係があります。「すべてを共有」(下記) では不可能です。
- テーブルあたりの最小行数。クエリ速度はほぼ最適です。
「すべてを共有」、「スキーマを共有」、または「惑星ごとに 1 つのデータベース」
- テナントあたりの費用が最も安い。
- 最低レベルのデータ分離。すべてのテーブルには、行が属するテナントを識別する列があります。テナントの行はすべてのテーブルに混在しているため、他のテナントのデータを誤って公開することは比較的簡単です。
- 単一テナントのディザスタ リカバリは比較的複雑です。多くのテーブルで個々の行を復元する必要があります。一方、単一テナントの災害は比較的まれです。ほとんどの災害は、おそらくすべてのテナントに影響を与えます。
- すべてのテナントがテーブルを共有するため、構造のメンテナンスがより簡単になります。ただし、変更ごとにすべてのテナントと通信して調整する必要があるため、通信負荷が増加します。簡単にカスタマイズできるものではありません。
- テーブルあたりの最大行数。クイック クエリは難しくなりますが、テナント数と行数によって異なります。VLDB 領域に簡単にひっくり返る可能性があります。
「何も共有しない」と「すべてを共有する」の間に「共有スキーマ」があります。
「共有スキーマ」
- テナントはデータベースを共有しますが、各テナントには独自の名前付きスキーマがあります。コストは「何も共有しない」と「すべてを共有する」の間に収まります。大規模なシステムでは、通常、「何も共有しない」よりもサーバーが少なくて済み、「すべてを共有する」よりも多くのサーバーが必要です。
- 「すべてを共有する」よりもはるかに優れた分離。「何も共有しない」ほどの分離ではありません。(スキーマに対するパーミッションを GRANT および REVOKE できます。)
- 1 つのテナントのディザスター リカバリーでは、多くのスキーマの 1 つを復元する必要があります。これは、dbms に応じて、比較的簡単な場合とかなり難しい場合があります。
- メンテナンスは「何も共有しない」よりも簡単です。「すべてを共有する」ほど簡単ではありません。データベース内の各スキーマで実行されるストアド プロシージャを作成するのは比較的簡単です。「何も共有しない」よりも、テナント間で共通のテーブルを共有する方が簡単です。
- 通常、「共有なし」よりもサーバーあたりのアクティブなテナントが多くなります。これは、より多くのリソースを共有 (劣化) することを意味します。しかし、「すべてを共有する」ほど悪くはありません。
Microsoft には、マルチテナント アーキテクチャに関する詳細な記事があります。(リンクは、複数ページのドキュメントの 1 ページにすぎません。Microsoft はその後、そのページを削除しました。現在、リンクは、archive.org のコピーへのリンクになっています。)