瞭解效能

本頁面說明 Bigtable 在最佳情況下可提供的約略效能、可能影響效能的因素，以及測試和排解 Bigtable 效能問題的訣竅。

一般工作負載效能

Bigtable 的效能相當穩定，容易預測，會隨著資源增加等比例提高。避免本頁所述的效能變慢原因後，視叢集使用的儲存空間類型而定，每個 Bigtable 節點都能提供下列約略處理量：

儲存層級 讀取   寫入   掃描檔
記憶體內層 (預先發布版) 每秒最多 120,000 個資料列1 或 每秒最多 10,000 個資料列2 不適用
「SSD」 每秒最多 17,000 個資料列 或 每秒最多 14,000 個資料列 或 最高 220 MBps
HDD 每秒最多 500 個資料列 或 每秒最多 10,000 個資料列 或 最高 180 MBps
不常存取的儲存空間 每秒最多 100 個資料列 或 每秒最多 10,000 個資料列 或 最高 36 MBps

這些預估值假設每個資料列包含 1 KB。

1 Enterprise Plus 節點每秒可處理 40,000 列資料，且每秒可處理的資料列數可垂直擴充，每個節點每秒最多可處理 120,000 列資料，每次擴充 40,000 列。詳情請參閱「記憶體內層」。

2 每秒寫入記憶體內層資料的資料列數過高，可能會影響寫入處理量。

一般來說，叢集的效能會隨著叢集中的節點增加而線性提升。舉例來說，如果您建立的 SSD 叢集包含 10 個節點，這個叢集每秒可支援多達 140,000 個資料列執行一般唯讀或唯寫工作負載，且未啟用記憶體內層。啟用記憶體內層後，叢集每秒最多可支援 120 萬列的讀取處理量。

規劃 Bigtable 容量

規劃 Bigtable 叢集時，請決定要著重於延遲時間還是處理量。舉例來說，如果是批次資料處理工作，您可能會比較重視總處理量，而非延遲。相較之下，對於處理使用者要求的線上服務，您可能會優先考量低延遲，而非處理量。如果以總處理量為目標進行最佳化，即可達到「一般工作負載的效能」一節中的數字。

記憶體內層

啟用記憶體內層級後，每個節點每秒可處理 40,000 個資料列。水平新增節點可增加叢集總容量。此外，每個節點最多可垂直擴充至每秒 120,000 列，以支援記憶體內讀取處理量。達到垂直擴充上限時，Bigtable 自動調度功能會新增節點，以進行水平擴充。手動資源調度的叢集支援記憶體內垂直資源調度，直到達到輸送量容量為止。如果垂直擴充超過每秒 40,000 列的基本量，系統會將節點的小時費用乘以倍數，做為計費依據。詳情請參閱這篇文章，瞭解定價相關資訊。

每個記憶體內節點都包含 8 GB 的儲存空間容量。雖然總處理量可以垂直擴充，但每個節點的儲存空間容量仍維持固定。不過，水平擴充會為每個新節點額外增加 8 GB 的記憶體。由於垂直調度期間儲存空間不會增加，節點垂直調度記憶體內總處理量時，工作負載的未命中率可能會上升。

CPU 使用率

在幾乎所有情況下，我們都建議您使用自動調度資源功能，讓 Bigtable 根據用量新增或移除節點。詳情請參閱「自動調度資源」。

設定自動調度資源目標時，或選擇手動分配節點時，請遵循下列指南。無論執行個體有多少叢集，都適用這些規範。如果是手動分配節點的叢集，您必須監控叢集的 CPU 使用率，目標是將 CPU 使用率維持在這些值以下，以獲得最佳效能。

最佳化目標 最高 CPU 使用率
處理量 90%
延遲時間 60%

如要進一步瞭解監控功能，請參閱「監控」。

儲存空間使用率

