管理搜尋索引

搜尋索引是一種資料結構，可透過 SEARCH 函式進行非常有效率的搜尋。搜尋索引也能針對使用支援函式和運算子的查詢進行最佳化。

就像書本後面的索引一樣，字串資料欄的搜尋索引就像輔助資料表，其中一欄是獨一無二的字詞，另一欄則是這些字詞在資料中的位置。

建立搜尋索引

如要建立搜尋索引，請使用 CREATE SEARCH INDEX DDL 陳述式。如要指定要編入索引的基本資料類型，請參閱「建立搜尋索引並指定資料欄和資料類型」。如果未指定任何資料類型，BigQuery 預設會為包含 STRING 資料的下列類型資料欄建立索引：

  • STRING
  • ARRAY<STRING>
  • STRUCT 至少包含一個 STRING 或 ARRAY<STRING> 類型的巢狀欄位
  • JSON

建立搜尋索引時，您可以指定要使用的文字分析器類型。文字分析器會控管資料的權杖化方式，以利建立索引和搜尋。預設值為 LOG_ANALYZER。這個分析器非常適合用於機器產生的記錄，並針對可觀測性資料中常見的權杖 (例如 IP 位址或電子郵件) 制定特殊規則。如果您有預先處理的資料，且希望完全比對，請使用 NO_OP_ANALYZER。PATTERN_ANALYZER 會使用規則運算式從文字中擷取權杖。

使用預設文字分析器建立搜尋索引

在下列範例中，系統會在 simple_table 的 a 和 c 資料欄上建立搜尋索引，並預設使用 LOG_ANALYZER 文字分析器：

CREATE TABLE dataset.simple_table(a STRING, b INT64, c JSON);

CREATE SEARCH INDEX my_index
ON dataset.simple_table(a, c);

使用 NO_OP_ANALYZER 分析器在所有資料欄上建立搜尋索引

在 ALL COLUMNS 上建立搜尋索引時，系統會為資料表中的所有 STRING 或 JSON 資料建立索引。如果資料表不含這類資料 (例如所有資料欄都包含整數)，索引建立作業就會失敗。指定要建立索引的 STRUCT 資料欄時，系統會為所有巢狀子欄位建立索引。

在下列範例中，系統會在 a、c.e 和 c.f.g 上建立搜尋索引，並使用 NO_OP_ANALYZER 文字分析器：

CREATE TABLE dataset.my_table(
  a STRING,
  b INT64,
  c STRUCT <d INT64,
            e ARRAY<STRING>,
            f STRUCT<g STRING, h INT64>>) AS
SELECT 'hello' AS a, 10 AS b, (20, ['x', 'y'], ('z', 30)) AS c;

CREATE SEARCH INDEX my_index
ON dataset.my_table(ALL COLUMNS)
OPTIONS (analyzer = 'NO_OP_ANALYZER');

由於搜尋索引是在 ALL COLUMNS 建立，因此如果表格中新增的任何資料欄包含 STRING 資料，系統就會自動為這些資料欄建立索引。

建立搜尋索引，並指定資料欄和資料類型

建立搜尋索引時，您可以指定要使用的資料類型。資料類型會控管 JSON 和 STRUCT 資料欄的資料欄和子欄位類型，以供建立索引。預設的索引資料類型為 STRING。如要使用更多資料類型 (例如數值類型) 建立搜尋索引，請使用 CREATE SEARCH INDEX 陳述式，並加入 data_types 選項。

在下列範例中，系統會在名為 simple_table 的資料表上，為 a、b、c 和 d 資料欄建立搜尋索引。支援的資料欄資料類型為 STRING、INT64 和 TIMESTAMP。

CREATE TABLE dataset.simple_table(a STRING, b INT64, c JSON, d TIMESTAMP);

CREATE SEARCH INDEX my_index
ON dataset.simple_table(a, b, c, d)
OPTIONS ( data_types = ['STRING', 'INT64', 'TIMESTAMP']);

在所有資料欄上建立搜尋索引，並指定資料類型

