このシリーズの以前の投稿では、PgBouncerとPgpool-IIの使用、接続プールアーキテクチャ、およびそれらを活用することの長所と短所について詳しく説明しました。 PostgreSQLデプロイメント用。最後の投稿では、詳細な機能比較でそれらを直接比較し、PostgreSQLホスティングのPgBouncerとPgpool-IIのパフォーマンスの結果を比較します！
機能はどのように積み重ねられますか？
PgBouncerとPgpool-IIの機能を比較することから始めましょう：
PgBouncer | Pgpool-II | |
|---|---|---|
| リソース消費 | 1つのプロセスのみを使用するため、非常に軽量です。 PgBouncerは、大きなデータセットを処理する場合でも、小さなメモリフットプリントを保証します。 勝者！ | N個の並列接続が必要な場合、これはN個の子プロセスをフォークします。デフォルトでは、フォークされる子プロセスは32個あります。 |
| 接続はいつ再利用されますか？ | PgBouncerは、ユーザーとデータベースの組み合わせごとに1つのプールを定義します。これはすべてのクライアント間で共有されるため、プールされた接続をすべてのクライアントで利用できます。 勝者！ | Pgpool-IIは、子プロセスごとに1つのプロセスを定義します。クライアントが接続する子プロセスを制御することはできません。クライアントは、このデータベースとユーザーの組み合わせの接続を以前に提供した子に接続する場合にのみ、プールされた接続の恩恵を受けます。 |
| プーリングモード | PgBouncerは、セッション（クライアントが切断すると接続がプールに戻る）、トランザクション（クライアントがコミットまたはロールバックするとプールに戻る）、またはステートメント（各ステートメントの実行後に接続がプールに返されました）。 勝者！ | Pgpool-IIはセッションプーリングモードのみをサポートします–プーリングの効果は、クライアントの適切な動作に依存します。 |
| 高可用性 | サポートされていません。 | PostgreSQLの高可用性は、Pgpool-IIの組み込みウォッチャープロセスによってサポートされます。 勝者！ |
| 負荷分散 | サポートされていません– PgBouncerは、高可用性と負荷分散のためにHAProxyの使用を推奨しています。 | 自動負荷分散をサポート–読み取り要求をスタンバイにリダイレクトし、マスターに書き込むのに十分なインテリジェント機能を備えています。 勝者！ |
| マルチクラスターのサポート | 1つのPgBouncerインスタンスは、複数のPostgreSQLクラスター（1ノードまたはレプリカセット）の前に置くことができます。これにより、複数のPostgreSQLクラスターを使用する場合のミドルウェアのコストを削減できます。 勝者！ （注–この利点は特定のシナリオにのみ適用されます） | Pgpool-IIはマルチクラスターをサポートしていません。 |
| 接続制御 | PgBouncerを使用すると、プールごと、データベースごと、ユーザーごと、またはクライアントごとに接続を制限できます。 勝者！ | Pgpool-IIでは、接続の総数を制限することしかできません。 |
| 接続キュー | PgBouncerは、アプリケーションレベルでのキューイングをサポートします（つまり、PgBouncerはキューを維持します）。 勝者！ | Pgpool-IIはカーネルレベルでのキューイングをサポートしています。これにより、CentOS6のpg_benchがフリーズする可能性があります。 |
| 認証 | パススルー認証は、PgBouncerを介してサポートされています。 勝者！ | Pgpool-IIはパススルー認証をサポートしていません–ユーザーとそのmd5暗号化パスワードをファイルにリストし、ユーザーが更新するたびに手動で更新する必要がありますPgpool-IIは、PAMまたはSSL証明書によるパスワードなしの認証をサポートしています。ただし、これらはPostgreSQLシステムの外部で設定する必要がありますが、PgBouncerはこれをPostgreSQLサーバーにオフロードできます。 |
| 管理 | PgBouncerは、さまざまな有用な統計を報告する仮想データベースを提供します。 | Pgpool-IIは、GUIを含む詳細な管理インターフェースを提供します。 勝者！ |
| ホストベースの認証 | サポートされています。 結ばれました！ | サポートされています。 結ばれました！ |
| SSLサポート | 完全サポート。 結ばれました！ | 完全サポート。 結ばれました！ |
| 論理レプリケーション | PgBouncerではサポートされていません。 結ばれました！ | Pgpool-IIでサポートされていますが、これはすべてのノードに書き込みクエリを送信することで行われるため、通常はお勧めしません。 結ばれました！ |
| ライセンス | ISC –非常に寛容で、基本的にすべての使用を許可します。 結ばれました！ | カスタムライセンス–同様に許容されます。 結ばれました！ |
結論– Pgpool-IIは、負荷分散と高可用性が必要な場合に最適なツールです。接続プールは、ほとんど一緒に得られるボーナスです。 PgBouncerは1つのことだけを行いますが、それは本当にうまくいきます。接続数を制限し、リソース消費を削減することが目的の場合、PgBouncerが勝ちます。
チェーンでPgBouncerとPgpool-IIの両方を使用することもまったく問題ありません。PgBouncerを使用して接続プールを提供できます。高可用性と負荷分散を提供するPgpool-IIインスタンス。これにより、両方の長所が得られます！
パフォーマンステスト
理論的にはPgBouncerの方が優れているように見えるかもしれませんが、理論は誤解を招くことがよくあります。そこで、標準のpgbenchツールを使用して、2つの接続プーラーを直接比較し、ベンチマークテストを通じて、どちらが1秒あたりのスループットの向上を実現するかを確認しました。適切な方法として、接続プールを使用せずに同じテストを実行しました。
テスト条件
すべてのPostgreSQLベンチマークテストは、次の条件下で実行されました。
- 100のスケールファクターを使用してpgbenchを初期化しました。
- 干渉を防ぐためにPostgreSQLインスタンスの自動バキュームを無効にしました。
- 当時、他のワークロードは機能していませんでした。
- デフォルトのpgbenchスクリプトを使用してテストを実行しました。
- PgBouncerとPgpool-IIの両方にデフォルト設定を使用しました。max_childrenを除く *。 PostgreSQLのすべての制限もデフォルトに設定されました。
- すべてのテストは、シングルCPU、2コアのマシンで、5分間、シングルスレッドとして実行されました。
- -Cオプションを使用してトランザクションごとに新しい接続を作成するようにpgbenchに強制しました。これは、最新のWebアプリケーションのワークロードをエミュレートし、プーリーを使用する理由です。
各反復を5分間実行して、ノイズが平均化されるようにしました。ミドルウェアのインストール方法は次のとおりです。
- PgBouncerの場合、PostgreSQLサーバーと同じボックスにインストールしました。これは、マネージドPostgreSQLクラスターで使用する構成です。 PgBouncerは非常に軽量なプロセスであるため、ボックスに取り付けても全体的なパフォーマンスに影響はありません。
- Pgpool-IIの場合、Pgpool-IIインスタンスがPostgreSQLと同じマシン（ボックス列）にインストールされた場合と、別のマシンにインストールされた場合の両方をテストしました。 （オフボックス列）。予想どおり、Pgpool-IIをオフボックスにすると、リソースを求めてPostgreSQLサーバーと競合する必要がなくなるため、パフォーマンスが大幅に向上します。
スループットベンチマーク
これは、さまざまな数のクライアントにわたる各シナリオの1秒あたりのトランザクション数（TPS）の結果です。
| クライアント数 | プーリングなし | PgBouncer | Pgpool-II （ボックス上） | Pgpool-II （オフボックス） |
|---|---|---|---|---|
| 10 | 16.96 | 26.86 | 15.52 | 18.22 |
| 20 | 16.97 | 27.19 | 15.67 | 18.28 |
| 40 | 16.73 | 26.77 | 15.33 | 18.3 |
| 80 | 16.75 | 26.64 | 15.53 | 18.13 |
| 100 | 16.51 | 26.73 | 15.66 | 18.45 |
| 200 | 接続が中止されました。 | 26.93 | max-children> 200の場合、接続は中止されます。<=100の場合、pgbenchはmax-children値でハングします。 | max-children> 200の場合、接続は中止されます。<=100の場合、pgbenchはmax-children値でハングします。 |
pg_benchがmax_childrenよりも多くのクライアントで実行されると、Pgpool-IIがハングします。そのため、各テスト実行のクライアント数に一致するようにmax_childrenを増やしました。
接続プールを使用した場合のTPSの増加率を計算すると、次のようになります。
| クライアント数 | PgBouncer | Pgpool-II（ボックス上） | Pgpool-II（オフボックス） |
|---|---|---|---|
| 10 | 58.37％ | -8.49％ | 7.43％ |
| 20 | 60.22％ | -7.66％ | 7.72％ |
| 40 | 60.01％ | -8.37％ | 9.38％ |
| 80 | 59.04％ | -7.28％ | 8.24％ |
| 100 | 61.90％ | -5.15％ | 11.75％ |
*改善アルゴリズム=（プールあり–なし）/なし
最後の言葉
パフォーマンステストの結果からわかるように、適切に構成された接続と適切な接続プールを使用すると、クライアントの数がかなり少ない場合でも、トランザクションスループットを大幅に向上させることができます。接続プーリーは、キューイングのサポートに特に役立ちます。クライアントの数がPostgreSQLサーバーでサポートされているmax-clientsを超えた場合でも、PgBouncerはトランザクションレートを維持できますが、PostgreSQLへの直接接続は中止されます。
ただし、不適切に構成された接続プールは、実際には削減できます。 ここでPgpool-IIのセットアップで見たパフォーマンス。問題の一部は、Pgpool-II doublesを使用することです。 同じサーバーで実行されているプロセスの数-必須 別のサーバーでPgpool-IIを実行すると、良好なパフォーマンスが得られます。しかし、それでも、PgBouncerは、これらの比較的少数のクライアントにより良いパフォーマンスを提供することに成功しています。
また、ここでのテストは実際にはPgpool-II用に完全に作成されていることに注意してください。N> 32の場合、クライアントの数と子プロセスの数は同じであり、したがって、各再接続は、キャッシュされたプロセスを見つけることが保証されていました。それでも、PgBouncerがより高速な代替手段でした。
したがって、テストでは、PgBouncerが接続プールにはるかに適していることが示されています。ただし、最も現実的なワークロードでは接続プールが絶対に必須ですが、クライアント側のプールを使用するか、PgBouncerなどのミドルウェアを使用することで利益を得るかは、アプリケーションによって異なることを覚えておくことが重要です。データアクセスのパターンは、アーキテクチャに基づいて関連するレイテンシと同様に、役割を果たします。両方に対してワークロードをテストしてから、最善の行動方針を決定することをお勧めします。実験に代わるより良い方法はありません。