儲存空間也是容量規劃時需要考量的因素。叢集的儲存空間容量取決於儲存空間類型和叢集中的節點數量。隨著叢集中的資料量增加，Bigtable 會將資料分配到叢集中的所有節點，藉此最佳化儲存空間。

如要判斷每個節點的儲存空間用量，請將叢集的儲存空間使用率 (以位元組為單位) 除以叢集中的節點數量。舉例來說，假設叢集有三個 HDD 節點和 9 TB 的資料。每個節點儲存約 3 TB，相當於每個節點 16 TB HDD 儲存空間上限的 18.75%。

儲存空間使用率增加時，即使叢集有足夠的節點來滿足整體 CPU 需求，工作負載的查詢處理延遲仍可能增加。這是因為節點儲存空間越大，就越需要執行索引等背景工作。處理更多儲存空間會增加背景工作，導致延遲時間變長，處理量變少。

設定自動調度資源設定時，請先從下列項目著手。如果選擇手動分配節點，請監控叢集的儲存空間使用率，並新增或移除節點，以維持下列狀態。

最佳化目標 儲存空間使用率上限
處理量 70%
延遲時間 60%

詳情請參閱「每個節點的儲存空間」一文。

針對 Bigtable 執行工作負載

進行容量規劃時，請務必針對 Bigtable 集群執行工作負載，判斷應用程式的最佳資源分配方式。

Google 的 PerfKit Benchmarker 使用 YCSB 進行雲端服務基準測試。您可以按照 Bigtable 適用的 PerfKitBenchmarker 教學課程指示，為工作負載建立測試。進行這項操作時，請調整基準測試設定 YAML 檔案中的參數，確保產生的基準測試反映下列生產特性：

如需更多最佳做法，請參閱「使用 Bigtable 測試效能」。

效能緩慢的原因

下列因素可能會導致 Bigtable 執行速度比預估值慢：

  • 您在單一讀取要求中讀取大量不連續的資料列鍵或資料列範圍。Bigtable 會掃描資料表，並依序讀取所要求的資料列。這種缺乏平行處理能力的情況會影響整體延遲時間，而讀取作業命中熱節點可能會增加尾端延遲時間。詳情請參閱「讀取次數和成效」一文。
  • 資料表的結構定義設計不正確。如要讓 Bigtable 獲得良好效能，請務必設計結構定義，以便在每個資料表之間平均分配讀取與寫入作業。此外，一個資料表中的熱點可能會影響同一執行個體中其他資料表的效能。詳情請參閱「結構定義設計最佳做法」。
  • Bigtable 資料表中的資料列包含大量資料。效能預估值假設每個資料列包含 1 KB 的資料。每個資料列可以讀取及寫入更大的資料量，但增加每個資料列的資料量也會降低每秒的資料列數。
  • Bigtable 資料表中的資料列包含非常大量的儲存格。 Bigtable 需要時間來處理資料列中的每一個儲存格。每一個儲存格也會對資料表儲存及透過網路傳送的資料量增加一些負擔。舉例來說，如果您要儲存 1 KB (1,024 個位元組) 的資料，將資料儲存在單一儲存格中，會比將資料分散到 1,024 個各含 1 個位元組的儲存格中，更節省空間。如果分割資料的儲存格數量超過必要數量，可能無法獲得最佳效能。如果資料欄包含多個帶有時間戳記的資料版本，導致資料列包含大量儲存格，請考慮只保留最新值。如果資料表已存在，您也可以在每次重寫時，傳送所有先前版本的刪除要求。

  • 叢集的節點數量不足。叢集的節點會提供運算資源，供叢集處理傳入的讀取和寫入作業、追蹤儲存空間，以及執行壓縮等維護工作。請務必確保叢集有足夠的節點，可滿足運算和儲存空間的建議限制。使用監控工具檢查叢集是否過度負載。

    • 運算 - 如果 Bigtable 叢集的 CPU 負載過重，新增更多節點可將工作負載分散到更多節點，進而提升效能。
    • 儲存空間 - 如果每個節點的儲存空間用量高於建議值，請新增更多節點，以維持最佳延遲時間和輸送量，即使叢集有足夠的 CPU 可處理要求也一樣。這是因為增加每個節點的儲存空間，會增加每個節點的背景維護工作量。詳情請參閱「儲存空間用量與效能之間的取捨」。

  • Bigtable 叢集最近擴充或縮減規模。 自動調度資源功能增加叢集中的節點數量後，可能需要 20 分鐘的負載時間，效能才會顯著提升。Bigtable 會根據叢集節點的負載調整節點數量。

    縮減叢集中的節點數量時，請盡量不要在 10 分鐘內將叢集大小縮減超過 10%，以免延遲時間大幅增加。

  • Bigtable 叢集使用 HDD 磁碟。在大部分的情況下，叢集應使用 SSD 磁碟，這類磁碟的效能明顯優於 HDD 磁碟。詳情請參閱「選擇 SSD 或 HDD 儲存空間」。

  • 網路連線有問題。網路問題會造成總處理量降低，讀取和寫入作業的時間會比平常更久。特別是如果用戶端與 Bigtable 叢集不在同一個區域，或是用戶端在 Google Cloud外部執行，就可能會發生問題。

  • 您正在使用複寫功能，但應用程式使用的用戶端程式庫版本過舊。如果在啟用複寫功能後發現延遲時間變長，請確認應用程式使用的 Cloud Bigtable 用戶端程式庫是最新版本。舊版用戶端程式庫可能未經過最佳化，無法支援複製作業。請參閱 Cloud Bigtable 用戶端程式庫，找出用戶端程式庫的 GitHub 存放區，您可以在該處查看版本，並視需要升級。

  • 您已啟用複製功能，但未在叢集中新增節點。在採用複製功能的執行個體中，每個叢集除了要處理來自應用程式的負載，還必須處理複製作業。如果叢集資源不足，可能會導致延遲時間增加。如要確認這一點，請在 Google Cloud 控制台中查看執行個體的 CPU 使用率圖表。

