接続プールの実行方法
各プラットフォームには、異なる接続プールインターフェイスがあります。使用する特定のプラットフォーム（Ruby + Railsなど）のドキュメントを読むか、PgBouncerなどの一般的なプーリングミッドレイヤーを使用する必要があります。
あるツール（たとえば、Zend Frameworkを使用したPHP）に関連する回答は、別のツール（Ruby on Railsなど）に関連する回答とは関係ありません。 PgBouncerのようなものを選択した場合でも、プラットフォームがトランザクションの有効期間を処理する方法、アプリのニーズに基づいて選択するプーリングモードなどに関連する詳細があります。
したがって、最初に、使用しているものとそれを使用して何をする必要があるかを判断する必要があります。 次に 接続プールを設定する方法を研究します。 （多くのツールでは、それはただ自動です。）
選択したプラットフォームのドキュメントを読んだ後も立ち往生している場合 、新しい詳細で具体的なを尋ねる プラットフォームに適切にタグ付けされた質問。
プーリングとミドルウェア
アプリをPostgreSQLに直接接続しないでください。 特に ランダムなクライアントからインターネット経由の場合。
PostgreSQLサーバーの近くにあるWebサーバーを使用し、Webサービス要求を受け入れて、可能な限り要求するようにスコープされた短いトランザクションで、明確に定義されたWebAPIを介してデータベースへのアクセスを仲介します。
これは、受け取った知識の場合だけではありません。それを行うのには十分な理由があり、インターネット上のランダムなデバイスからPostgreSQLを実行することには深刻な問題があります。
Pgと直接通信するAndroidアプリ
多くのクライアントからインターネット経由でPgと直接話す際の問題は、次のとおりです。
-
各PostgreSQLバックエンドには、アイドル状態であるかどうかに関係なく、コストがかかります。トランザクションプーリングモードのPgBouncerは、これをある程度支援します。
-
インターネットを介して作業していると、接続がランダムに失われます。 WiFiのドロップ、動的IPサービスでのIPアドレスの変更、容量がフェードアウトまたは最大化するモバイルサービス、またはパケット損失が大きいだけでよろめく。これにより、おそらくオープントランザクションで、不確定な状態の多くのPostgreSQL接続が残り、トランザクションで
<IDLE> in transaction問題と、実際に作業しているよりもはるかに多くの接続を許可する必要性。 -
これはトランザクションです。何かが終了しない場合は、トランザクションを終了して、効果がないことを確認できます。
中間層を持つことの利点
Androidデバイス上のアプリからのHTTPWebサービス要求に応答して、データベースアクセスのブローカーとして機能するサーバーは、大きな利点になる可能性があります。
-
バージョン管理されたAPIを定義できるため、新しい機能を導入したり、APIを変更する必要がある場合でも、古いクライアントを壊す必要はありません。これは、ストアドプロシージャまたは多くのビューを使用するPgで可能ですが、不格好になる可能性があります。
-
データベースアクセスの範囲とトランザクションの有効期間を厳密に制御します。
-
べき等APIを定義できます。この場合、同じリクエストを複数回実行しても効果は1つだけです。 （次の点があるため、これを行うことを強くお勧めします）。
-
すべてがステートレスであり、タイムアウトが短くなる可能性があります。何かがうまくいかない場合は、それを再試行してください。
-
すべてのデータベース接続はプールを経由するため、アイドル状態のセッションが発生することはありません。すべてのデータベースバックエンドは、最大のスループットを得るために懸命に取り組んでいます。
-
大量の処理を同時に実行してサーバーをスラッシングするのではなく、作業をキューに入れることができます。 （これは、トランザクションプーリングモードのPgBouncerを使用して行うこともできます）。
...そして編集をやり直して質問の意味を変更します：
パフォーマンス
あなたの「また」の再パフォーマンスは、実際にはまったく異なる質問です（そして、できればそのように投稿する必要があります）。非常に短いバージョン：クライアントアプリリクエストごとのdbリクエストの数、データの種類、クエリの種類、データのサイズ、クエリの頻度、キャッシュの実用性など、ワークロードに関する詳細情報がないと予測できません。 ....際限なく。その質問に明確に答えると主張する人は誰でも、歴史上最初の真の超能力者であるか、完全にそれでいっぱいです。
データサイズ、クエリパターンなどを大まかに把握する必要があります。 redis / memcachedなどの中間層キャッシュにキャッシュする余裕がある量、取得できる古さ、必要なキャッシュ無効化のレベルを把握します。 「ホット」データセット（頻繁にアクセスする）がRAMに収まるかどうかを判断します。頻繁にクエリされるテーブルのインデックスがRAMに収まるかどうかを判断します。大まかな読み取り/書き込みバランスと、書き込みが挿入専用（追加）またはより通常のOLTP（挿入/更新/削除）になる可能性が高い量を把握します。データセットといくつかのクライアントワークロードをダミーアップします。 次に あなたはその質問に答え始めることができます-多分。それを正しく行うには、停止/消失したクライアントなどをシミュレートする必要もあります。
なぜそれが単なる「また」ではないのか見てみましょう。