接続プールを使用する

Lakebase には、サーバー接続のプールを維持し、多数のクライアント接続間でそれらを共有する組み込みの PgBouncer 接続プーラーが含まれています。 プーラーは、最大 10,000 個の同時クライアント接続をサポートしているため、サーバーレス関数、Web API、およびその他のアプリケーションが短時間接続を多数開く場合に適しています。

接続プーリングにはネイティブな Postgres パスワード認証が必要です。 OAuth ロールでは使用できません。

接続プールのしくみ

Postgres はクライアントごとに個別のプロセスを作成するため、各 Postgres 接続ではサーバー リソースが消費されます。 同時接続が増えると、サーバーの接続制限をすぐに使い果たすことができます。

接続プーラーは、アプリケーションと Postgres の間に配置されます。 クライアントはプーラーに接続し、プーラーはクエリを実際のサーバー接続の小さなプールに転送します。 Lakebase は PgBouncer をトランザクション モードで実行するため、サーバー接続は 1 つのトランザクションの期間中のみ保持され、プールに返されます。 これにより、多くのクライアントがサーバー接続の小さなプールを共有できます。

接続プール

PgBouncer は、データベースとユーザーの組み合わせごとに個別のプールを作成します。 同じデータベースに接続している 2 人のユーザーが独立したプールを取得します。 各プールのサイズは、Postgres max_connections 制限の約 90% であり、コンピューティング サイズによって異なります。

プール内のすべての接続が使用中の場合、新しいクライアント要求はキューで待機します。 サーバー接続が 2 分以内に使用できない場合、クライアントはタイムアウト エラーを受け取ります。

この図は、異なるユーザーからの複数のクライアント接続が、実際の Postgres 接続の数が限られている個別の PgBouncer プール (ユーザー/データベースの組み合わせごとに 1 つ) を経由する方法を示しています。

接続の制限

接続プールには、次の 3 つの制限があります。

直接接続の制限は、コンピューティング サイズによって異なります。 たとえば、8 CU コンピューティングでは 1,678 の直接接続がサポートされ、16 CU コンピューティングでは 3,357 がサポートされます。 完全な一覧については、「 コンピューティングの仕様」を参照してください。

10,000 クライアント接続の制限は、10,000 件の同時クエリ結果を意味するものではありません。 これは、PgBouncer が受け入れるクライアント接続の最大数を表します。 同時アクティブ トランザクションの数はプール サイズによって制限されます。プール サイズは、約 90% の max_connectionsです。

接続プールを有効にする

前提条件

• Lakebase 自動スケール プロジェクトがアクティブである必要があります。
• プロジェクトには、ネイティブの Postgres パスワード ロールが必要です。 手順については、「 ネイティブ Postgres パスワード ロールの作成」を参照してください。
• 読み取り専用コンピューティング インスタンスで接続プールを使用するには、読み取り専用コンピューティング インスタンス へのアクセスを許可する 高可用性エンドポイントが有効になっている必要があります。 高可用性を参照してください。

手順

1. Lakebase アプリで、プロジェクトに移動し、[ 接続] をクリックします。
2. 接続先のブランチとコンピューティングを選択します。
3. [ ロール ] ドロップダウンから、ネイティブ Postgres パスワード ロールを選択します。 接続プーリング スイッチは、パスワード ロールが選択されている場合にのみ表示されます。 OAuth ロールでは非表示になっています。
4. 接続プールを有効にします。
5. 接続文字列をコピーし、アプリケーションで使用します。

接続文字列の形式

プーラー接続文字列では、直接データベース接続とは異なるホスト名が使用されます。 ホスト名には、読み取り/書き込みコンピューティングのエンドポイント ID の後に -pooler が含まれるか、読み取り専用コンピューティングの -ro-pooler が含まれます。

どちらもポート 5432 を使用します。

PgBouncer の構成

Lakebase は、次の設定で PgBouncer を管理します。 これらの設定は固定されており、カスタマイズすることはできません。

[pgbouncer]
pool_mode=transaction
max_client_conn=10000
default_pool_size=0.9 * max_connections
max_prepared_statements=1000
query_wait_timeout=120

トランザクション モード

トランザクション モードでは接続効率が向上しますが、永続的なサーバー接続を必要とする特定の Postgres 機能が制限されます。 接続プーラーを使用する場合、次の機能は使用できません。

• SQL レベルの準備済みステートメント: PREPARE ステートメントと DEALLOCATE ステートメントは、トランザクション モードではサポートされていません。 ドライバー レベルの準備済みステートメント (psycopg、node-postgres、JDBC、および同様のライブラリによって内部的に使用) は、PgBouncer のプロトコル レベルのサポートによって正しく機能します。 JDBC の場合、準備済みステートメントに関連するエラーが発生した場合は、名前付きサーバー側の準備済みステートメントキャッシュを無効にするように prepareThreshold=0 を設定します。

• セッション レベルの設定: 各トランザクションで異なるサーバー接続が使用される可能性があるため、 SET コマンドはトランザクション間で保持されません。 例えば次が挙げられます。

  BEGIN;
  SET search_path TO myschema;
  SELECT * FROM mytable; -- works in this transaction
  COMMIT;
  -- connection returns to pool after COMMIT
  SELECT * FROM mytable; -- ERROR: relation "mytable" does not exist
  

  設定を永続的に適用するには、代わりに ALTER ROLE を使用します。

  ALTER ROLE myrole SET search_path TO myschema, public;
  

• セッション保持一時テーブル: トランザクション間で保持される一時テーブルは使用できません。 プールに返される接続は、次のトランザクションで別のクライアントに割り当てることができます。

• WITH HOLD カーソル: WITH HOLD で宣言されたカーソルには永続的な接続が必要であり、サポートされていません。

• アドバイザリ ロック: PgBouncer はアドバイザリ ロックをサポートしていません。 アドバイザリ ロックには永続的なサーバー接続が必要です。これはトランザクション モードでは使用できません。

• LISTEN/NOTIFY: サポートされていません。 pub/sub メッセージングを必要とするアプリケーションには、直接 (プールされていない) 接続を使用します。

• pg_dump とスキーマの移行: セッション レベルの状態に依存する pg_dump、スキーマの移行、およびその他のツールに直接接続を使用します。