設計結構定義

本頁說明如何為 Cloud Bigtable 資料表設計結構定義。 閱讀本頁之前,應先熟讀 Cloud Bigtable 總覽

基本概念

設計 Cloud Bigtable 結構定義與設計關聯資料庫結構定義非常不同。您設計 Cloud Bigtable 結構定義時,請牢記以下概念:

  • 每個資料表只有一個索引,也就是資料列索引鍵。 並沒有次要索引。
  • 資料列是依據字典順序由資料列索引鍵排序,順序為最低到最高的位元組字串。資料列索引鍵是以位元組由大到小排序,或是以網路、位元組順序,或相當於字母順序的二進位排序。
  • 資料欄會按資料欄系列分組,並按資料欄系列中的字母順序排序。
  • 所有作業在資料列層級均為不可部分完成。 例如若您更新資料表的兩個列,有可能其中一個列成功更新,但另一個列更新失敗。請避免讓結構定義設計需要在資料列之間符合不可部分完成原則。
  • 在理想情況下,讀取及寫入應平均分佈在資料表列空間之中。
  • 一般來說,請讓實體的所有資訊位於單一資料列之中。 不需要不可部分完成更新及讀取的實體,可分割位於多個列之間。 如果實體資料偏大 (數百 MB),就建議分割位於多個列之間。
  • 相關實體應儲存於鄰近資料列,可提升讀取效率。
  • Cloud Bigtable 資料表是疏鬆的。 空欄不會佔用任何空間。因此建立非常大量的欄通常是合理作法,即使大部分資料列之中大多為空欄亦同。

大小限制

Cloud Bigtable 會針對您在資料表儲存的資料設定大小限制。請確保在設計結構定義時考量這類限制。

由於 Cloud Bigtable 會以不可部分完成的方式讀取資料列,因此限制在單列儲存資料的總量特別重要。最佳做法是在單一儲存格儲存最多 10 MB,單列最多儲存 100 MB。您也不得超過儲存格及資料列的資料大小強制限制

以上大小限制是以二進位 MB 為單位,其中 1 MB 等於 220 位元組;這種計算單位也稱為 MiB

選擇資料列索引鍵

為了讓 Cloud Bigtable 發揮最佳效能,您必須仔細思考要如何撰寫您的資料列索引鍵。這是因為效率最高的 Cloud Bigtable 查詢會使用資料列索引鍵、資料列索引鍵前置字串或資料列範圍來擷取資料。其他查詢類型會觸發完整的資料表掃描,大幅降低效率。現在選擇正確的資料列索引鍵,就可以避免之後痛苦的資料遷移程序。

首先,請思考您會如何使用要儲存的資料。例如:

  • 使用者資訊:您是否需要快速存取使用者之間的連結相關資訊 (例如使用者 A 是否追蹤使用者 B)?
  • 使用者自製內容:若您向使用者顯示狀態更新等大量使用者自製內容範例,您要如何決定向特定使用者顯示哪些狀態更新?
  • 時間序列資料:您是否需要經常擷取最新的 N 記錄,或是特定時間範圍之中的記錄?如果您儲存多種類型的事件資料,是否需要依據事件類型進行篩選?

事先瞭解本身需求,可協助您確保資料列索引鍵及整體結構定義設計提供足夠彈性,有效地查詢資料。

資料列索引鍵類型

本節說明部分最常用的資料列索引鍵類型,以及每種資料鍵的使用時機。

一般準則是在合理範圍內採用簡短的資料列索引鍵。長的資料列索引鍵會佔用額外記憶體及儲存空間,增加由 Cloud Bigtable 伺服器取得回應的時間。

反向網域名稱

若您儲存的實體資料,可利用網域名稱的方式表示,請考慮使用反向網域名稱 (例如 com.company.product) 作為資料列索引鍵。如果每列資料會與鄰近列重疊,使用反向網域名稱就特別理想;這樣可讓 Cloud Bigtable 更有效地壓縮您的資料。

這種方法最適合用於資料散佈在許多不同反向網域名稱的情況。如果您預期在少量的反向網域名稱之中儲存大部分資料,請考慮為資料列索引鍵使用其他值。否則您可能會將大部分寫入作業推向叢集之中的單一節點,造成子表超載。

字串 ID

若您儲存的實體資料可利用簡單字串識別 (例如使用者 ID),就可能需要使用字串 ID 作為資料列索引鍵,或作為資料列索引鍵的一部分。