在 ALL COLUMNS 上建立搜尋索引時，如果指定 data_types 選項，系統會為符合指定資料類型的任何資料欄建立索引。如果是 JSON 和 STRUCT 資料欄，系統會為符合指定資料類型的任何巢狀子欄位建立索引。

在下列範例中，系統會在 ALL COLUMNS 上建立搜尋索引，並指定資料型別。名為 my_table 的資料表中的資料欄 a、b、c、d.e、d.f、d.g.h、d.g.i 已建立索引：

CREATE TABLE dataset.my_table(
  a STRING,
  b INT64,
  c TIMESTAMP,
  d STRUCT <e INT64,
            f ARRAY<STRING>,
            g STRUCT<h STRING, i INT64>>)
AS (
  SELECT
    'hello' AS a,
    10 AS b,
    TIMESTAMP('2008-12-25 15:30:00 UTC') AS c,
    (20, ['x', 'y'], ('z', 30)) AS d;
)

CREATE SEARCH INDEX my_index
ON dataset.my_table(ALL COLUMNS)
OPTIONS ( data_types = ['STRING', 'INT64', 'TIMESTAMP']);

由於搜尋索引是在 ALL COLUMNS 建立，因此如果新增至表格的任何資料欄符合指定資料類型，系統就會自動為這些資料欄建立索引。

以資料欄為精細程度建立索引

建立搜尋索引時，您可以為索引資料欄指定資料欄細微程度。BigQuery 會在搜尋索引中儲存額外的資料欄資訊，藉此以資料欄精細度為基礎，最佳化特定類型的搜尋查詢。如要為已建立索引的資料欄設定資料欄細微程度，請在執行 CREATE SEARCH INDEX 陳述式時，使用 index_column_option_list 中的 index_granularity 選項。

在內部，BigQuery 資料表會整理成檔案。建立索引時，BigQuery 會建立從權杖到含有這些權杖的檔案的對應。執行搜尋查詢時，BigQuery 會掃描含有權杖的所有檔案。如果搜尋權杖很少出現在您搜尋的資料欄中，但經常出現在其他資料欄中，這種做法可能效率不彰。

舉例來說，假設您有下列包含職缺資訊的表格：

CREATE TABLE my_dataset.job_postings (job_id INT64, company_name STRING, job_description STRING);

「技能」一詞可能經常出現在 job_description 欄中，但很少出現在 company_name 欄中。假設您執行下列查詢：

SELECT * FROM my_dataset.job_postings WHERE SEARCH(company_name, 'skills');

如果您在 company_name 和 job_description 欄上建立搜尋索引，但未指定欄的精細程度，BigQuery 就會掃描 job_description 或 company_name 欄中出現「skills」一字的所有檔案。如要提升這項查詢的效能，您可以將 company_name 的資料欄細微程度設為 COLUMN：

CREATE SEARCH INDEX my_index
ON my_dataset.job_postings (
  company_name OPTIONS(index_granularity = 'COLUMN'),
  job_description);

現在執行查詢時，BigQuery 只會掃描 company_name 資料欄中出現「skills」一詞的檔案。

如要查看已編列索引的資料表資料欄設定了哪些選項，請查詢 INFORMATION_SCHEMA.SEARCH_INDEX_COLUMN_OPTIONS 檢視區塊。

以資料欄精細度建立索引的資料欄數量有限制。詳情請參閱配額與限制。

瞭解索引重新整理

搜尋索引完全由 BigQuery 管理，且會在資料表變更時自動重新整理。在下列情況中，系統可能會完整重新整理索引：

如果每個資料列中索引資料欄的資料都已更新 (例如在回填作業期間)，則需要更新整個索引，相當於完整重新整理。建議您緩慢執行回填作業 (例如依據分割區分割)，盡量減少潛在的負面影響。

如果您對主資料表進行任何結構定義變更，導致系統無法為明確建立索引的資料欄建立索引，則索引會永久停用。

如果您刪除資料表中唯一的索引資料欄，或是重新命名資料表本身，搜尋索引就會自動刪除。

