瞭解 Cloud Bigtable 效能

假如您要去拜訪一位朋友。您應該搭飛機去嗎?這要看您去哪裡。如果對方就住在附近,也許您有更好的交通方式。但是如果朋友住在千里之外,或許搭飛機可以最快抵達。

使用 Cloud Bigtable 時,很多地方都跟搭乘飛機很像。Cloud Bigtable 擅長處理長時間 (數小時或數天) 內非常大量的資料 (幾 TB 或幾 PB),不適合用來處理短時間內的少量資料。如果您試著讓 Cloud Bigtable 處理幾 GB 的資料 30 秒,將拿不到準確的效能數據。

請繼續閱讀下文,進一步瞭解 Cloud Bigtable 如何提供您所期待的效能。

一般工作負載效能

在一般工作負載下,Cloud Bigtable 提供非常容易預測的效能。在一切運作順暢時,視叢集使用的儲存空間類型而定,一般工作負載可在 Cloud Bigtable 叢集中的每個節點達到下列效能:

儲存空間類型 讀取   寫入 掃描
SSD 每秒 10,000 個資料列 @ 6 ms 每秒 10,000 個資料列 @ 6 ms 220 MB/秒
HDD 每秒 500 個資料列 @ 200 ms 每秒 10,000 個資料列 @ 50 ms 180 MB/秒

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

一般來說,叢集的效能會隨著叢集中的節點增加而線性提升。舉例來說,如果您建立的 SSD 叢集包含 10 個節點,這個叢集每秒可支援多達 100,000 個資料列執行一般唯讀或唯寫工作負載,而每次讀取或寫入作業的延遲時間為 6 毫秒。

這些效能預估值是參考準則,但不是鐵則。每一節點效能因工作負載及資料表中每一個資料列的一般大小而異。

此外,這些值反映的是唯讀或唯寫工作負載的預估效能。混合讀取和寫入的工作負載效能會有所不同。視工作負載而定,整體總處理量可能會低於唯讀或唯寫工作負載的一般每秒資料列數量。

效能緩慢的原因

若 Cloud Bigtable 執行效能低於上述預估值,可能有幾個原因:

  • 資料表的結構定義設計不正確。 為了讓 Cloud Bigtable 發揮良好效能,需要設計一個結構定義,使讀取和寫入作業能均勻分散在各個資料表中。進一步詳情請參閱設計您的結構定義
  • 工作負載不適用 Cloud Bigtable。 如果您測試少量 (低於 300 GB) 的資料,或測試極短的時間 (只有幾秒,而不是幾分鐘或幾小時),Cloud Bigtable 將無法提供良好的效能來均衡資料。它需要時間來學習您的存取模式,也需要夠大量的資料才能充分利用叢集中的所有節點。
  • Cloud Bigtable 資料表中的資料列包含大量資料。 上方顯示的效能預估值假設每個資料列包含 1 KB 的資料。每個資料列可以讀取及寫入更大的資料量,但增加每個資料列的資料量也會降低每秒的資料列數。
  • Cloud BigTable 資料表中的資料列包含非常大量的儲存格。Cloud Bigtable 需要時間來處理資料列中的每一個儲存格。每一個儲存格也會對資料表儲存及透過網路傳送的資料量增加一些負擔。舉例來說,如果要儲存 1 KB (1,024 個位元組) 的資料,將這些資料儲存在單一儲存格中,要比將資料分散儲存到 1,024 個各包含 1 個位元組的儲存格更具有空間效率。如果您將資料分割儲存到高於所需的儲存格中,有可能無法獲得最佳效能。
  • Cloud Bigtable 叢集沒有足夠的節點。 如果 Cloud Bigtable 叢集超載,增加更多節點可以改善效能。監控工具可用於檢查叢集是否超載。
  • Cloud Bigtable 叢集最近經過規模增減。變更叢集中的節點數量後,可能需要在負載情況下執行多達 20 分鐘,之後您才會看到叢集效能有明顯的改善。
  • Cloud Bigtable 叢集使用 HDD 磁碟。 在大部分的情況下,叢集應使用 SSD 磁碟,這類磁碟的效能明顯優於 HDD 磁碟。詳情請參閱選擇 SSD 或 HDD 儲存裝置
  • Cloud Bigtable 執行個體屬於開發環境執行個體。 由於開發環境執行個體的效能等同一個有單節點叢集的執行個體,所以執行效能不如實際工作環境執行個體。尤其是如果執行個體處於負載吃重時,您可能會看到大量的錯誤。
  • 網路連線有問題。 網路問題會造成總處理量降低,讀取和寫入作業的時間會比平常更久。尤其是如果用戶端與 Cloud Bigtable 叢集的執行所在區域不同,或用戶端在 Google Cloud Platform 之外執行時,您可能會看到錯誤。

