接続プールの構成

接続プーラーは、データベース接続を管理するソフトウェア コンポーネントです。これは、さまざまな方法でリソースの使用率を向上させ、負荷分散やフェイルオーバーに役立ち、トランザクション時間を大幅に短縮することができます。このブログ投稿では、接続プーラーとは何か、その構成方法について説明します。

接続プーラーはソフトウェア コンポーネントです。データベース接続を管理します。これは、さまざまな方法でリソースの使用率を向上させ、負荷分散やフェイルオーバーに役立ち、トランザクション時間を大幅に短縮することができます。このブログ投稿では、接続プーラーとは何か、その構成方法について説明します。

接続プーラーとは何か、なぜ役立つのか

データベースへの接続を開くには、次の手順が必要です。多くのステップ。サーバーに接続して初期ハンドシェイクを実行し、暗号化と接続設定に同意して、すべての層 (ネットワーク ドライバー、OS 層、データベース層など) にわたって新しい接続リソースを維持する必要があります。各接続はメモリを消費します。そのサイズはデータベース エンジンによって異なります。 PostgreSQL の場合、これは 1 つの接続で 1.3MB のメモリになる場合もあります。新しい接続の設定をネゴシエートする必要があるため、接続を開くにも時間がかかります。

SQL クエリごとに新しい接続を開き続けると、データベース サーバーに複数の問題が発生する可能性があります。

• 接続を開くには時間とリソースがかかるため、トランザクションが遅くなります

• アクティブな接続の制限を超える可能性があります (デフォルトで何かに設定できます) 100 の接続など)

• データベースはより多くのメモリを消費する可能性があり、キャッシュ ヒット率やクエリに使用できる空きメモリに悪影響を与える可能性があります

を開く代わりにSQL クエリごとに新しい接続を作成すると、接続をプールできます。接続量を保持し、すべてのクライアントに対してそれらを再利用する接続プーラーを構成できます。このようにして、アプリケーションはデータベースに直接接続するのではなくプーラーに接続し、その後プーラーがデータベースに接続します。これにより、複数の利点がもたらされます。

• 接続プーラーは、接続を開いた状態をより長時間維持するため、データベース側で接続を開いたり閉じたりするオーバーヘッドが軽減され、待ち時間が短縮されます。

• 接続間、さらにはデータベース間で負荷分散を行うことができ、パフォーマンスが向上します。

• プーラーは安定した接続数を維持できるため、この問題を回避できます。アクティブな接続が多すぎるため、リソースの使用量が減少します。

• プーラーは、プライマリ サーバーとスタンバイ サーバー間の接続をリダイレクトして、安定性と拡張性を向上させるフェイルオーバーを提供できます。

• プーラーはパスワードを中央の場所にデータベースに保存できるため、セキュリティが向上します。

• プーラーは結果をキャッシュしてクエリのパフォーマンスを向上させることができます。

接続プーラーにはいくつかの欠点もあります。

• これは、障害点になる可能性のあるシステム内のさらに別のコンポーネントです。

• アプリケーションとデータベース間の別のネットワーク ホップにより、ネットワーク遅延がわずかに増加する可能性があります。

• 非効率な接続プーラーがボトルネックになる可能性があります。

• 接続プーラーを調整して保守する必要があるため、保守の負担が増加します。

接続プーリングにはさまざまなタイプがあります

接続プーリングを実装する方法。このセクションでは、さまざまな実装の詳細を見ていきます。

外部または内部接続プーラー

一般的なケースでは、アプリケーションからデータベースに接続します。接続プーラーを 2 つの場所 (アプリケーション自体、またはアプリケーションとデータベースの間のどこか) のいずれかに配置できるようになりました。

アプリケーション (アプリケーション側の接続プーラー) に接続プールを配置するのは非常に簡単です。多くの ORM またはデータベース ドライバーがすぐにこれをサポートします。たとえば、JDBC は c3p0 でこれをサポートし、ODBC はそのままの状態でこれをサポートします。これにより多くのメリットがもたらされます。プーラーはアプリケーション内に存在するため、追加のコンポーネントをインストールして保守する必要はありません。新しいバージョンのアプリケーションをデプロイするだけで、プーリングの準備が整います。これにより、追加のネットワーク ホップがなくなる (すべてがアプリケーション内に存在する) ため、ネットワーク遅延も短縮されます。

残念ながら、アプリケーション側の接続プーラーにはいくつかの欠点があります。最大の特徴は、1 つのアプリケーションに対してのみ構成されていることです。多くのアプリケーションがある場合 (特に分散環境)、多くの場所でプーラーを構成する必要があります。言うまでもなく、プーラーはお互いのことを知らないため、サーバー側の接続数制限に依然として達する可能性があります。多数の接続プーラーがあると、リソース使用量が増加し、通常はパフォーマンスが低下します。

