必ずしもパフォーマンスが低下するわけではありません。記事で説明されているように、アプリケーションの設計とワークロードに応じて、スキーマのアプローチを改善または悪化させる特定の条件があります。 「テナントスキーマ」アプローチと「共有テーブル」アプローチのトレードオフについて説明します。
テナントスキーマ かなり大きなテナントが比較的少ない場合に最適です。この例は、有料サブスクリプションユーザーのみを使用する会計アプリケーションです。それをあなたにとってより良いパフォーマンスのオプションにするものは次のとおりです：
- それぞれに大量のデータがある少数のテナント
- テナントごとに多くのテーブルがない比較的単純なスキーマ
- 一部のテナントのスキーマをカスタマイズする必要があります
- テナントごとのデータベースロールを利用する機能
- テナントのデータをあるサーバーから別のサーバーに移行するための要件
- テナントごとにクラウド内の専用アプリサーバーを起動する機能
パフォーマンスの低いオプションとなるものは次のとおりです。
- それぞれのデータが非常に少ない多数のテナント
- 各リクエストが任意のテナントになる可能性がある接続へのステートレスアプローチ
- すべてのテーブル（ActiveRecordなど）のメタデータをキャッシュするクライアントライブラリまたはorm
- 効率的で高性能な接続プールやキャッシュの要件
- 数千のテーブル間で拡張性が低いVACUUMおよびその他のPostgreSQL管理操作の問題。
テナントスキーマが移行/スキーマ変更に適していないかどうかは、実際にはそれらをどのように行っているかによって異なります。ユニバーサルスキーマ変更を迅速に展開するのは良くありませんが、テナント間で段階的に展開するようにスキーマ変更を展開するのには適しています。
共有テーブル テナントが多く、多くのテナントのデータが非常に少ない状況に適しています。この例は、無料のアカウントを許可し、したがって何千もの放棄されたアカウントを持つソーシャルメディアモバイルアプリケーションです。共有テーブルモデルを有益にする他のことは次のとおりです。
- すべての接続で同じプールを使用できるため、接続プールに適しています
- テーブルの総数が少ないため、PostgreSQLの管理に適しています
- テーブルの「セット」は1つしかないため、移行やスキーマの変更に適しています
共有テーブルの主な欠点は、アプリケーション層のすべてのクエリにテナントフィルター条件を追加する必要があることです。また、次の理由で問題があります。
- テナントフィルタがクエリプランニングを破棄するため、多くのテーブルを結合するクエリのパフォーマンスが低下する可能性があります
- テーブルが1億行に増えると、特定のパフォーマンスとメンテナンスの問題が発生する可能性があります
- テナント固有のアプリケーションの変更やスキーマのアップグレードを行う方法はありません
- サーバー間でテナントを移行するのに費用がかかる
したがって、どのモデルが「パフォーマンスが優れている」かは、どのトレードオフが最も悪い結果をもたらすかによって異なります。
実際のデータが共有テーブルに保存されるハイブリッドモデル「tenant-view」もありますが、各アプリケーション接続はセキュリティバリアビュー データを表示します。これには、各モデルのトレードオフがいくつかあります。主に、テナントスキーマモデルのセキュリティ上の利点と、両方のモデルのパフォーマンス上の欠点のいくつかがあります。