由於效能會因工作負載不同而異,所以您應該測試自己的工作負載,以取得最準確的基準。

複製功能和效能

啟用複製功能會對 Cloud BigTable 執行個體的效能造成影響。複製功能對某些指標有正面影響,對其他指標則有不良影響。決定啟用複製功能之前,您應該先瞭解對效能的潛在影響。

讀取與掃描

複製功能可以提高讀取總處理量,尤其是在使用多叢集轉送時。此外,將 Cloud BigTable 資料放置在距離應用程式使用者較近的地理位置,複製功能可以降低讀取延遲。

寫入總處理量

雖然複製功能可以提高可用性和讀取效能,但無法增加寫入總處理量。您必須將針對一個叢集的寫入作業複製到執行個體中的所有其他叢集。因此,每個叢集都會消耗 CPU 資源,以從其他叢集提取變更。由於複製作業會讓每個叢集執行額外工作,因此寫入總處理量實際上可能會下降。

例如,假設您有一個單一叢集執行個體,而該叢集包含 3 個節點:

包含 3 個節點的單一叢集執行個體

新增節點至該叢集時,對寫入總處理量的影響,與將第二個包含 3 個節點的叢集新增至執行個體來啟用複製功能相比,影響程度並不相同。

新增節點至原始叢集:您可以新增 3 個節點至該叢集,使其總共包含 6 個節點。執行個體的寫入總處理量會加倍,但您只能在一個區域中取得該執行個體的資料:

包含 6 個節點的單一叢集執行個體

啟用複製功能:您也可以新增第二個包含 3 個節點的叢集,使其總共包含 6 個節點。執行個體現在會將每個資料片段寫入兩次:收到時會執行第一次寫入,複製到其他叢集時會執行第二次寫入。寫入總處理量不僅不會增加,還可能會下降,但您可以從兩個不同的區域中取得資料:

包含 6 個節點的雙叢集執行個體

在上述範例中,即使每個執行個體的叢集都包含共 6 個節點,但單一叢集執行個體可以處理的寫入總處理量比複製的執行個體多了一倍。

複製延遲時間

使用多叢集轉送時,Cloud BigTable 的複製功能具有最終一致性。一般來說,距離越遠,複製資料所需的時間就越久。與相同地區中的複製叢集相較,不同地區中的複製叢集所需的複製延遲時間較長。

應用程式設定檔和流量轉送

您可以根據自身用途來決定使用一或多個應用程式設定檔轉送 Cloud BigTable 流量。每個應用程式設定檔會使用多叢集轉送或單叢集轉送。轉送選項會影響效能。

多叢集轉送可以將延遲時間降到最低。從應用程式的角度來看,使用多叢集轉送的應用程式設定檔會自動將要求轉送至執行個體中最接近的叢集,然後將寫入內容複製到執行個體中的其他叢集。這種自動選擇最短距離的做法會將延遲時間降至最低。

使用單叢集轉送的應用程式設定檔對某些用途來說是最佳選項,例如區隔工作負載,或單一叢集上的寫入後讀取作業語意,但單叢集轉送不像多叢集轉送一樣可以降低延遲時間。

如要瞭解如何針對不同用途設定應用程式設定檔,請參閱複製功能設定範例一文。

Cloud BigTable 如何長期最佳化您的資料

為了儲存各個資料表的基礎資料,Cloud Bigtable 會將資料分散到多個資料表中,而這些資料表可以在 Cloud Bigtable 叢集中的節點之間移動。這種儲存方法讓 Cloud Bigtable 得以使用下列兩種策略,長期對資料進行最佳化:

  1. Cloud Bigtable 嘗試將數量差不多的資料儲存在每個 Cloud Bigtable 節點上。
  2. Cloud Bigtable 嘗試將讀取和寫入作業均勻分散在所有的 Cloud Bigtable 節點中。

這些策略有時會互相抵觸。舉例來說,如果極度頻繁讀取某個子表的資料列,Cloud Bigtable 可能會將這個子表儲存在該子表自己的節點上,即使這會造成某些節點儲存的資料比其他節點多。

在這個過程中,Cloud Bigtable 也可能會將子表分割成兩個或更多個更小的子表,藉此降低子表的大小或隔離現有子表內的熱門資料列。

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

