接続プールを使用する

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

接続プールには、標準のPostgresパスワード認証が必要です。 OAuth または Azure Databricks ID ロールでは使用できません。

接続プールのしくみ

Postgres はクライアントごとに個別のプロセスを作成するため、各 Postgres 接続ではサーバー リソースが消費されます。 Web API やサーバーレス関数など、有効期間の短い接続を多数開くアプリケーションでは、サーバーの接続制限がすぐに使い果たされる可能性があります。

接続プーラーは、アプリケーションと Postgres の間に配置されます。 クライアントはプーラーに接続し、プーラーはクエリを実際のサーバー接続の小さなプールに転送します。 トランザクションが完了すると、プーラーはプールへのサーバー接続を返し、次のクライアントが使用できるようにします。

Lakebase は、トランザクション モードで PgBouncer を実行します。 トランザクション モードでは、サーバー接続は 1 つのトランザクションの間保持され、プールに返されます。 これにより、多くのクライアントがサーバー接続の小さなプールを共有できます。

トランザクション モードでは接続効率が向上しますが、永続的なサーバー接続を必要とする特定の Postgres 機能が制限されます。 トランザクション モードの制限事項を参照してください。

接続プール

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

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

接続の制限

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

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

接続プールを使用すると、直接接続の制限だけでは許容されるよりもはるかに多くの同時実行ユーザーをアプリケーションでサポートできます。

前提条件

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

接続プールを有効にする

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

接続文字列の形式

プーラー接続文字列では、直接データベース接続とは異なるホスト名が使用されます。

どちらのプーラーの種類もポート 5432 を使用します。

トランザクション モードの制限事項

接続プーラーを使用する場合、次の Postgres 機能は使用できません。

• SQL レベルの準備済みステートメント: PREPARE ステートメントと DEALLOCATE ステートメントは、トランザクション モードではサポートされていません。 ドライバー レベルで準備されたステートメント (psycopg2、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、スキーマの移行、およびその他のツールに直接接続を使用します。

次のステップ

• 接続文字列: 直接接続の接続文字列形式のリファレンス。 接続文字列を参照してください。
• Postgres ロールの作成: 接続プールに必要なネイティブ Postgres パスワード ロールを作成する方法。 Postgres ロールの作成を参照してください。
• 認証について: OAuth とパスワード認証方法の比較。 「 認証について」を参照してください。