搜尋索引是為大型資料表設計，如果為小於 10 GB 的資料表建立搜尋索引，系統就不會填入索引。同樣地，如果從已建立索引的資料表刪除資料，且資料表大小低於 10 GB，索引就會暫時停用。在這種情況下，搜尋查詢不會使用索引，且 IndexUnusedReason 程式碼 為 BASE_TABLE_TOO_SMALL。無論您是否使用自己的預留空間執行索引管理作業，都會發生這種情況。當索引資料表的大小超過 10 GB，系統就會自動填入索引。在搜尋索引填入資料並啟用前，系統不會收取儲存費用。即使部分資料尚未建立索引，使用 SEARCH 函式的查詢一律會傳回正確結果。

取得搜尋索引的相關資訊

您可以查詢 INFORMATION_SCHEMA，確認搜尋索引是否存在及是否已準備就緒。有三個檢視畫面包含搜尋索引的中繼資料。

INFORMATION_SCHEMA.SEARCH_INDEXES 查看範例

本節包含 INFORMATION_SCHEMA.SEARCH_INDEXES 檢視區塊的查詢範例。

以下範例會顯示專案 my_project 中，資料集 my_dataset 內資料表的所有有效搜尋索引。包括名稱、用於建立這些物件的 DDL 陳述式、涵蓋範圍百分比，以及文字分析器。如果編入索引的基礎資料表小於 10 GB，系統就不會填入索引，此時 coverage_percentage 為 0。

SELECT table_name, index_name, ddl, coverage_percentage, analyzer
FROM my_project.my_dataset.INFORMATION_SCHEMA.SEARCH_INDEXES
WHERE index_status = 'ACTIVE';

結果應如下所示：

+-------------+-------------+--------------------------------------------------------------------------------------+---------------------+----------------+
| table_name  | index_name  | ddl                                                                                  | coverage_percentage | analyzer       |
+-------------+-------------+--------------------------------------------------------------------------------------+---------------------+----------------+
| small_table | names_index | CREATE SEARCH INDEX `names_index` ON `my_project.my_dataset.small_table`(names)      | 0                   | NO_OP_ANALYZER |
| large_table | logs_index  | CREATE SEARCH INDEX `logs_index` ON `my_project.my_dataset.large_table`(ALL COLUMNS) | 100                 | LOG_ANALYZER   |
+-------------+-------------+--------------------------------------------------------------------------------------+---------------------+----------------+

INFORMATION_SCHEMA.SEARCH_INDEX_COLUMNS 查看範例

本節包含 INFORMATION_SCHEMA.SEARCH_INDEX_COLUMNS 檢視區塊的查詢範例。

以下範例會在 my_table 的所有資料欄上建立搜尋索引。

CREATE TABLE dataset.my_table(
  a STRING,
  b INT64,
  c STRUCT <d INT64,
            e ARRAY<STRING>,
            f STRUCT<g STRING, h INT64>>) AS
SELECT 'hello' AS a, 10 AS b, (20, ['x', 'y'], ('z', 30)) AS c;

CREATE SEARCH INDEX my_index
ON dataset.my_table(ALL COLUMNS);

下列查詢會擷取已建立索引的欄位資訊。 index_field_path 表示資料欄的哪個欄位已建立索引。只有在 STRUCT 的情況下，這與 index_column_name 不同，因為系統會提供已編入索引欄位的完整路徑。在這個範例中，資料欄 c 包含 ARRAY<STRING> 欄位 e 和另一個名為 STRUCT 的欄位 f，其中包含 STRING 欄位 g，每個欄位都會建立索引。

SELECT table_name, index_name, index_column_name, index_field_path
FROM my_project.dataset.INFORMATION_SCHEMA.SEARCH_INDEX_COLUMNS

結果大致如下：

+------------+------------+-------------------+------------------+
| table_name | index_name | index_column_name | index_field_path |
+------------+------------+-------------------+------------------+
| my_table   | my_index   | a                 | a                |
| my_table   | my_index   | c                 | c.e              |
| my_table   | my_index   | c                 | c.f.g            |
+------------+------------+-------------------+------------------+

