時間序列資料的結構定義設計

本頁面說明在 Bigtable 儲存時間序列資料的結構定義設計模式。本頁面以「設計結構定義」為基礎，並假設您熟悉該頁面所述的概念和建議。

時間序列是資料集合，包含測量結果和記錄測量結果的時間。時間序列的例子包括：

  • 電腦記憶體用量圖
  • 新聞報導中的氣溫隨時間變化
  • 一段時間內的股市價格

良好的結構定義可帶來出色的效能和擴充性，而不良的結構定義則可能導致系統效能不佳。不過，沒有任何一種結構定義設計能完美因應所有用途。

本頁所述的模式可做為起點。為時間序列資料設計結構定義時，最重要的是考量您獨特的資料集和預計使用的查詢。

在 Bigtable 中儲存時間序列資料的基本設計模式如下：

範例資料

為說明模式之間的差異，本頁範例假設您要儲存應用程式的資料，該應用程式會記錄氣象氣球每分鐘測量一次的資料。我們使用「事件」一詞，代表同時寫入一或多個儲存格的單一要求。地區 ID 對應 Google Cloud 區域。

評估 範例
  1. 本頁面的時間戳記格式為「tYYYY-MM-DD-HHMM」，方便使用者閱讀。在實際工作環境資料表中，時間戳記通常會以自 1970-01-0100:00:00 UTC 起算的微秒數表示，例如「1616264288050807」。
壓力 (帕斯卡) 94587
溫度 (攝氏) 9.5
濕度 (百分比) 65
海拔高度 (公尺) 601
相關資料 範例
氣球 ID 3698
位置 asia-southeast1
時間戳記1 t2021-03-05-1204

時間區間

在時間值區模式中，資料表中的每一列都代表一個時間「值區」，例如一小時、一天或一個月。資料列索引鍵包含非時間戳記 ID (例如 week49)，用於記錄資料列中的時間範圍，以及其他識別資料。

您使用的值區大小 (例如分鐘、小時或天) 取決於您打算使用的查詢和 Bigtable 資料大小限制。舉例來說，如果包含一小時資料的資料列大於建議的每列大小上限 100 MB，則代表半小時或一分鐘的資料列可能是更好的選擇。

時間值區模式的優點如下：

  • 成效會有所提升。舉例來說，如果您儲存 100 個測量值，Bigtable 在一個資料列中寫入和讀取這些測量值的速度，會比在 100 個資料列中更快。

  • 以這種方式儲存的資料，壓縮效率會高於高窄資料表中的資料。

缺點包括：

  • 時間值區結構定義設計模式比單一時間戳記模式更複雜，可能需要更多時間和精力來開發。

為新事件新增資料欄

在這個時間值區模式中，您會為每個事件在資料列中寫入新資料欄，並將資料儲存在資料欄限定詞中，而不是儲存為儲存格值。也就是說，您會為每個儲存格傳送資料欄系列、資料欄限定詞和時間戳記，但不會傳送值。

以天氣氣球範例資料來說，如果採用這種模式，每列會包含單一氣球在單一指標 (例如 pressure) 的一週測量結果。每個資料列索引鍵都包含位置、氣球 ID、您在資料列中記錄的指標，以及週數。每當氣球回報指標資料時，您就會在資料列中新增資料欄。資料欄限定詞包含測量值，即以帕斯卡為單位的壓力，以及儲存格時間戳記識別的分鐘。

在這個範例中，三分鐘後的資料列可能如下所示：

資料列索引鍵 94558 94122 95992
us-west2#3698#pressure#week1 "" (t2021-03-05-1200) "" (t2021-03-05-1201) "" (t2021-03-05-1202)

這個模式的用途包括：

為新事件新增儲存格

在這個時間值區模式中，您會在寫入新事件時，將新儲存格新增至現有資料欄。這個模式可讓您充分運用 Bigtable 的功能，在特定資料列和資料欄中儲存多個加上時間戳記的儲存格。使用這個模式時，請務必指定垃圾收集規則。

如果工作負載的事件發生率很高，同一毫秒內可能會發生多個事件，導致時間戳記衝突而遺失資料。如要在為新事件新增儲存格時避免這種情況，您可以將資料表設定為使用微秒時間戳記精細程度。這項功能僅適用於 Enterprise Plus 版本的執行個體。

以氣象氣球資料為例，每一列都包含單一氣象氣球在一週內的所有測量結果。資料列索引鍵前置字元是週的 ID，因此您可以使用單一查詢，讀取多個氣球一整週的資料。其他資料列索引鍵區段則是氣球的運作位置和 ID 號碼。資料表有一個 measurements 資料欄系列，該系列則為每種測量類型建立一個資料欄：pressure、temperature、humidity 和 altitude。

