使用連線池化

Lakebase 內建 PgBouncer 連線池，維護伺服器連線池並在多個用戶端連線間共享。 連線集區器最多可支援 10,000 個同時用戶端連線，因此非常適合用於無伺服器函式、Web API 及其他會開啟大量短暫連線的應用程式。

連線集區需要使用 Postgres 原生密碼驗證。 OAuth 職位無法使用此服務。

連線池的運作方式

每個 Postgres 連線都會消耗伺服器資源，因為 Postgres 為每個用戶端建立獨立的程序。 隨著同時連線增加，它們可能會很快耗盡伺服器的連線限制。

連線池位於你的應用程式和 Postgres 之間。 用戶端連接到池池器，池池器會將查詢轉發到較小的實際伺服器連線池。 Lakebase 以交易模式運行 PgBouncer，因此伺服器連線只會在單一交易期間保留，然後返回池中。 這允許許多用戶端共享一小池伺服器連線。

連線集區

PgBouncer 為每個資料庫和使用者組合建立獨立的池子。 兩個連接同一個資料庫的使用者會獲得獨立的連線池。 每個池的大小約為 Postgres max_connections 限制的 90%，而限制會依計算大小而異。

當池中所有連線都被使用時，新的用戶請求會在佇列中等待。 如果伺服器連線在 2 分鐘內無法恢復，客戶端會收到逾時錯誤。

顯示多個用戶端連線經由 PgBouncer 路由至按使用者、按資料庫區分的獨立集區的圖示，這些集區共享數量有限的 Postgres 直接連線，且受 max_connections 限制。

圖示顯示來自不同使用者的多個用戶端連線如何經過不同的 PgBouncer 池（每個使用者/資料庫組合一個），這些池共享有限數量的實際 Postgres 連線。

連線限制

連線池有三個限制：

限制 價值 它控制的是什麼
用戶端連結（max_client_conn） 10,000 從你的應用程式到PgBouncer的最大連線
池數（default_pool_size） ~90% max_connections 每對（使用者、資料庫）的主動伺服器連線數
直接連接（max_connections） 依計算大小而異 Postgres 直接最大連線數

直接連線的限制取決於你的運算容量。 例如，8 CU 運算支援 1,678 個直接連線，16 個 CU 運算支援 3,357 個。 完整清單請參見 計算規範。

10,000 個用戶端連線上限並不代表同時有 10,000 個查詢結果。 它代表 PgBouncer 接受的最大客戶端連線數。 同時進行的活躍交易數量受池大小限制，池大小約為 90% max_connections。

啟用連線池

先決條件

  • 您的 Lakebase 自動縮放專案必須處於啟用狀態。
  • 專案中必須有原生 Postgres 密碼角色。 相關說明請參見 「建立原生 Postgres 密碼角色」。
  • 要在唯讀運算實例中使用連線池，必須有一個高可用性端點，並啟用 「允許存取唯讀運算實例 」。 詳見 高可用性。

Steps

  1. 在 Lakebase 應用程式中，進入你的專案並點 選「連結」。
  2. 選擇你想連接的分支和運算。
  3. 從 角色 下拉選單中，選擇一個原生的 Postgres 密碼角色。 連線池交換器只有在選擇密碼角色時才會顯示。 它隱藏在 OAuth 職位上。
  4. 開啟 連線池。
  5. 複製 連接字串 並用在你的應用程式裡。

連線對話框顯示針對 Postgres 原生密碼角色的連線池切換已啟用。

連接字串格式

池子連線字串使用的主機名稱與直接資料庫連線不同。 主機名稱在讀寫運算的端點 ID 後面包含 -pooler，或在唯讀運算的端點 ID 後面包含 -ro-pooler：

計算類型 主機名稱格式 何時使用
讀寫運算 <endpoint-id>-pooler.<region>.<cloud>.databricks.com 所有寫入與讀取流量
唯讀運算 <endpoint-id>-ro-pooler.<region>.<cloud>.databricks.com 僅限讀取網路流量。 需要一個高可用性端點並啟用讀取權限。

兩者都使用 5432 埠。

Note

直接從 Lakebase App 的 Connect 對話框中複製你的池連線字串，以獲取端點、區域和雲端的正確主機名稱。

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
Setting Description
pool_mode=transaction 每次交易結束後，伺服器連線會回到池中。 詳見 交易模式。
max_client_conn=10000 PgBouncer 可接受的最大並行用戶端連線數。
default_pool_size=0.9 * max_connections 每對（使用者、資料庫）的主動伺服器連線。 這會依計算大小而異。
max_prepared_statements=1000 允許在交易模式下使用協定層級的預備陳述式。 將每個用戶端連線可追蹤的陳述式數量限制為 1,000 個。
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：不支援。 對於需要發佈/訂閱模式的應用程式，請使用直接（非集中式）連線。

  • pg_dump 以及架構遷移：使用直接連線來進行 pg_dump、架構遷移，以及其他依賴會話層級狀態的工具。

Note

對於需要工作階段層級 Postgres 功能的應用程式，請使用 Connect 對話方塊中的直接連線字串，且不要啟用 Connection pooling 切換開關。

  • Last updated on