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