下列查詢會將 INFORMATION_SCHEMA.SEARCH_INDEX_COUMNS 檢視區塊與 INFORMATION_SCHEMA.SEARCH_INDEXES 和 INFORMATION_SCHEMA.COLUMNS 檢視區塊聯結，以納入搜尋索引狀態和每個資料欄的資料類型：

SELECT
  index_columns_view.index_catalog AS project_name,
  index_columns_view.index_SCHEMA AS dataset_name,
  indexes_view.TABLE_NAME AS table_name,
  indexes_view.INDEX_NAME AS index_name,
  indexes_view.INDEX_STATUS AS status,
  index_columns_view.INDEX_COLUMN_NAME AS column_name,
  index_columns_view.INDEX_FIELD_PATH AS field_path,
  columns_view.DATA_TYPE AS data_type
FROM
  mydataset.INFORMATION_SCHEMA.SEARCH_INDEXES indexes_view
INNER JOIN
  mydataset.INFORMATION_SCHEMA.SEARCH_INDEX_COLUMNS index_columns_view
  ON
    indexes_view.TABLE_NAME = index_columns_view.TABLE_NAME
    AND indexes_view.INDEX_NAME = index_columns_view.INDEX_NAME
LEFT OUTER JOIN
  mydataset.INFORMATION_SCHEMA.COLUMNS columns_view
  ON
    indexes_view.INDEX_CATALOG = columns_view.TABLE_CATALOG
    AND indexes_view.INDEX_SCHEMA = columns_view.TABLE_SCHEMA
    AND index_columns_view.TABLE_NAME = columns_view.TABLE_NAME
    AND index_columns_view.INDEX_COLUMN_NAME = columns_view.COLUMN_NAME
ORDER BY
  project_name,
  dataset_name,
  table_name,
  column_name;

結果類似下列畫面：

+------------+------------+----------+------------+--------+-------------+------------+---------------------------------------------------------------+
| project    | dataset    | table    | index_name | status | column_name | field_path | data_type                                                     |
+------------+------------+----------+------------+--------+-------------+------------+---------------------------------------------------------------+
| my_project | my_dataset | my_table | my_index   | ACTIVE | a           | a          | STRING                                                        |
| my_project | my_dataset | my_table | my_index   | ACTIVE | c           | c.e        | STRUCT<d INT64, e ARRAY<STRING>, f STRUCT<g STRING, h INT64>> |
| my_project | my_dataset | my_table | my_index   | ACTIVE | c           | c.f.g      | STRUCT<d INT64, e ARRAY<STRING>, f STRUCT<g STRING, h INT64>> |
+------------+------------+----------+------------+--------+-------------+------------+---------------------------------------------------------------+

INFORMATION_SCHEMA.SEARCH_INDEXES_BY_ORGANIZATION 查看範例

本節包含 INFORMATION_SCHEMA.SEARCH_INDEXES_BY_ORGANIZATION 檢視區塊的查詢範例。

查看特定區域的用量是否超出上限

以下範例說明如果整個機構在美國多重區域使用共用時段，且索引基本資料表總大小超過 100 TB，會發生什麼情況：

WITH
 indexed_base_table_size AS (
 SELECT
   SUM(base_table.total_logical_bytes) AS total_logical_bytes
 FROM
   `region-us`.INFORMATION_SCHEMA.SEARCH_INDEXES_BY_ORGANIZATION AS search_index
 JOIN
   `region-us`.INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION AS base_table
 ON
   (search_index.table_name = base_table.table_name
     AND search_index.project_id = base_table.project_id
     AND search_index.index_schema = base_table.table_schema)
 WHERE
   TRUE
   -- Excludes search indexes that are permanently disabled.
   AND search_index.index_status != 'PERMANENTLY DISABLED'
   -- Excludes BASE_TABLE_TOO_SMALL search indexes whose base table size is
   -- less than 10 GB. These tables don't count toward the limit.
   AND search_index.index_status_details.throttle_status != 'BASE_TABLE_TOO_SMALL'
   -- Excludes search indexes whose project has BACKGROUND reservation purchased
   -- for search indexes.
   AND search_index.use_background_reservation = false
 -- Outputs the total indexed base table size if it exceeds 100 TB,
 -- otherwise, doesn't return any output.
)
SELECT * FROM indexed_base_table_size
WHERE total_logical_bytes >= 109951162777600 -- 100 TB

