連線集區
本主題說明 Bigtable 中的連線集區運作方式、連線集區大小對使用 Bigtable 的應用程式造成的影響，以及您可能需要變更預設連線集區設定的情況。
閱讀本頁內容後，如果您認為應該變更連線集區大小，請參閱「設定連線集區」，瞭解如何判斷最佳大小及變更大小。只有在使用 Go、C++ 或 Java 版 Cloud Bigtable 用戶端程式庫時，才能在程式碼中設定每個集區的連線數。
連線集區的運作方式
連線集區 (又稱管道集區) 是資料庫連線的快取，可共用及重複使用，以縮短連線延遲時間並提升效能。連線會用於循環配置系統。
使用 Bigtable 時，每個應用程式程序都會建立單一資料用戶端。每個用戶端都有一個連線集區。每個連線集區都包含一定數量的 gRPC 連線，每個連線最多可處理 100 個並行串流。透過這些連線傳送的要求會經過 Google 中介軟體，然後轉送到您的資料表。中介軟體層由許多負載平衡執行個體組成，每個要求都會透過可用性最高的執行個體傳送。
您可以將連線 (或管道) 視為最多有 100 個車道的公路，每個車道 (串流) 在任何時間只能容納一輛車 (要求)。Google 中介軟體層會強制執行每個 gRPC 連線 100 個並行串流的限制，您無法重新設定這個數字。
連線每小時會自動重新整理一次。此外，如果連線在五分鐘內未收到要求，中介軟體會自動刪除連線，並在需要其他連線時才重新建立。
在後端，每個頻道都有一個子頻道。每個子通道都有 HTTP2 連線，會使用 TCP 將要求轉換為位元組，然後透過中介軟體傳送至資料表。Bigtable 服務會順暢地處理這項程序，您不需要進行任何設定。
連線集區對效能的影響
理想情況下，您應有足夠的 gRPC 連線來處理要求，而不需緩衝。不過，您不應建立過多連線，以免連線因閒置而經常中斷。
連線數不足
如果連線集區沒有足夠的連線來處理流量，中介軟體就會開始緩衝及佇列要求。這項緩衝會減緩流量，導致每秒要求數減少，且要求備份時延遲時間會增加。
連線數量過多
如果集區的連線過多 (表示部分連線處於閒置狀態)，中介軟體會中斷閒置連線。然後，當有需要這些連線的新要求傳送過來時，系統就會重新建立連線。這表示流量增加時，要求可能會遇到伺服器端快取未命中，導致額外工作和延遲。如果流量層級變化頻繁，導致這種情況經常發生，這項活動可能會在用戶端顯示為尾端延遲時間的明顯尖峰。
何時變更預設設定
預設連線集區大小適用於大多數應用程式，因此在大多數情況下不需要變更。視應用程式中使用的用戶端程式庫而定，您可能無法變更連線集區大小。只有在使用適用於 Cloud Bigtable 的 Go、C++ 或 Java 用戶端程式庫時，才能在程式碼中設定每個集區的連線數。
一般而言，理想的連線集區至少應有達到飽和狀態所需連線數的兩倍。這樣一來，流量波動時，系統仍有調整空間。舉例來說，假設您有 4 個連線，且每個連線都處理了可能的最大要求數 (100 個)，您希望將每個連線的要求數降至 10 到 50 之間，因此理想的連線集區大小至少是這個數字的兩倍，也就是至少 8 個連線。
您應考慮變更集區中連線數量的信號包括：
總處理量低，且用戶端尾部延遲時間大幅增加
如果您的典型輸送量相當低 (例如每個連線每秒少於一個要求)，且應用程式的尾部延遲時間會定期變長，則可能是因為您傳送的流量不足，無法維持連線。在這種情況下，您可能需要減少集區中的連線數。請參閱「設定連線集區」，瞭解如何判斷適當的數量。
緩衝要求
如果發現用戶端堆積了許多要求，可能表示您傳送的並行要求數量超出連線集區的處理能力。計算最佳數量，然後視需要變更程式碼。
如要判斷要求是否堆積，可以使用 OpenCensus 查看 grpc.io/client/started_rpcs 和 grpc.io/client/completed_rpcs 指標之間的差異。
虛擬環境
在極少數情況下，Bigtable 用戶端無法判斷應用程式執行的 CPU 數量，並會以只使用一個 CPU 的方式分配連線。舉例來說，在 Kubernetes 或 Docker 中使用虛擬 CPU 執行個體時，就可能會發生這種情況。如果明顯有這種情況，請根據應用程式的 QPS 和延遲時間，按照指南設定集區數量。