由於效能會因工作負載不同而異，請測試自己的工作負載，以取得最準確的基準。

冷啟動和低 QPS

冷啟動和低 QPS 可能會增加延遲時間。Bigtable 最適合用於經常存取的大型資料表。因此，如果您在一段時間未使用後開始傳送要求 (冷啟動)，Bigtable 重新建立連線時，您可能會發現延遲時間較長。QPS 較低時，延遲時間也會較長。

如果每秒查詢次數偏低，或您知道自己有時會在一段時間沒有活動後，傳送要求至 Bigtable 資料表，請嘗試下列策略，保持連線運作並避免高延遲。

在 QPS 較低的期間，Bigtable 傳回的錯誤數量比傳回錯誤的作業百分比更具參考價值。

用戶端初始化時的冷啟動。 如果您使用的 Java 適用的 Cloud Bigtable 用戶端版本早於 2.17.1，可以啟用通道重新整理。在後續版本中，頻道重新整理功能預設為啟用。頻道重新整理會執行以下兩項作業：

  • 用戶端初始化時，會先準備好管道，再傳送第一個要求。
  • 伺服器每小時會中斷長期連線。頻道預先準備功能會預先取代即將到期的頻道。

不過，如果頻道一段時間沒有活動，這項功能就無法維持頻道熱度。

Bigtable 如何長期最佳化您的資料

為儲存每個資料表的基礎資料，Bigtable 會將資料分片為多個平板電腦，這些平板電腦可在 Bigtable 叢集中的節點之間移動。這種儲存方法可讓 Bigtable 隨著時間推移，使用兩種策略來最佳化資料：

  1. Bigtable 會在每個 Bigtable 節點上儲存大致相同的資料量。
  2. Bigtable 會在所有 Bigtable 節點之間平均分配讀取和寫入作業。