結果大致如下：

+---------------------+
| total_logical_bytes |
+---------------------+
|     109951162777601 |
+---------------------+

依區域找出專案的索引基準表總大小

以下範例提供美國多區域中每個專案的詳細資料，以及已建立索引的基本資料表總大小：

SELECT
 search_index.project_id,
 search_index.use_background_reservation,
 SUM(base_table.total_logical_bytes) AS total_logical_bytes
FROM
 `region-us`.INFORMATION_SCHEMA.SEARCH_INDEXES_BY_ORGANIZATION AS search_index
JOIN
 `region-us`.INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION AS base_table
ON
 (search_index.table_name = base_table.table_name
   AND search_index.project_id = base_table.project_id
   AND search_index.index_schema = base_table.table_schema)
WHERE
 TRUE
  -- Excludes search indexes that are permanently disabled.
  AND search_index.index_status != 'PERMANENTLY DISABLED'
  -- Excludes BASE_TABLE_TOO_SMALL search indexes whose base table size is
  -- less than 10 GB. These tables don't count toward limit.
 AND search_index.index_status_details.throttle_status != 'BASE_TABLE_TOO_SMALL'
GROUP BY search_index.project_id, search_index.use_background_reservation

結果大致如下：

+---------------------+----------------------------+---------------------+
|     project_id      | use_background_reservation | total_logical_bytes |
+---------------------+----------------------------+---------------------+
| projecta            |     true                   |     971329178274633 |
+---------------------+----------------------------+---------------------+
| projectb            |     false                  |     834638211024843 |
+---------------------+----------------------------+---------------------+
| projectc            |     false                  |     562910385625126 |
+---------------------+----------------------------+---------------------+

找出受到節流的搜尋索引

以下範例會傳回機構和區域內所有受到節流的搜尋索引：

SELECT project_id, index_schema, table_name, index_name
FROM
 `region-us`.INFORMATION_SCHEMA.SEARCH_INDEXES_BY_ORGANIZATION
WHERE
 -- Excludes search indexes that are permanently disabled.
 index_status != 'PERMANENTLY DISABLED'
 AND index_status_details.throttle_status IN ('ORGANIZATION_LIMIT_EXCEEDED', 'BASE_TABLE_TOO_LARGE')

結果大致如下：

+--------------------+--------------------+---------------+----------------+
|     project_id     |    index_schema    |  table_name   |   index_name   |
+--------------------+--------------------+---------------+----------------+
|     projecta       |     dataset_us     |   table1      |    index1      |
|     projectb       |     dataset_us     |   table1      |    index1      |
+--------------------+--------------------+---------------+----------------+

索引管理選項

如要建立索引並讓 BigQuery 維護索引，有兩種做法：

使用共用運算單元

如果您尚未將專案設定為使用專屬預留項目進行索引，系統會在免費的共用運算單元集區中處理索引管理作業，但須遵守下列限制。

如果新增至資料表的資料導致已建立索引的資料表總大小超出貴機構的限制，BigQuery 會暫停所有已建立索引的資料表索引管理作業。發生這種情況時，INFORMATION_SCHEMA.SEARCH_INDEXES 檢視區塊中的 index_status 欄位會顯示 PENDING DISABLEMENT，且系統會將索引排入刪除佇列。索引停用期間，系統仍會用於查詢，且您仍須支付索引儲存空間費用。刪除索引後，index_status 欄位會將索引顯示為 TEMPORARILY DISABLED。處於這個狀態時，查詢不會使用索引，您也不會產生索引儲存空間費用。在本例中，IndexUnusedReason 程式碼為 BASE_TABLE_TOO_LARGE。

