垃圾收集總覽

本頁面說明垃圾收集在 Bigtable 中的運作方式，並涵蓋下列主題：

  • 垃圾收集類型
  • 預設垃圾收集設定
  • 刪除資料時
  • 備用資料表垃圾收集政策的變更

垃圾收集總覽

垃圾收集是持續進行的自動流程，可從 Bigtable 資料表移除過期與過時資料。垃圾收集政策是您建立的一組規則，指出何時不再需要特定資料欄系列中的資料。

垃圾收集是內建非同步背景程序。實際刪除符合垃圾收集條件的資料可能需要一週的時間。垃圾收集會以固定排程進行，不會因需要刪除的資料量而有所不同。資料在刪除之前會顯示在讀取結果中。您可以篩選讀取來排除此資料。

垃圾收集政策的優點包括：

  • 將資料列大小降到最低 - 您總是希望防止資料列無限成長。大型資料列會對效能造成負面影響。在理想情況下，絕對不能讓資料列的大小超過 100 MB，且限制為 256 MB。如果您不需要保留舊資料，或目前資料的舊版本，使用垃圾收集可協助您將每個資料列的大小降到最低。
  • 降低成本 - 垃圾收集可確保您不需要為了儲存不再需要或不再使用的資料而付費。在進行壓縮並刪除符合垃圾收集條件的資料之前，系統會向您收取儲存過期或過時資料的費用。一般來說，這項程序需要幾天的時間，但可能最多需要一週的時間才能完成。

您可以透過程式或使用 cbt CLI 來設定垃圾收集政策。垃圾收集政策是在資料欄系列層級設定。

資料表中的每個資料欄系列都有自己的垃圾收集政策。垃圾收集程序會針對每個資料欄系列查詢目前的垃圾收集政策，然後根據政策中的規則刪除資料。

時間戳記

在 Bigtable 中，資料列與資料欄的交集可以有多個儲存格，這些儲存格包含該交集的值版本 (附有時間戳記)。每個儲存格都有時間戳記。時間戳記是指自 Unix 紀元 (1970-01-01 00:00:00 UTC) 起算，以微秒為單位的時間。您可以採用預設時間戳記，也可以在傳送寫入要求時設定時間戳記。

傳送至 Bigtable 的時間戳記必須是微秒值，精確的位數只到毫秒。精確度達微秒的時間戳記 (例如 3023483279876543) 會遭到拒絕。在本範例中，可接受的時間戳記值為 3023483279876000。

儲存格的時間戳記屬性可以是「實際」時間戳記，反映寫入儲存格的實際時間值，也可以是「人工」時間戳記。人工時間戳記包含序號、零或時間戳記格式的值 (並非寫入儲存格的實際時間)。使用人工時間戳記之前，請查看人工時間戳記的使用案例，包括使用風險：

傳送寫入要求時，請務必設定預設時間戳記，除非您需要支援使用人工時間戳記的用途。

垃圾收集類型

本節說明 Bigtable 中提供的垃圾收集類型。設定垃圾收集一文中提供每種垃圾收集類型的程式碼範例。

到期值 (以時間為基礎)

您可以根據每個儲存格的時間戳記設定垃圾收集規則。例如，您可能並不想保留時間戳記在目前日期與時間前 30 天以上的任何儲存格。若使用此類型的垃圾收集規則，您就可以設定資料的存留時間 (TTL)。Bigtable 會在垃圾收集期間查看每個資料欄系列，並刪除已過期的任何儲存格。

版本數量

您可以設定垃圾收集規則，明確指出針對資料欄系列中的所有資料欄要保留的儲存格數上限。

舉例來說，如果您只想保留客戶的最新使用者名稱與電子郵件地址，可建立包含這兩個資料欄的資料欄系列，並針對該資料欄系列，將值數上限設定為 1。

在另一種情況下，您可能想要保留使用者密碼雜湊的最近五個版本，以確保使用者未重複使用密碼，因此，您應將包含密碼資料欄之資料欄系列的版本數上限設定為 5。當 Bigtable 在垃圾收集期間查看資料欄系列時，如果第六個儲存格已寫入密碼資料欄，系統會刪除最舊的儲存格，以保持儲存格數量為五個。

有效期限規則與版本號碼規則的組合

您可以結合有效期限和版本號碼規則，進行垃圾收集。組合類型包括交集、聯集和巢狀。如需設定範例，請參閱「根據多項條件進行垃圾收集」。

十字路口

如果資料符合指定規則集中的所有條件，交集垃圾收集政策就會將資料標示為待刪除。例如，您可能想刪除超過 30 天的設定檔，但始終為每位使用者保留至少一個設定檔。在這種情況下，針對包含設定檔資料欄的資料欄系列，交集政策應包含到期值的規則與版本數量的規則。

Union

如果資料符合指定規則集中的任何項目，聯集垃圾收集政策就會將資料標示為待刪除。例如，您可能想確保針對每位使用者保留最多兩個網頁瀏覽記錄，但前提是這些記錄的使用時間少於 30 天。在這種情況下，應針對到期值或版本數量設定聯集政策。