アプリケーションとデータベースの間のどこかにある外部接続プーラーを使用することもできます。これは任意の数のアプリケーションで機能し、接続制限を正確に制御できます。集中接続プーラーは、リソースをより適切に制御し、フェイルオーバーや負荷分散を実現することもできます。

外部接続プーラーにもいくつかの欠点があります。何よりもまず、これは、時間をかけてインストール、構成、調整、保守する必要があるもう 1 つのコンポーネントです。また、接続プーラーを使用するようにすべてのアプリケーションを再構成する必要があります (これは、一部の接続文字列を変更してアプリケーションを再デプロイするのと同じくらい簡単です)。外部接続プーラーは、アプリケーションとデータベース間の別のネットワーク コンポーネントであるため、ネットワーク遅延も追加します。

外部接続プーラーも障害点になる可能性があります。何らかの理由でプーラーがダウンすると、アプリケーションはデータベースに接続できなくなります。プーラーが遅いか非効率である場合、それを使用しているすべてのアプリケーションに影響します。したがって、プーラーは全体のパフォーマンスを低下させないように高品質である必要があります。

プーリングの種類

各プーラーは、クライアントに接続を割り当てる方法を決定する必要があります。通常、3 つのアプローチがあります。

最初のアプローチはセッション プーリングです。このアプローチでは、接続はセッションの間 (つまり、クライアントが切断されるかタイムアウトに達するまで) クライアントに割り当てられます。これは最も簡単なアプローチですが、通常、各クライアントは 1 つの接続を消費するため、クライアントの数が効果的に制限されます。

次の解決策は、トランザクション プーリングです。このアプローチでは、プーラーはトランザクションごとに、トランザクション期間中のみ接続を割り当てます。クライアントが別のトランザクションを実行したい場合は、別の接続を取得する必要があります (また、他の接続が利用可能になるまで待つ必要がある場合もあります)。これにより、プーラーはより多くのクライアントを処理できるようになり、推奨されるアプローチです。

最後のアプローチは、各 SQL ステートメントに個別に接続を割り当てることです。理論的には、これにより最高の柔軟性と接続使用率がもたらされます。ただし、これにより、1 つのトランザクションが多くの接続にまたがることになります。多くのトランザクション設定は接続に関連付けられているため、これは技術的な制限となる可能性があります。

接続プーリング ソリューション

使用するデータベースの種類によっては、いくつかの組み込みソリューションがある場合があります。手動で構成する必要がある場合があります。いくつかの例を見てみましょう。

組み込みソリューション

インフラストラクチャ プロバイダーによっては、組み込みまたはほぼ組み込みのソリューションを使用できる場合があります。

• Neon PostgreSQL データベースには PgBouncer が組み込まれています

• Supabase には Supervisor が組み込まれています

• PostgreSQL 用の Azure データベース組み込みの PgBouncer をサポート

• DigitalOcean の PostgreSQL には PgBouncer

• が含まれます。Azure データベースは ProxySql で使用できます

• Azure データベースは Heimdall Database Proxy で使用できます

• ADO.NET は組み込みの接続プールをサポートします

• Oracle はユニバーサル接続プールをサポートしますJDBC 用

• Oracle Autonomous Database はデータベース常駐接続プールをサポート

外部ソリューション

使用できる外部ソリューションは多数あります使用:

• Amazon RDS プロキシ

• Pgpool

• PgBouncer

• オデッセイ

• Heimdall データベース プロキシ

• ProxySQL

• pgcat

ケーススタディ: PgBouncer の構成

この例では、PgBouncer を調べます。

まず、ドキュメントにあるようにインストールします。

次に、それを構成する必要があります。最も重要な設定は次のとおりです。

• pool_mode: 接続の処理方法。トランザクションを使用できます

• max_client_conn: 接続プーラーに接続できるクライアントの数を構成します

• default_pool_size: 許可されるサーバー接続の数を構成しますユーザー データベースごとに

• min_pool_size: 保持するスタンバイ接続の数

プーラーを構成した後、pgbench でパフォーマンスを確認できます。

pgbench -c 10 -p -j 2 -t 1000 database_name

PgBouncer は、ベンチマークで示されているように、1 秒あたりのトランザクション数を簡単に 60% 増やすことができます:

• PostgreSQL 接続プーラーのベンチマーク: PgBouncer、PgCatおよび Supervisor

• 接続プーリングによるデータベースのパフォーマンスの向上

• PgBouncer による PostgreSQL のスーパーチャージ

概要

接続プーラーにより、パフォーマンスが向上し、リソース消費が削減されます。データベースをホストする場所や使用するデータベース エンジンに関係なく、データベースで簡単に使用できる組み込みソリューションが多数あります。接続プーラーも障害のもう 1 つのポイントであり、慎重に扱う必要があることに留意する必要があります。接続プーラーを適切に構成すると、1 秒あたりのトランザクション数がほぼ 2 倍になり、パフォーマンスが大幅に向上します。

以上が接続プールの構成の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。