如果您從資料表刪除資料，且索引資料表的總大小低於機構的限制，系統就會恢復所有索引資料表的索引管理作業。檢視區塊中的 index_status 欄位為 ACTIVE，查詢可以使用索引，且您需要支付索引儲存空間費用。INFORMATION_SCHEMA.SEARCH_INDEXES

您可以透過 INFORMATION_SCHEMA.SEARCH_INDEXES_BY_ORGANIZATION 檢視區塊，瞭解目前在特定區域內，各專案和資料表的用量，以及與機構上限的差距。

BigQuery 不保證共用集區的可用容量或您看到的索引總處理量。對於正式版應用程式，您可能想使用專屬時段處理索引。

使用自己的預留項目

您也可以選擇不使用預設的共用運算單元集區，改用自己的預留項目為資料表建立索引。使用自己的預留空間，可確保索引管理作業 (例如建立、重新整理和背景最佳化) 的效能穩定且可預測。

  • 在預訂中執行索引工作時，資料表大小沒有限制。
  • 使用自己的預留空間，可彈性管理索引。如要建立非常大的索引，或對已建立索引的資料表進行重大更新，可以暫時在指派作業中新增更多運算單元。

如要為專案中具有指定預留項目的資料表建立索引，請在資料表所在的區域建立預留項目。然後，使用 job_type 設為 BACKGROUND 的預訂項目指派專案：

SQL

使用 CREATE ASSIGNMENT DDL 陳述式。

  1. 前往 Google Cloud 控制台的「BigQuery」頁面。

    前往 BigQuery

  2. 在查詢編輯器中輸入下列陳述式：

    CREATE ASSIGNMENT
  `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME.ASSIGNMENT_ID`
OPTIONS (
  assignee = 'projects/PROJECT_ID',
  job_type = 'BACKGROUND');

    取代下列項目：

    • ADMIN_PROJECT_ID：擁有預留資源的管理專案專案 ID
    • LOCATION：預訂的地點
    • RESERVATION_NAME：預留項目名稱

    • ASSIGNMENT_ID：指派作業的 ID

      ID 必須是專案和位置的專屬 ID，開頭和結尾須為小寫英文字母或數字，且只能包含小寫英文字母、數字和破折號。

    • PROJECT_ID：包含要建立索引的資料表的專案 ID。這項專案已指派給預留項目。

  3. 按一下「執行」。

如要進一步瞭解如何執行查詢，請參閱「執行互動式查詢」。

bq

使用 bq mk 指令：

bq mk \
    --project_id=ADMIN_PROJECT_ID \
    --location=LOCATION \
    --reservation_assignment \
    --reservation_id=RESERVATION_NAME \
    --assignee_id=PROJECT_ID \
    --job_type=BACKGROUND \
    --assignee_type=PROJECT

更改下列內容：

  • ADMIN_PROJECT_ID：擁有預留資源的管理專案專案 ID
  • LOCATION：預訂的地點
  • RESERVATION_NAME：預訂名稱
  • PROJECT_ID：要指派給這項預留位置的專案 ID

查看索引工作

每次在單一表格上建立或更新索引時，系統都會建立新的索引工作。如要查看工作相關資訊，請查詢 INFORMATION_SCHEMA.JOBS* 檢視區塊。您可以在查詢的 WHERE 子句中設定 job_type IS NULL AND SEARCH(job_id, '`search_index`')，篩選出建立索引的工作。以下範例會列出專案 my_project 中五個最新的索引工作：

SELECT *
FROM
 region-us.INFORMATION_SCHEMA.JOBS
WHERE
  project_id  = 'my_project'
  AND job_type IS NULL
  AND SEARCH(job_id, '`search_index`')
ORDER BY
 creation_time DESC
LIMIT 5;

選擇預留大小

如要為預留項目選擇適當的運算單元數量，請考量索引管理工作執行時間、使用的運算單元數量，以及一段時間內的用量。在下列情況下，BigQuery 會觸發索引管理作業：

  • 您在資料表上建立索引。
  • 修改索引資料表中的資料。
  • 資料表結構定義變更，影響建立索引的資料欄。
  • 系統會定期最佳化或更新索引資料和中繼資料。

