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