PostgreSQL接続プール：パート1-長所と短所

昔、はるか遠くの銀河系では、「スレッド」はめったに使用されず、ほとんど信頼されないプログラミングの目新しさでした。その環境では、最初のPostgreSQL開発者は、データベースへの接続ごとにプロセスをフォークすることが最も安全な選択であると判断しました。結局のところ、データベースがクラッシュした場合は残念です。

それ以来、その橋の下にはたくさんの水が流れてきましたが、PostgreSQLコミュニティは当初の決定に固執しています。彼らの主張に誤りを犯すことは困難です–それは絶対に真実です：

• 独自のプロセスを持つ各クライアントは、動作の悪いクライアントがデータベース全体をクラッシュするのを防ぎます。
• 最近のLinuxシステムでは、プロセスのフォークとスレッドの作成のオーバーヘッドの違いは、以前よりもはるかに少なくなっています。
• マルチスレッドアーキテクチャに移行するには、大幅な書き換えが必要になります。

ただし、最近のWebアプリケーションでは、クライアントは多くの接続を開く傾向があります。開発者は、他の操作が行われている間、データベース接続を保持することを強くお勧めしません。 「できるだけ遅く接続を開き、できるだけ早く接続を閉じてください」。しかし、それはPostgreSQLのアーキテクチャに問題を引き起こします。トランザクションが非常に短い場合、一般的な知識でプロセスをフォークする必要があるため、プロセスのフォークはコストがかかります。

接続プールアーキテクチャ

最新の言語ライブラリを使用すると、問題がいくらか軽減されます。接続プールは、最も一般的なデータベースアクセスライブラリの重要な機能です。これにより、「閉じた」接続は実際には閉じられずにプールに戻され、新しい接続を「開く」と同じ「物理的な接続」が返され、PostgreSQL側での実際の分岐が減ります。

ただし、最新のWebアプリケーションモノリシックになることはめったになく、多くの場合、複数の言語とテクノロジーを使用します。各モジュールで接続プールを使用することはほとんど効率的ではありません：

• モジュールの数が比較的少なく、各モジュールのプールサイズが小さい場合でも、サーバープロセスが多くなります。それらの間のコンテキスト切り替えにはコストがかかります。
• プールのサポートはライブラリと言語によって大きく異なります。1つの不適切な動作のプールはすべてのリソースを消費し、他のモジュールからデータベースにアクセスできなくなる可能性があります。
• 集中管理はありません。クライアント固有のアクセス制限などの手段を使用することはできません。

その結果、人気のあるミドルウェアがPostgreSQL用に開発されました。これらはデータベースとクライアントの間にあり、場合によっては別のサーバー（物理または仮想）にあり、場合によっては同じボックスにあり、クライアントが接続できるプールを作成します。これらのミドルウェアは次のとおりです。

• PostgreSQLと最新のDBMSの中でかなりユニークなアーキテクチャに最適化されています。
• さまざまなクライアントに一元化されたアクセス制御を提供します。
• クライアント側のプールと同じ報酬を獲得してから、さらにいくつかの報酬を獲得できるようにします（これらについては、次の投稿で詳しく説明します）。