建立全域次要索引

您可以將連續具體化檢視區塊做為資料表的全域次要索引。

閱讀本頁面之前，請先熟悉持續具體化檢視區塊。

Bigtable 資料表中的資料通常會依資料列索引鍵建立索引。不過，您可以從來源資料表建立連續具體化檢視區塊，並將其做為全域次要索引。這樣一來，您就能透過查詢具體化檢視表，使用不同的查詢查閱模式擷取相同資料。

全域次要索引是連續具體化的檢視畫面，包含來源資料表的部分資料欄，以及與來源資料表中的資料列鍵不同的資料列鍵。這些資料列鍵可能基於下列轉換，讓應用程式能夠根據不同的查詢查閱模式擷取相同資料：

  • 來源資料表中的屬性，例如資料欄限定符、資料欄值或來源資料列鍵的部分。
  • 重新格式化資料列索引鍵。
  • 結合資料列鍵和屬性的轉換。

Bigtable 會以最終一致的方式，自動將全域次要索引與來源資料表同步。

使用全域次要索引的時機

應用程式經常需要使用不同的查閱模式或屬性查詢相同資料。舉例來說，假設應用程式會透過電子郵件地址或電話號碼擷取使用者資訊，您可能希望這兩種查詢模式的效能相同。如果您將電子郵件地址設為 Bigtable 列鍵，並將電話號碼儲存在資料欄中，電話號碼查詢作業的效能就會變慢，因為系統需要掃描整個表格。

如要提升依電話號碼查詢時的查詢效能，可以使用 SQL 陳述式建立持續性具體化檢視區塊。SQL 陳述式會指示 Bigtable 如何使用不同的資料列鍵重組資料。持續性具體化檢視表就像可供查詢的資料表。然後將該檢視區塊做為全域次要索引。為應用程式提供相同資料的另一個存取路徑。每個路徑都使用不同的資料列索引鍵，因此您可以為每個查詢選擇替代路徑。如要為查詢選擇最佳路徑，請瞭解每個資料表的資料列鍵結構，以及每個資料表儲存的資料。

在下列用途中，使用持續具體化檢視區塊做為全域次要索引，可提升查詢效能：

  • 重新設定資料金鑰：如要使用與來源資料表列鍵不同的金鑰查詢資料，可以建立含有替代金鑰的連續具體化檢視區塊，並針對該檢視區塊執行查詢。
  • 篩選資料：如要篩選來源資料表，並只在全域次要索引中填入特定資料列，請在定義檢視區塊的 SQL 查詢中提供 WHERE 子句。
  • 屬性鍵：如要根據非鍵屬性 (例如資料欄限定符或值) 查詢資料，可以將該屬性納入 ORDER BY 子句。

關於全域次要索引

如要在 Bigtable 中使用持續具體化檢視區塊做為全域次要索引，請考量下列需求：

  • 新全域次要索引的資料列鍵必須包含來源資料表的資料列鍵，以確保來源資料表中的資料列與連續具體化檢視的全域次要索引中的資料列之間存在一對一的對應關係。
  • 全域次要索引不必與來源資料表具有相同的結構定義或屬性。在 SQL 查詢的 SELECT 部分，您必須指定資料表中必要的資料欄，以及要套用的任何 SQL 資料轉換。
  • 全域次要索引只需要複製查詢模式所需的資料。您不必提供來源資料表中的所有來源資料。
  • 在 Bigtable 中，您選擇的資料列鍵會提供預設排序順序。

如要查詢全域次要索引，請注意下列規定：

  • ORDER BY 子句中的每個資料欄也必須包含在 SELECT 子句中。
  • 定義全域次要索引後，應用程式必須能夠選擇查詢來源資料表或具體化檢視區塊 (代表全域次要索引)。
  • 應用程式不會直接寫入索引，而是持續與來源資料表同步。一律寫入來源資料表。
  • 全域次要索引最終會保持一致性；資料會先寫入來源資料表，然後轉換為全域次要索引格式。
  • 建議您建立涵蓋索引。詳情請參閱本文件的涵蓋索引一節。
  • ORDER BY 子句必須包含來源資料表的未修改資料列鍵，且所有資料都必須依遞增順序排序。來源資料表中的資料列鍵一律會投影至具體化檢視區塊，但可以與其他屬性合併。
  • ORDER BY 子句中的資料欄會成為全域次要索引的結構化列鍵。所有其他選取的資料欄都會成為全域次要索引中的非索引鍵資料欄值。如果您將 ORDER BY 子句中的值轉換為特定 GoogleSQL for Bigtable 資料類型，該值會在全域次要索引的結構化資料列鍵中保留其資料類型。

覆蓋索引

涵蓋索引包含查詢所需的所有資料欄。查詢涵蓋索引時，Bigtable 可以直接從索引擷取所有必要資料，不必存取來源資料表。為達到最佳效能，我們建議採用這個方法，因為這樣可以盡量減少磁碟讀取次數。如要建立涵蓋索引，請確保 SELECT 陳述式指定查詢中所需的所有資料欄。

如要建立非涵蓋索引，請查詢索引，然後使用結果從來源資料表查詢所需的其他資料欄。

定義全域次要索引

如要建立全域次要索引，請建立連續 materialized view，並使用定義全域次要索引的 SQL 查詢。

在下列範例中，SQL 查詢會建立全域次要索引，讓您查詢使用者互動資料。ORDER BY 子句會使用使用者的電話號碼、使用者 ID 和電子郵件地址的組合，定義全域次要索引的結構化資料列鍵。並將 interactions 名稱指派給 activity 資料欄系列：

SELECT
  user['phone'] AS phone,
  CAST(user['id'] AS INT64) AS user_id,
  _key AS email,
  activity AS interactions
FROM CLICKS_TABLE
ORDER BY 1, 2, 3;

下表比較來源資料表中的同一列與對應的全域次要索引，說明索引的建立方式：

來源資料表列 全域次要索引列
資料列鍵：
_key：user1@example.com



屬性：
user：{id: "123", phone: "555-123-4567"}
activity：{action: "CLICKED_PRODUCT_A"}		 結構化列鍵：
phone：555-123-4567
user_id：123
email：user1@example.com

屬性：
interactions：{action: "CLICKED_PRODUCT_A"}
資料列鍵：
_key：user2@example.com



屬性：
user：{id: "456", phone: "555-987-6543"}
activity：{action: "VIEWED_PRODUCT_B"}		 結構化列鍵：
phone：555-987-6543
user_id：456
email：user2@example.com

屬性：
interactions：{action: "VIEWED_PRODUCT_B"}
資料列鍵：
_key：user3@example.com



屬性：
user：{id: "1000", phone: "555-111-2222"}
activity：{action: "ADDED_TO_CART_PRODUCT_C"}		 結構化列鍵：
phone：555-111-2222
user_id：1000
email：user3@example.com

屬性：
interactions：{action: "ADDED_TO_CART_PRODUCT_C"}

限制

  • 如要讀取輸出金鑰 (即全域次要索引鍵)，只能使用 SQL 查詢。

後續步驟