1つだけではなく、PostgreSQLで多くのスキーマを使用することの長所と短所？

（PostgreSql 9.4に裏打ちされた）大規模なSAASアプリケーションの場合、300,000を超えるアカウントがあり（そして成長中）、アカウントごとにスキーマを使用してデータをパーティション分割することと、すべてのデータを1つのスキーマに入れ、外部キーを使用することの長所と短所は何ですか。クエリで分割しますか？

以前、多くのスキーマを操作するときにpg_dumpが非常に遅くなっていましたが、それが今日のケースかどうかはわかりません。また、データベース構造の変更はすべてのスキーマで行う必要があることも認識しています。そしてプラス面では、スキーマをある物理サーバーから別の物理サーバーに移動するのは簡単です。また、スキーマをバックアップから復元することはもちろんです。データをそのようにパーティション分割することは理にかなっています。

それで、私が見逃している長所と短所は何ですか？

— ハレル
ソース

どちらも良く見えません。単一の巨大なテーブル（「垂直方向の増加」）を管理することは困難であり、膨大な数のスキーマ（「水平方向の増加」）を管理することも困難です。

— DanielVérité2015年

その数のアカウント（およびさらに多くのユーザー）がいる古いシステムを再構築しています。共有アプローチ（mySqlを使用）を使用しており、パフォーマンスに関しては問題なく機能しています。私の懸念は、そのレベルのパフォーマンスを維持しながら、それに保守性を追加することです。

— Harel

@Harel私は好奇心旺盛ですが、400kのスキーマでそれを試しましたか、それとも別のアーキテクチャ/テクノロジーに切り替えましたか？

— sthzg

考えてみたところ、あきらめました。私が作成しようとしていたスキーマの量は、これの実用的な使用を打ち負かすでしょう。すべてのレコードで古き良きアカウントIDフィールドを使用しました。私がやったことは、UUIDを優先して数値の自動インクリメントIDを削除することでした。つまり、整合性を壊すことを心配する必要なく、1つのdbから別のdbにアカウント全体を簡単に取得できます。

— Harel

明らかに、各ユーザースキーマの同じテーブルを扱っています。これの継承を検討しましたか？これは、いくつかのユースケースで両方の長所を提供します。いくつかの制限もあります。ユーザーごとに個別のスキーマを使用でき、すべてのユーザーテーブルを一度に非常に便利に検索できます。

関連：

それ以外に、少なくとも特権の付与/取り消しについて言及する必要があります。これは、スキーマが別々の場合ははるかに簡単です。

— アーウィンブランドステッター
ソース

継承について調べます。しかし、私の懸念はここのスケールにあります。私が読んだどこでも、人々はマルチテナントスキーマ戦略について話しているが、数十、数百、数千のスキーマに言及している。1つの場所で20Kスキーマについて言及しました。問題は、400Kスキーマが多すぎないかということです。それはファイル記述子の狂気を引き起こし、サーバーを殺しますか？押しているの？

— Harel

また、実際のユーザーデータとしてスキーマ自体を維持しながら、テナントデータ（アカウントとユーザー）をパブリックスキーマに保持するつもりでした。そのデータはスキーマ間で共有されることはなく、今後も共有されることはありません。

— Harel

継承はここでは私には役に立たないと思います。共有アプローチは、ユーザーまたはテナントに必須の外部キーを持つ単一のスキーマを使用するため、継承から得られるものは何もありません。

— Harel

この記事からinfluitive.io/…多数のテナントにとってマルチスキーマモードは良い方法ではないと思います。列tenant_id（古代の方法）が改善されました。

— Xiaohui Zhang