表格的索引管理工作所需運算單元數量取決於下列因素：

  • 資料表大小
  • 資料擷取至資料表的速率
  • 套用至資料表的 DML 陳述式比率
  • 建構及維護索引時可接受的延遲時間
  • 索引的複雜程度，通常取決於資料的屬性，例如重複字詞的數量
初步估算

以下估算值可協助您概略瞭解保留項目所需的運算單元數量。由於索引工作負載的變異性極高，因此您應在開始為資料建立索引後，重新評估需求。

  • 現有資料：如果預留 1000 個時段，BigQuery 中現有資料表的索引建立速度平均可達每秒 4 GiB，約為每天 336 TiB。
  • 新擷取的資料：新擷取的資料通常需要更多資源才能建立索引，因為資料表及其索引會經過多輪轉換最佳化。平均來說，為新擷取的資料建立索引所消耗的資源，是為相同資料進行初始回填索引的三倍。
  • 不常修改的資料：如果索引資料表幾乎沒有資料修改，持續維護索引所需的資源就會大幅減少。建議的起點是維持相同資料初始回填索引所需的運算單元數量的 1/5，且不得少於 250 個運算單元。
  • 索引編製進度大致會隨著預留項目大小而線性變化。 不過，我們不建議使用少於 250 個位置的預訂進行索引，因為這可能會導致效率不彰，進而減緩索引進度。
  • 這些預估值可能會隨著功能、最佳化和實際用量而有所不同。
  • 如果貴機構的資料表總大小超過區域的索引限制，您應為索引指派非零預留容量。否則索引可能會回復為預設層級，導致所有索引遭到意外刪除。
監控使用情況和進度

如要評估有效執行索引管理作業所需的運算單元數量，最佳做法是監控運算單元用量，並據此調整預留大小。下列查詢會產生索引管理工作的每日時段用量。只有過去 30 天的資料會納入區域 us-west1：

SELECT
  TIMESTAMP_TRUNC(job.creation_time, DAY) AS usage_date,
  -- Aggregate total_slots_ms used for index-management jobs in a day and divide
  -- by the number of milliseconds in a day. This value is most accurate for
  -- days with consistent slot usage.
  SAFE_DIVIDE(SUM(job.total_slot_ms), (1000 * 60 * 60 * 24)) AS average_daily_slot_usage
FROM
  `region-us-west1`.INFORMATION_SCHEMA.JOBS job
WHERE
  project_id = 'my_project'
  AND job_type IS NULL
  AND SEARCH(job_id, '`search_index`')
GROUP BY
  usage_date
ORDER BY
  usage_date DESC
limit 30;

如果執行索引管理工作的時段不足，索引可能會與表格失去同步，索引工作也可能會失敗。在這種情況下，BigQuery 會從頭重建索引。為避免索引不同步，請確保有足夠的時段來支援資料擷取和最佳化作業的索引更新。如要進一步瞭解如何監控時段用量，請參閱管理員資源圖表。

最佳做法

  • 搜尋索引是為大型資料表設計，表格越大，搜尋索引帶來的效能提升就越顯著。
  • 請勿為只包含極少數不重複值的資料欄建立索引。
  • 請勿為您從未打算與 SEARCH 函式或任何其他支援的函式和運算子搭配使用的資料欄建立索引。
  • 在 ALL COLUMNS 上建立搜尋索引時，請務必謹慎。每當您新增包含 STRING 或 JSON 資料的資料欄，系統就會為該資料欄建立索引。
  • 在正式版應用程式中管理索引時，請使用自己的預留空間。如果您選擇為索引管理工作使用預設共用運算單元集區，則適用機構的大小限制。

刪除搜尋索引

如果不再需要搜尋索引，或想變更資料表上建立索引的資料欄，可以刪除該資料表目前的索引。使用 DROP SEARCH INDEX DDL 陳述式。

如果刪除已建立索引的資料表，系統會自動刪除索引。

範例：

DROP SEARCH INDEX my_index ON dataset.simple_table;

後續步驟