每當氣球傳送測量結果時，應用程式就會將新值寫入含有氣球當週資料的資料列，並在每個資料欄中寫入額外的時間戳記儲存格。一週結束時，每列中的每個資料欄都會有一週內每分鐘的一項測量結果，或 10,080 個儲存格 (如果垃圾收集政策允許)。

每列中的各欄都包含一週內每分鐘的測量值。在這種情況下，三分鐘後，資料列的前兩欄可能會像這樣：

資料列索引鍵 壓力 temp
asia-south2#3698#week1 94558 (t2021-03-05-1200) 9.5 (t2021-03-05-1200)
94122 (t2021-03-05-1201) 9.4 (t2021-03-05-1201)
95992 (t2021-03-05-1202) 9.2 (t2021-03-05-1202)

這個模式的用途包括：

  • 您希望能夠評估測量結果隨時間的變化。

單一時間戳記資料列

在這個模式中，您會為每個新事件或測量結果建立一列，而不是在現有資料列的資料欄中新增儲存格。資料列索引鍵後置字串是時間戳記值。遵循這種模式的資料表通常高而窄，且資料列中的每個資料欄都只有一個儲存格。

單一時間戳記序列化

在這個模式中，您會以 JSON 或通訊協定緩衝區 (protobuf) 等序列化格式，將資料列的所有資料儲存在單一資料欄中。如要進一步瞭解這個方法，請參閱「結構定義設計最佳做法」。

舉例來說，如果您使用這個模式儲存氣象氣球資料，資料表在四分鐘後可能會像這樣：

資料列索引鍵 measurements_blob
us-west2#3698#2021-03-05-1200 protobuf_1
us-west2#3698#2021-03-05-1201 protobuf_2
us-west2#3698#2021-03-05-1202 protobuf_3
us-west2#3698#2021-03-05-1203 protobuf_4

這個模式的優點包括：

  • 儲存效率

  • 速度

缺點包括：

  • 如果不使用 Bigtable 的 SQL 查詢功能來查詢 JSON 或通訊協定緩衝區，就無法在讀取資料時只擷取特定欄位，而必須讀取指定儲存格的所有資料。

  • 讀取資料後需要反序列化

這個模式的用途包括：

  • 您幾乎一律需要同時擷取特定事件的所有測量結果。

  • 您會優先考量儲存空間效率，因為您幾乎一律會同時擷取特定事件的所有測量結果。雖然您可以使用 Bigtable 的 SQL 功能在伺服器端篩選資料，但只有在不需要頻繁篩選時，這種模式才最有效益。

  • 每個事件都包含許多測量結果，如果將資料儲存在多個資料欄中，可能會超過每列 100 MB 的限制。

單一時間戳記未序列化

在這個模式中，即使只記錄一項測量結果，您也會將每個事件儲存在各自的資料列中。資料欄中的資料未序列化。

這個模式的優點包括：

  • 通常比時間值區模式更容易實作。

  • 您可能可以花較少時間精簡結構定義，再開始使用。

這種模式的缺點通常多於優點：

  • Bigtable 採用這種模式時，效能會降低。

  • 以這種方式儲存的資料，壓縮效率不如較寬資料欄中的資料。

  • 即使時間戳記位於資料列索引鍵的結尾，這種模式仍可能導致熱點。

這個模式的用途包括：

  • 您希望一律擷取所有資料欄，但只擷取指定範圍的時間戳記，但您有理由不將資料儲存在序列化結構中。

  • 您想儲存無限數量的事件。

使用氣象氣球範例資料，資料欄系列和資料欄限定詞與使用時間值區和新儲存格的範例相同。不過，在這個模式中，每個氣象氣球回報的每組測量值都會寫入「新資料列」。下表顯示使用這個模式寫入的五個資料列：

資料列索引鍵 壓力 temperature 濕度 海拔高度
us-west2#3698#2021-03-05-1200 94558 9.6 61 612
us-west2#3698#2021-03-05-1201 94122 9.7 62 611
us-west2#3698#2021-03-05-1202 95992 9.5 58 602
us-west2#3698#2021-03-05-1203 96025 9.5 66 598
us-west2#3698#2021-03-05-1204 96021 9.6 63 624

其他策略

如需針對同一個資料集傳送多個不同的查詢，建議您將資料儲存在多個資料表中，並為每個資料表設計一個資料列索引鍵，用於其中一個查詢。

在某些情況下，您也可以結合使用多種模式。舉例來說，您可以將序列化資料儲存在代表時間 bucket 的資料列中，只要資料列不會過大即可。

後續步驟