巢狀

巢狀垃圾收集政策結合了聯集和交集規則。

垃圾收集的預設設定

資料欄系列沒有預設存留時間。資料欄保留的儲存格數量取決於您建立資料欄所在之資料欄系列的方式，如下列幾節所述。

HBase 政策

如果您使用 Java 適用的 HBase 用戶端、HBase shell 或使用 Java 適用之 HBase 用戶端的其他工具建立資料欄系列，除非您變更規則，否則 Bigtable 只會保留資料欄系列中每個資料欄的最新儲存格。此預設設定與 HBase 一致。

其他所有用戶端程式庫或工具

如果您使用其他任何用戶端程式庫或工具建立資料欄系列，Bigtable 會保留資料欄系列中每個資料欄的無限量儲存格。這包括使用 gcloud 和 cbt CLI 建立的資料欄系列。如要限制版本數量，必須變更資料欄系列的垃圾收集政策。

刪除資料時

垃圾收集是一個持續的過程，Bigtable 會檢查每個資料欄系列的規則，並會相應地刪除過期與過時資料。一般而言，從資料符合資料規則中的條件到實際刪除資料可能需要最多一週的時間。您無法變更垃圾收集的時間。

由於刪除過期資料可能需要最多一週的時間，因此，您不應僅依賴垃圾收集政策來確保讀取要求傳回所需資料。請一律將篩選器套用至讀取要求，該篩選器會排除與垃圾收集規則相同的值。您可以透過限制每個資料欄的儲存格數，或指定時間戳記範圍來進行篩選。

舉例來說，假設資料欄系列的垃圾收集規則設定為僅保留設定檔的五個最新版本，且已經儲存了五個版本。寫入設定檔的新版本之後，可能需要最多一週的時間來刪除最舊的儲存格。因此，為了避免讀取第六個值，您應一律篩選除五個最新版本以外的所有版本。

在進行壓縮並刪除資料之前，系統會向您收取儲存過期資料的費用。

垃圾收集具有追溯性：當設定新垃圾收集政策時，在接下來的幾天內，該政策將套用至資料表中的所有資料。如果新政策的限制比之前的政策更加嚴格，舊資料將在背景工作發生時刪除，包括政策變更之前寫入的資料。

如要確保系統會刪除標示為垃圾收集的資料，可以查詢資料表，並將資料與預期結果進行比較。您也可以在 Google Cloud 控制台中監控資料表大小。永遠沒有變小的資料表可能反映出垃圾收集政策沒有如預期運作，但請記住，垃圾收集會延遲執行。

複製和垃圾收集

複製會以幾種方式影響垃圾收集作業。

根據版本進行垃圾收集和 CPU 使用率

在使用複製功能的執行個體中，系統會將以版本為準的垃圾收集作業刪除的資料，複製到執行個體中的所有叢集，複製方式與複製應用程式要求相同。如果您快速寫入新儲存格，導致舊儲存格標示為待刪除，Bigtable 刪除過時儲存格並將刪除作業複製到執行個體中的其他叢集時，CPU 使用率可能會提高。如果將叢集新增至含有使用版本式垃圾收集的資料表執行個體，請準備好因應 CPU 使用率的增加。

另一方面，以時間為基礎的垃圾收集不會增加複製執行個體的 CPU 用量。

變更以版本為準的垃圾收集政策

您可以修改複製資料表中資料欄系列的版本數上限。但是，如果您降低資料欄系列的版本數，所有複製叢集可能需要最多一週的時間，才能反映新的較低數值。因此，讀取資料時應一律使用篩選器。

變更以存在時間為準的垃圾收集政策

無論執行個體是否使用複寫功能，您都可以增加或減少垃圾收集政策中指定的保留時間。您也可以刪除以存在時間為準的垃圾收集政策。

縮短保留時間

如果您在以年齡為準的政策中縮短保留時間，所有叢集最多可能需要一週的時間，才能同步處理並採用新政策。

延長保留時間

在複寫資料表中，您最多可將垃圾收集政策的保留時間延長 90 天。

如果您延長資料欄系列的保留期限，叢集可能會超過一週無法同步。如要瞭解原因，請考慮以下假設情況：您在雙叢集執行個體中建立資料表，並將資料欄系列的保留期限從 30 天變更為 50 天：

  1. 系統會將資料列鍵 ip#685 的寫入要求傳送至叢集 A，並為資料欄系列 profile 中的資料欄 click-through 提供 2023-01-02 值。資料會複製到叢集 B。
  2. 31 天後，叢集 A 會進行垃圾收集，並將 click-through 欄中的值視為過期並刪除。
  3. 您變更資料欄系列 profile 的垃圾收集政策，將存留時間從 30 天增加到 50 天。
  4. 一天後，垃圾收集作業在叢集 B 上執行。由於 TTL 為 50 天，因此系統會保留 2023-01-02 值。
  5. 叢集現在已不同步，且會持續不同步近 20 天，直到系統最終刪除叢集 B 中有但叢集 A 中沒有的值為止。

後續步驟