単一接続の接続プール

Question

私は接続プールに関して直面している状況について意見を得たいと思います。

私はマルチテナントアプリケーションで作業しているSW開発者です。 1つのDBがあり、各テナント（クライアント）には独自のスキーマがあります。接続されたテナントごとに、ソロプロセスが開始され、ソロDB接続が確立されます。近い将来、私は300 +同時テナント環境でそれを使用する必要があります。

私が読んだところから、ポストグルに多くの接続（100+）を使用することは勧められません。 1つの解決策は、接続プールを使用することです。もう1つは、より多くのDBサーバーを使用することです。

私は接続プーラー（pgBouncer、pgPool）について考えていました。しかし、現在のアプリケーションの状態では、少し問題があります。ここで「問題」の項目と提案されたソリューションのリストは、次のとおりです。

1. プロセスの全体の寿命のためのサーバーへの単一の接続 - 私たちは頻繁に一時テーブルとプリペアドステートメントを使用しているためです。一時テーブルの期間は可変ですが、ほとんどの場合、複数のトランザクションにまたがります。

   • 接続プールが "フリー"接続を返すので、指定された一時テーブルが返された接続で作成されたかどうかはわかりません。しかし、私は事前定義されたスキーマで "一時テーブル"を作成することで回避することができると思います（しかし、孤立した一時テーブルをきれいに閉じたり、クラッシュしていないプロセスから削除するためのバックグラウンドタスクが必要です。自動的に閉じる）。準備されたステートメントについては、回避策が見つかりませんでした。

2. 「set search_path = "custom_schema"、public; - これは各テナントのアプリケーション開始時に行われるため、正しい表が使用されます。

   • これは、各トランザクションでset search_path = ...コマンドを発行することで修正できます。それは安く/速くなければなりません。

3. 一時テーブルに依存するトリガーの使用 - これはいくつかのものの自動ロギングに使用されます。アプリケーションの起動時に自動的に作成される一時テーブルが使用されます。

   • ため、テーブル名の前述の「カスタム・テーブル・アプローチは、」（複数のテナントが、その後悪いである、複数回同じテーブルを作成します）一定でなければならない使用することはできませんようまだ解決策を持っていません。

私は再設計かどうかについて考え始める必要があるのであれば、私は知りません。 DBサーバーを追加するだけで、すべてを実行することができれば、それを再設計する必要はありません。

あなたはどう思いますか？

は、これらの事は pool_mode = sessionとpgbouncerに問題はありませんあなた

Answer 1

ありがとうございます。