將資料量分散在節點中

將資料寫入 Cloud Bigtable 資料表時,Cloud Bigtable 會將資料表的資料分割到子表中。每一個子表都包含資料表內連續範圍的資料列。

如果只將少量資料寫入資料表,Cloud Bigtable 會將所有子表儲存在叢集中的單一節點上:

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

當累積的子表越來越多時,Cloud Bigtable 會將其中一部分移至叢集中的其他節點,讓資料量可以更均勻分佈在叢集中:

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

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

如果您已正確設計結構定義,那麼讀取和寫入作業應該會非常均勻分散在整個資料表中。然而,某些情況下,總是免不了會頻繁地存取某些特定資料列。Cloud Bigtable 可以協助您處理這樣的情況,因為這項服務跨節點均衡配置子表時,會考量到讀取和寫入作業。

舉例來說,假設 25% 的讀取作業是發生在叢集中的少數子表上,且讀取作業均勻分散在其他子表中:

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

Cloud Bigtable 將會重新分配現有的子表,使讀取作業盡可能均勻分散在整個叢集中:

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

測試 Cloud Bigtable 效能

如果您要執行的效能測試涉及 Cloud Bigtable,請務必按照下列步驟來規劃及執行您的測試:

  1. 使用正式版執行個體。 開發版執行個體無法準確提供正式版執行個體在負載下的執行效能。
  2. 使用至少 300 GB 的資料。 Cloud BigTable 在處理 1 TB 或更多的資料時效能最佳。不過,在 3 個節點的叢集上,300 GB 的資料已經足以提供合理的效能測試結果。在較大的叢集上,每個節點則應使用至少 100 GB 的資料量。為簡單起見,請使用單一資料表進行測試。
  3. 每個節點的儲存空間使用率應維持低於建議值。 詳情請參閱每個節點的儲存空間使用率
  4. 進行測試之前,請執行滿載預先測試數分鐘。 執行這個步驟可讓 Cloud Bigtable 根據所觀察到的存取模式,先將資料均衡分散在節點中。
  5. 執行測試至少 10 分鐘。 這個步驟可讓 Cloud Bigtable 進一步將資料最佳化,並有助於您確實測試磁碟讀取和記憶體快取讀取。

您可以使用以 Go 編寫的 Cloud Bigtable loadtest 工具做為自行開發效能測試的起點。loadtest 工具會執行由 50% 讀取和 50% 寫入組成的簡單工作負載。

效能問題疑難排解

如果您發現 Cloud Bigtable 可能在您的應用程式中造成效能瓶頸,請確實檢查下列幾點:

  • 查看 Key Visualizer 掃描資料表的結果。 Cloud Bigtable 的 Key Visualizer 工具可執行每日掃描,並顯示叢集中各個資料表的使用模式。Key Visualizer 可以輕鬆查出使用模式是否造成不良結果,譬如,特定資料列出現資源使用率不均的問題或 CPU 使用率過高。瞭解如何開始使用 Key Visualizer
  • 試著在執行 Cloud Bigtable 讀取和寫入的程式碼中加上註解。 如果效能問題未再出現,便可能是 Cloud Bigtable 的使用方式導致效能不盡理想。如果效能問題持續發生,則這項問題可能與 Cloud Bigtable 無關。
  • 盡可能少建立用戶端。 為 Cloud Bigtable 建立用戶端是一個相對高成本的作業。因此,您建立的用戶端應該越少越好:

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

    如果使用 Java 適用的 HBase 用戶端,您建立的會是 Connection 物件,而非用戶端,因此您建立的連線應越少越好。

  • 確認讀取和寫入資料表中的多個不同資料列。當讀取和寫入作業均勻分佈在整個資料表中,這可協助 Cloud Bigtable 將工作負載分散到叢集中的所有節點,此時 Cloud Bigtable 執行效能最佳。如果讀取和寫入作業不能分散到所有的 Cloud Bigtable 節點中,效能會受到嚴重影響。

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

  • 確認您看到的讀取和寫入效能大致相同。 如果您發現讀取速度比寫入快很多,可能是您嘗試讀取的資料列索引鍵不存在,或是讀取了大範圍的資料列索引鍵,但其中只包含少數的資料列。

    為了對讀取和寫入進行有效比較,您應該瞄準測試至少 90% 的讀取作業,以傳回有效的結果。此外,如果讀取大範圍的資料列索引鍵,請根據這個範圍內的實際資料列數測量效能,而不是根據「可能」存在的最大資料列數。

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

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Bigtable 說明文件