マルチテナントアプリケーション用のPostgreSQLのスキーマ
マルチテナント アプリケーションと、これにPostgreSQLのスキーマを使用する方法について学習しています。
主題を調査して、私は 記事 を見つけました。この記事では、マルチテナントアプリケーションでPostgreSQLのスキーマを使用したときの経験が乏しいと著者が説明しています。主な問題は、移行のパフォーマンスが低下し、データベースリソースが大量に使用されることです。
スキーマを1つだけ持つ（テナント間でテーブルを共有する）と、テナントごとに1つのスキーマを分けるよりもパフォーマンスが向上するようです。しかし、私には奇妙に感じます。小さいテーブルのインデックスは大きいテーブルのインデックスよりも軽い傾向があるため、私は反対を考えるでしょう。
多数の小さなテーブル（複数のスキーマ）でデータを分離する場合、いくつかの巨大なテーブル（単一のスキーマ）でデータを分離するよりも、パフォーマンスが低下するのはなぜですか？
パフォーマンスは必ずしも悪くありません。この記事で説明しているように、アプリケーションの設計とワークロードに応じて、スキーマアプローチを改善または悪化させる特定の条件があります。 「テナントスキーマ」アプローチと「共有テーブル」アプローチのトレードオフについて説明します。
tenant-schemaは、比較的少数のかなり大きなテナントがある場合に最適です。この例としては、有料のサブスクリプションユーザーのみがいる会計アプリケーションがあります。あなたにとってより良いパフォーマンスのオプションとなるものは次のとおりです。
- それぞれが大量のデータを持つ少数のテナント
- テナントごとに多くのテーブルを持たない比較的単純なスキーマ
- 一部のテナントのスキーマをカスタマイズする必要がある
- テナントごとにデータベースロールを使用する機能
- テナントのデータをあるサーバーから別のサーバーに移行するための要件
- テナントごとにクラウド内の専用アプリサーバーを起動する機能
パフォーマンスの低いオプションとなるものには次のものがあります。
- それぞれ非常に少ないデータを持つ多くのテナント
- 各リクエストがテナントになる可能性がある接続へのステートレスなアプローチ
- すべてのテーブルのメタデータをキャッシュするクライアントライブラリまたはオーム（ActiveRecordなど）
- 効率的で高性能な接続プーリングおよび/またはキャッシュの要件
- 数千のテーブル間でスケーラビリティが低いVACUUMおよびその他のPostgreSQL管理操作の問題。
テナントスキーマが移行/スキーマの変更に悪いかどうかは、実際にそれらをどのように行っているかによって異なります。ユニバーサルスキーマの変更を迅速に展開することは悪いことですが、テナント間の段階的なロールアウトとしてスキーマの変更を展開するには適しています。
shared-tableは、テナントが多く、テナントのデータがほとんどない場合に適しています。この例は、無料のアカウントを許可するため、数千のアカウントを放棄したソーシャルメディアモバイルアプリケーションです。共有テーブルモデルを有益にする他の要素は次のとおりです。
- すべての接続が同じプールを使用できるため、接続プーリングに適しています
- 合計テーブル数が少ないため、PostgreSQLの管理に適しています
- テーブルの「セット」は1つしかないため、移行とスキーマの変更に適しています
共有テーブルの主な欠点は、アプリケーションレイヤーのすべてのクエリにテナントフィルター条件を追加する必要があることです。次の理由も問題です。
- 多くのテーブルを結合するクエリは、テナントフィルターがクエリ計画を無効にするため、パフォーマンスが低下する可能性があります
- 100百万行に成長するテーブルは、特定のパフォーマンスとメンテナンスの問題を引き起こす可能性があります
- テナント固有のアプリケーションの変更またはスキーマのアップグレードを行う方法がない
- サーバー間でテナントを移行するためのより高価な
そのため、どのモデルが「より良いパフォーマンス」を発揮するかは、どのトレードオフが最悪の結果になるかによって異なります。
また、実際のデータが共有テーブルに保存されるハイブリッドモデル「テナントビュー」もありますが、各アプリケーション接続では セキュリティバリアビュー を使用してデータを表示します。これには、各モデルのいくつかのトレードオフがあります。主に、テナントスキーマモデルのセキュリティ上の利点と、両方のモデルのパフォーマンス上の欠点のいくつかがあります。