有時這些策略會互相衝突。舉例來說，如果某個子表的資料列讀取頻率極高，Bigtable 可能會將該子表儲存在自己的節點上，即使這會導致某些節點儲存的資料量多於其他節點。

在此程序中，Bigtable 可能會將子表分割成兩個或多個較小的子表，以縮減大小或隔離現有子表中的熱門資料列。

下列各節進一步詳述各個策略。

將資料量分散在節點中

將資料寫入 Bigtable 資料表時，Bigtable 會將資料表資料分片為平板電腦。每一個子表都包含資料表內連續範圍的資料列。

如果寫入資料表中的資料量不到數 GB，Bigtable 會將所有子表儲存在叢集中的單一節點上：

叢集具有四個位於單一節點上的子表。

隨著子表累積，Bigtable 會將部分子表移至叢集中的其他節點，以便更平均地分配叢集中的資料量：

額外的子表分散在多個節點中。

將讀取和寫入作業均勻分散在節點中

如果您已正確設計結構定義，那麼讀取和寫入作業應該會非常均勻分散在整個資料表中。然而，某些情況下，總是免不了會頻繁地存取某些特定資料列。Bigtable 會在節點間平衡平板電腦時，將讀取和寫入作業納入考量，協助您處理這些情況。

舉例來說，假設叢集內有少數幾個平板電腦的讀取作業占了 25%，而其他平板電腦的讀取作業則平均分配：

在 48 個子表中，25% 的讀取作業發生在 3 個子表上。

Bigtable 會重新分配現有平板電腦，盡可能在整個叢集中平均分配讀取作業：

三個熱門子表隔離在自己的節點上。

使用 Bigtable 測試效能

如果您要對依附於 Bigtable 的應用程式執行效能測試，請在規劃及執行測試時遵循下列準則：

  • 使用足夠的資料進行測試。
    • 如果生產環境例項中的資料表每節點總共包含 100 GB 以下的資料，請使用相同資料量的資料表進行測試。
    • 如果資料表每個節點的資料量超過 100 GB，請使用每個節點至少包含 100 GB 資料的資料表進行測試。舉例來說，如果您的正式版執行個體有一個四節點叢集，且執行個體中的資料表總共包含 1 TB 的資料，請使用至少 400 GB 的資料表執行測試。
  • 使用單一資料表進行測試。
  • 每個節點的儲存空間使用率應維持低於建議值。詳情請參閱「每個節點的儲存空間使用率」。
  • 測試前，請先執行幾分鐘的密集前測。Bigtable 會根據觀察到的存取模式，在節點間平衡資料。
  • 測試時間至少要 10 分鐘。這個步驟可讓 Bigtable 進一步將資料最佳化，並有助於您確實測試磁碟讀取和記憶體快取讀取。
  • 如要測試記憶體內層 (預先發布版)，請確保測試時間足夠，可讓系統讀取資料並填入記憶體內層。

排解效能問題

