瞭解效能

本頁面說明 Bigtable 在最佳條件下可提供的約略效能、可能影響效能的因素，以及測試和疑難排解 Bigtable 效能問題的提示。

一般工作負載效能

Bigtable 的效能相當穩定，容易預測，會隨著資源增加等比例提高。只要避免本頁所述導致效能降低的原因，每個 Bigtable 節點就能提供下列約略處理量，具體取決於叢集使用的儲存空間類型：

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

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

1 Enterprise Plus 節點每秒可處理 40,000 列，並能以 40,000 列為單位垂直擴充，每個節點每秒最多可處理 120,000 列。詳情請參閱「記憶體內層級」。

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

一般來說，叢集的效能會隨著您在叢集中新增節點而線性擴充。舉例來說，如果您建立含有 10 個節點的 SSD 叢集，在未啟用記憶體內層的情況下，該叢集每秒最多可支援 140,000 個資料列，適用於一般唯讀或唯寫工作負載。啟用記憶體內層後，叢集每秒最多可支援 120 萬列的讀取處理量。

規劃 Bigtable 容量

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

記憶體內層

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

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

CPU 使用率

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

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

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

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

儲存空間使用率

儲存空間是容量規劃的另一項考量。叢集的儲存空間容量取決於儲存空間類型和叢集中的節點數量。當叢集內儲存的資料量增加時，Bigtable 會將資料分配到叢集內的所有節點，藉此最佳化儲存空間。

在規劃容量時，請根據預期的壓縮資料大小 (而非未壓縮的來源資料) 估算儲存空間需求和叢集節點數量。Bigtable 會在寫入儲存空間時自動壓縮資料。視結構定義設計和資料模式而定，壓縮功能可大幅減少磁碟上的實體儲存空間用量。如需資料壓縮指南，請參閱「資料壓縮」。

如要判斷每個節點的儲存空間用量，您可以將叢集的儲存空間使用率 (位元組) 除以叢集中的節點數量。舉例來說，假設某個叢集有三個 HDD 節點和 9 TB 的資料。每個節點儲存約 3 TB，也就是每個節點 HDD 儲存空間上限 16 TB 的 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 較低時，延遲時間也會較長。

如果 QPS 偏低，或您知道有時會在一段時間未活動後，向 Bigtable 資料表傳送要求，請嘗試下列策略，讓連線保持活躍，並防止高延遲。

在 QPS 較低的期間，Bigtable 傳回的錯誤數量比傳回錯誤的作業百分比更重要。

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

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

不過，如果有一段時間沒有活動，管道就不會保持運作。

Bigtable 如何逐步最佳化資料

為了儲存每個資料表的基礎資料，Bigtable 會將資料分割成多個 tablet，這些 tablet 可以在 Bigtable 叢集的節點之間移動。這種儲存方式可讓 Bigtable 採用兩種策略，逐步最佳化資料：

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

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

在這個過程中，Bigtable 可能會將一個 Tablet 分割成兩個或更多較小的 Tablet，以縮減其大小或隔離現有 Tablet 中的熱門資料列。

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

將資料量分散在節點中

將資料寫入 Bigtable 資料表時，Bigtable 會將資料表資料分割成多個 tablet。每一個子表都包含資料表內連續範圍的資料列。

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

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

隨著 Tablet 數量增加，Bigtable 會將部分 Tablet 移至叢集中的其他節點，更平均地分配叢集中的資料量：

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

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

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

舉例來說，假設 25% 的讀取作業會傳送至叢集內少數幾個 tablet，而讀取作業會平均分散至所有其他 tablet：

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

Bigtable 會重新分配現有 tablet，盡可能將讀取作業平均分配到整個叢集：

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

使用 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 建立用戶端的成本相對較高。因此，您建立的用戶端應該越少越好：

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

    如果您使用 HBase Java 用戶端，請建立 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 和服務」。

後續步驟