過去本頁建議使用字串 ID 雜湊碼,而不是使用實際的字串 ID,不過我們已不再建議使用雜湊碼。我們發現採用雜湊碼的資料列索引鍵,會讓 Cloud Bigtable 問題非常難以進行疑難排解,因為雜湊碼資料列索引鍵實際上是沒有意義的。例如若您的資料列索引鍵為使用者 ID 雜湊碼,就會很難或無法找出哪一個使用者 ID 與資料列索引鍵連結。

請以使用者可理解的值取代雜湊資料列索引鍵。此外,若您的資料列索引鍵包含多個值,請以分隔符號分隔這些值。以上實務做法也可讓您更容易使用 Key Visualizer 工具,針對 Cloud Bigtable 問題進行疑難排解。

時間戳記

若您經常需要依據資料記錄時間擷取資料,就適合在資料列索引鍵之中納入時間戳記。我們「不建議」使用時間戳記本身作為資料列索引鍵,因為這樣會將大部分寫入作業推向單一節點。同樣地,請避免將時間戳記放置在資料列索引鍵的開始處。

例如您的應用程式可能需要記錄 CPU 和記憶體使用情形等效能相關資料,針對大量機器每秒鐘記錄一次。此項資料的資料列索引鍵可結合機器 ID 及資料時間戳記 (例如 machine_4223421#1425330757685)。

如果您通常會先擷取最近的記錄,您可以從程式設計語言的長整數最大值 (在 Java 中為 java.lang.Long.MAX_VALUE) 減去時間戳記,藉此在資料列索引鍵中使用反向時間戳記。使用反向時間戳記後,記錄將以最新至最舊的方式排序。

多個值位於單一資料列索引鍵

由於資料列索引鍵是有效查詢 Cloud Bigtable 的唯一方式,因此在資料列索引鍵納入多個 ID 通常相當實用。資料列索引鍵包含多個值時,特別重要的就是明確瞭解自己要如何使用資料。

例如假設您的應用程式可讓使用者發佈訊息,且使用者可在貼文之中提及他人。您希望能有效列出在貼文中標記特定使用者的所有使用者。其中一種方式是使用包含受標記使用者名稱的資料列索引鍵,於之後接續進行標記的使用者名稱,並以分隔符號分隔兩者 (例如 wmckinley#gwashington)。如欲找出標記特定使用者名稱的使用者,或顯示標記該使用者名稱的所有貼文,您可擷取資料列索引鍵中以該使用者名稱為開頭的一系列資料列。

建立資料列索引鍵,使其仍能擷取一系列妥善定義的資料列是很重要的,否則您的查詢就需要進行資料表掃描,速度比擷取特定資料列慢上許多。例如假設您每秒儲存一次效能相關資料,若您的資料列索引鍵包含時間戳記和機器 ID (例如 1425330757685#machine_4223421),就無法有效率地將查詢限制在特定機器,只能依據時間戳記限制查詢範圍。

資料列索引鍵前置字串

在包含多個值的資料列索引鍵中,第一個值稱為資料列索引鍵前置字串。經過良好規劃的資料列索引鍵前置字串可利用 Cloud Bigtable 的排序順序,在連續的資料列中儲存相關資料,讓您以資料列範圍存取相關資料,不需執行效率不佳的資料表掃描。

在多租戶架構使用資料列索引鍵前置字元

資料列索引鍵前置字元為「多租戶架構」使用案例提供可擴充的解決方案,讓您代表多位客戶使用相同的資料模型來儲存類似的資料。在儲存與存取多租戶架構資料時,將所有用戶納入同一個資料表,通常是最具效能的方式。

例如,假設您替許多公司儲存和追蹤購買記錄,您可以在每個公司使用唯一識別碼,來做為資料列索引鍵的前置字串。用戶的所有資料都會儲存在相同資料表的連續資料列中,方便您使用資料列索引鍵前置字串進行查詢或篩選。當某間公司不再是您的客戶,您必須刪除為該公司儲存的購買記錄資料時,便可捨棄使用該客戶資料列索引鍵前置字串的資料列範圍。

相反地,若您將每家公司的資料儲存在各自的資料表中,就很有可能會遭遇到效能與擴充性的問題,也會不意外地超過 Cloud Bigtable 每個執行個體 1,000 個資料表的限制。

避免使用資料列索引鍵的情況

部分類型的資料列索引鍵,可能會讓您難以查詢資料或導致效能不彰。本節說明您在 Cloud Bigtable 應避免使用的部分資料列索引鍵類型。

網域名稱

避免使用標準非反向的網域名稱作為資料列索引鍵。使用標準網域名稱會無法有效擷取部分網域名稱之中的所有資料列 (例如與 company.com 有關的所有資料列將位於不同的資料列範圍,例如 services.company.comproduct.company.com 等等)。此外,使用標準網域名稱會造成資料列在排序時,相關資料無法聚集在單一位置,可能導致壓縮效率降低。

依序數字 ID

假設您的系統指派數字 ID 至各個應用程式使用者, 您可能會想要以使用者數字作為資料表的資料列索引鍵。 不過由於新使用者成為作用中使用者的機率較高,這種方式可能會將大部分流量推向少量節點。

比較安全的方式是以相反的方式使用使用者的數字 ID,將流量更平均地分佈在 Cloud Bigtable 資料表的所有節點。

經常更新的識別碼

請避免使用單一資料列索引鍵來識別非常頻繁更新的值。例如,如果您每秒儲存一次記憶體用量資料,請「勿」使用名為 memusage 的單一資料列索引鍵並重複更新該資料列。 這類作業會讓儲存常用資料列的子表超載, 也可能讓資料列超過大小限制,因為儲存格之前的值會佔用空間一段時間。

請在每列儲存一個值,使用包含指標、分隔符號及時間戳記類型的資料列索引鍵。例如若您需要追蹤記憶體隨時間變化的使用情形,可使用類似 memusage#1423523569918 的資料列索引鍵。這項策略效率優異,因為在 Cloud Bigtable 之中建立新資料列的時間,並不會比建立新儲存格更久。此外這項策略也可讓您計算適當的起始及結束索引鍵,迅速由特定日期範圍內讀取資料。

對非常頻繁變更的值而言,例如每分鐘更新數百次的計數器,最理想的做法是讓資料留在應用程式層的記憶體之中,並定期將新資料列寫入 Cloud Bigtable。

雜湊值

如前所述,本頁過去建議在資料列索引鍵使用雜湊值,不過我們已不再建議採取這種做法。使用雜湊值基本上會讓資料列索引鍵沒有意義,使其難以使用 Key Visualizer 工具針對 Cloud Bigtable 問題進行疑難排解。

請以使用者可理解的值取代雜湊值。若您的資料列索引鍵包含多個值,請以分隔符號分隔這些值。

資料欄系列及資料欄限定詞

本節說明如何考量資料表之中的資料欄系列及資料欄限定詞。

資料欄系列

有別於 HBase,在 Cloud Bigtable 您可使用最多約 100 個資料欄系列,同時仍維持絕佳效能。因此只要資料列包含多個彼此相關的值,理想做法就是將這些值集中在相同資料欄系列之中。將資料集中在資料欄系列,可讓您由單一系列或多個系列擷取資料,而不是在各個資料列擷取所有資料。將資料盡可能密集集中在一起,您就可以在最常用的 API 呼叫之中,僅取得您需要的資訊。

資料欄系列名稱也應保持簡短,因為每次要求傳輸的資料之中都包含這類名稱。

資料欄限定詞

由於 Cloud Bigtable 資料表是疏鬆的,您可在每個資料列建立不限數量的資料欄限定詞。資料列之中的空儲存格並不會遭受空間處罰,因此將資料欄限定詞視為資料通常是合理的。舉例來說,如果您的資料表會儲存使用者貼文,您就可以使用各貼文的不重複 ID 做為資料欄限定詞。

也就是說,您應避免在超過所需數量的資料欄限定詞之間分割資料,這樣可能造成資料列擁有大量的非空白儲存格。Cloud Bigtable 需要時間來處理資料列中的每一個儲存格。每一個儲存格也會對資料表儲存及透過網路傳送的資料量增加一些負擔。舉例來說,如果要儲存 1 KB (1,024 個位元組) 的資料,將這些資料儲存在單一儲存格,要比將資料分散儲存到 1,024 個各包含 1 位元組的儲存格更具有空間效率。 如果您常一次讀取或寫入幾個相關值,請考慮將所有值一同儲存到單一儲存格,而使用的格式要能於之後輕鬆擷取個別值 (例如通訊協定緩衝區二進位格式)。

同樣地,資料欄限定詞名稱也應保持簡短,有助於減少每次要求傳輸的資料量。

相關資源

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

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

這個網頁
Cloud Bigtable 說明文件