如果您認為 Bigtable 可能會造成應用程式效能瓶頸，請務必檢查下列所有項目：

  • 檢查資料表的 Key Visualizer 掃描結果。Bigtable 適用的 Key Visualizer 工具每 15 分鐘會產生新的掃描資料，顯示叢集中每個資料表的用量模式。您可以使用 Key Visualizer 檢查使用模式是否導致不良結果，例如特定資料列上的熱點或 CPU 使用率過高。詳情請參閱「使用 Key Visualizer」。
  • 註解排除 Bigtable 讀寫作業的程式碼。如果效能問題消失，表示您可能以導致效能不佳的方式使用 Bigtable。如果效能問題仍未解決，那麼問題很可能並非來自 Bigtable。

  • 請盡量減少建立的用戶端數量。建立 Bigtable 用戶端的成本相對較高。因此，您建立的用戶端應該越少越好：

    • 如果您使用複製功能，或是使用應用程式設定檔來辨識進入執行個體的不同流量類型，請為每個應用程式設定檔建立一個用戶端，並在整個應用程式中共用那些用戶端。
    • 如果沒有使用複製功能或應用程式設定檔，請建立單一用戶端，並在整個應用程式中共用這個用戶端。

    如果您使用 Java 適用的 HBase 用戶端，請建立 Connection 物件，而非用戶端，因此請盡量減少連線數。

  • 請務必在資料表中讀取及寫入多個不同的資料列。 如果讀取和寫入作業平均分散在整個資料表中，Bigtable 的效能最佳，這有助於 Bigtable 將工作負載分配到叢集中的所有節點。如果讀取和寫入作業不能分散到所有的 Bigtable 節點中，效能就會降低。

    如果您發現讀取和寫入只集中在少數的資料列時，可能需要重新設計您的結構定義，讓讀取和寫入作業可以更均勻地分佈。

  • 確認讀取和寫入效能大致相同。如果發現讀取速度遠快於寫入速度，可能是因為您嘗試讀取不存在的資料列索引鍵，或是只含有少量資料列的大範圍資料列索引鍵。

    如要有效比較讀取和寫入作業，請確保至少 90% 的讀取作業會傳回有效結果。此外，如果讀取大範圍的資料列索引鍵，請根據這個範圍內的實際資料列數測量效能，而不是根據「可能」存在的最大資料列數。

  • 為您的資料使用正確的寫入要求類型。 選擇最佳的資料寫入方式有助於維持高效能。

  • 檢查單一資料列的延遲時間。如果在傳送 ReadRows 要求時發生非預期的延遲，您可以檢查要求第一列的延遲，縮小原因範圍。根據預設，ReadRows要求的整體延遲時間包括要求中每列的延遲時間，以及列之間的處理時間。如果整體延遲時間很長，但第一列延遲時間很短，表示延遲時間是由要求數量或處理時間所致，而非 Bigtable 問題。

    如果您使用 Java 適用的 Bigtable 用戶端程式庫，啟用用戶端指標後，即可在Google Cloud 控制台的 Metrics Explorer 中查看 read_rows_first_row_latency 指標。

  • 為每個工作負載使用專屬的應用程式設定檔。如果新增工作負載後發生效能問題，請為新的工作負載建立新的應用程式設定檔。然後分別監控應用程式設定檔的指標，進一步排解問題。如要瞭解為什麼建議使用多個應用程式設定檔，請參閱「應用程式設定檔的運作方式」。

  • 啟用用戶端指標。您可以設定用戶端指標，協助改善及排解效能問題。舉例來說，由於 Bigtable 最適合處理平均分配的高 QPS，因此一小部分要求的 P100 (最大) 延遲時間增加，不一定表示 Bigtable 有較大的效能問題。用戶端指標可協助您深入瞭解請求生命週期中，哪個部分可能導致延遲。

  • 請確保應用程式會在讀取要求逾時前耗用這些要求。如果應用程式在讀取串流期間處理資料，要求可能會在您收到呼叫的所有回應之前逾時。這會導致 ABORTED 訊息。如果看到這個錯誤，請減少讀取串流期間的處理量。

直接連線

Bigtable 支援符合特定條件的應用程式流量直接連線，可略過 Google 前端並提升效能。升級至最新版本的用戶端程式庫，即可直接連線，進而提升處理量並縮短延遲時間。直接連線適用於具有下列特性的應用程式：

  • 在虛擬私有雲 (VPC) 網路中，於 Compute Engine 或 Google Kubernetes Engine (GKE) 虛擬機器上執行
  • 使用支援的 Bigtable 用戶端程式庫
  • 使用標準應用程式設定檔 (而非 Data Boost)
  • 在設定了路由和防火牆規則的網路中，允許輸出流量連到 34.126.0.0/18 和 2001:4860:8040::/42

使用下列任一 Bigtable 用戶端程式庫時，系統預設會啟用直接連線：

支援 IPv4 和 IPv6。詳情請參閱虛擬私有雲說明文件中的「直接連線至 API 和服務」。

後續步驟