ניהול של אינדקסים לחיפוש

אינדקס חיפוש הוא מבנה נתונים שנועד לאפשר חיפוש יעיל מאוד באמצעות הפונקציה SEARCH. אינדקס חיפוש יכול גם לבצע אופטימיזציה של חלק מהשאילתות שמשתמשות בפונקציות ובאופרטורים נתמכים.

בדומה לאינדקס שמופיע בסוף ספר, אינדקס חיפוש של עמודת נתוני מחרוזות פועל כמו טבלה משנית עם עמודה אחת למילים ייחודיות ועוד עמודה שבה מצוין איפה המילים האלה מופיעות בנתונים.

יצירת אינדקס חיפוש

כדי ליצור אינדקס חיפוש, משתמשים בהצהרת ה-DDL‏ CREATE SEARCH INDEX. כדי לציין סוגי נתונים פרימיטיביים לאינדוקס, אפשר לעיין במאמר בנושא יצירת אינדקס חיפוש וציון העמודות וסוגי הנתונים. אם לא מציינים סוגי נתונים, כברירת מחדל BigQuery יוצר אינדקס לעמודות מהסוגים הבאים שמכילות נתוני STRING:

  • STRING
  • ARRAY<STRING>
  • ‫STRUCT שמכיל לפחות שדה אחד מוטמע מסוג STRING או ARRAY<STRING>
  • JSON

כשיוצרים אינדקס חיפוש, אפשר לציין את הסוג של כלי לניתוח טקסט שבו רוצים להשתמש. הכלי לניתוח טקסט קובע איך הנתונים עוברים טוקניזציה לצורך הוספה לאינדקס וחיפוש. ערך ברירת המחדל הוא LOG_ANALYZER. הכלי הזה מתאים לניתוח יומנים שנוצרו על ידי מכונה, ויש לו כללים מיוחדים לגבי אסימונים שנפוצים בנתוני יכולת צפייה, כמו כתובות IP או כתובות אימייל. משתמשים באופרטור NO_OP_ANALYZER כשרוצים להתאים בדיוק נתונים שעברו עיבוד מראש. ‫PATTERN_ANALYZER מחלצת טוקנים מטקסט באמצעות ביטוי רגולרי.

יצירת אינדקס חיפוש עם כלי ברירת המחדל לניתוח טקסט

בדוגמה הבאה, נוצר אינדקס חיפוש בעמודות a ו-c של simple_table, ונעשה שימוש בניתוח הטקסט 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.

בדוגמה הבאה, נוצר אינדקס חיפוש בעמודות a, b, c ו-d של טבלה בשם simple_table. סוגי הנתונים הנתמכים בעמודות הם 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 עם סוגי נתונים שצוינו. העמודות a, b, c, d.e, d.f, d.g.h, d.g.i של טבלה בשם my_table מתווספות לאינדקס:

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 לבצע אופטימיזציה של סוגים מסוימים של שאילתות חיפוש על ידי אחסון של מידע נוסף על העמודות באינדקס החיפוש. כדי להגדיר את רמת הפירוט של עמודה עם אינדקס, משתמשים באפשרות index_granularity ב-index_column_option_list כשמריצים הצהרת CREATE SEARCH INDEX.

באופן פנימי, טבלאות BigQuery מאורגנות בקבצים. כשיוצרים אינדקס, BigQuery יוצר מיפוי מטוקנים לקבצים שמכילים את הטוקנים האלה. כשמריצים שאילתת חיפוש, BigQuery סורק את כל הקבצים שמכילים את הטוקנים. יכול להיות שהשיטה הזו לא יעילה אם טוקן החיפוש שלכם מופיע לעיתים רחוקות בעמודה שאתם מחפשים אבל הוא נפוץ בעמודה אחרת.

לדוגמה, נניח שיש לכם את הטבלה הבאה שמכילה מודעות דרושים:

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

המילה skills (כישורים) כנראה מופיעה הרבה בעמודה job_description, אבל מעט בעמודה company_name. נניח שמריצים את השאילתה הבאה:

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

אם יצרתם אינדקס חיפוש בעמודות company_name ו-job_description בלי לציין את רמת הגרנולריות של העמודה, מערכת BigQuery תסרוק כל קובץ שבו המילה skills מופיעה בעמודה job_description או בעמודה company_name. כדי לשפר את הביצועים של השאילתה הזו, אפשר להגדיר את רמת הפירוט של העמודה company_name ל-COLUMN:

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

עכשיו, כשמריצים את השאילתה, BigQuery סורק רק את הקבצים שבהם המילה skills מופיעה בעמודה company_name.

כדי לראות מידע על האפשרויות שהוגדרו בעמודות של טבלה עם אינדקס, מריצים שאילתה על התצוגה INFORMATION_SCHEMA.SEARCH_INDEX_COLUMN_OPTIONS.

יש מגבלות למספר העמודות שאפשר להוסיף לאינדקס ברמת פירוט של עמודה. מידע נוסף זמין במאמר מכסות ומגבלות.

הסבר על רענון האינדקס

האינדקסים של החיפוש מנוהלים באופן מלא על ידי BigQuery ומתעדכנים אוטומטית כשיש שינוי בטבלה. רענון מלא של אינדקס יכול לקרות במקרים הבאים:

אם הנתונים של עמודה עם אינדקס מתעדכנים בכל שורה, למשל במהלך פעולת מילוי חוסרים, צריך לעדכן את האינדקס כולו, כמו בעדכון מלא. מומלץ לבצע מילוי חוסרים לאט, למשל מחיצה לחיצה, כדי לצמצם את ההשפעה השלילית הפוטנציאלית.

אם מבצעים שינוי בסכימה של טבלת הבסיס שמונע את יצירת האינדקס של עמודה עם אינדקס מפורש, האינדקס מושבת באופן קבוע.

אם מוחקים את העמודה המאונדקסת היחידה בטבלה או משנים את השם של הטבלה עצמה, האינדקס של החיפוש נמחק באופן אוטומטי.

אינדקסים של חיפוש מיועדים לטבלאות גדולות. אם יוצרים אינדקס חיפוש בטבלה שגודלה קטן מ-10GB, האינדקס לא יאוכלס. באופן דומה, אם מוחקים נתונים מטבלה עם אינדקס והגודל של הטבלה יורד מתחת ל-10GB, האינדקס מושבת באופן זמני. במקרה כזה, שאילתות החיפוש לא משתמשות באינדקס והקוד IndexUnusedReason הוא BASE_TABLE_TOO_SMALL. זה קורה בין אם אתם משתמשים בהזמנה משלכם לעבודות ניהול האינדקס ובין אם לא. אם גודל הטבלה המאונדקסת עולה על 10GB, האינדקס שלה מאוכלס באופן אוטומטי. לא מחויבים על אחסון עד שמדד החיפוש מתמלא ופעיל. שאילתות שמשתמשות בפונקציה SEARCH תמיד מחזירות תוצאות נכונות, גם אם חלק מהנתונים עדיין לא עברו אינדוקס.

מידע על אינדקסים של חיפוש

כדי לוודא שאינדקס החיפוש קיים ומוכן, אפשר לשלוח שאילתה אל INFORMATION_SCHEMA. יש שלוש תצוגות שמכילות מטא-נתונים באינדקסים של החיפוש.

INFORMATION_SCHEMA.SEARCH_INDEXES דוגמאות

הקטע הזה כולל דוגמאות לשאילתות של התצוגה המפורטת INFORMATION_SCHEMA.SEARCH_INDEXES.

בדוגמה הבאה מוצגים כל אינדקסים החיפוש הפעילים בטבלאות של מערך הנתונים my_dataset, שנמצא בפרויקט my_project. הוא כולל את השמות שלהם, את הצהרות ה-DDL ששימשו ליצירתם, את אחוז הכיסוי שלהם ואת כלי הניתוח של הטקסט שלהם. אם טבלת בסיס באינדקס קטנה מ-10GB, האינדקס שלה לא יאוכלס, ובמקרה כזה הערך של 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 מציין איזה שדה בעמודה עבר אינדוקס. ההבדל בין index_column_name לבין STRUCT הוא רק במקרה של STRUCT, שבו מצוין הנתיב המלא לשדה שנוסף לאינדקס. בדוגמה הזו, עמודה 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.

איך בודקים אם הצריכה חורגת מהמגבלה באזור מסוים

הדוגמה הבאה ממחישה מה קורה אם הגודל הכולל של טבלת הבסיס עם האינדקסים בארגון, שמשתמש במשבצות משותפות באזור מרובה של ארה"ב, חורג מ-100TB:

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 משהה את ניהול האינדקסים של הטבלה הזו. במקרה כזה, בשדה index_status בתצוגה INFORMATION_SCHEMA.SEARCH_INDEXES מופיע הערך PENDING DISABLEMENT והאינדקס מתווסף לתור למחיקה. בזמן שהאינדקס ממתין להשבתה, הוא עדיין משמש בשאילתות ואתם מחויבים על אחסון האינדקס. אחרי שהאינדקס נמחק, בשדה index_status האינדקס מוצג כ-TEMPORARILY DISABLED. במצב הזה, השאילתות לא משתמשות באינדקס, ולא תחויבו על אחסון האינדקס. במקרה הזה, הקוד IndexUnusedReason הוא BASE_TABLE_TOO_LARGE.

אם מוחקים נתונים מהטבלה והגודל הכולל של הטבלאות המאונדקסות קטן מהמגבלה לכל ארגון, ניהול האינדקסים יתחדש. השדה index_status בתצוגה INFORMATION_SCHEMA.SEARCH_INDEXES הוא ACTIVE, אפשר להשתמש באינדקס בשאילתות, ויש חיוב על האחסון של האינדקס.

אפשר להשתמש בתצוגה INFORMATION_SCHEMA.SEARCH_INDEXES_BY_ORGANIZATION כדי להבין את הצריכה הנוכחית שלכם ביחס למגבלה לכל ארגון באזור מסוים, עם פירוט לפי פרויקטים וטבלאות.

‫BigQuery לא מתחייב לגבי הקיבולת הזמינה של המאגר המשותף או לגבי קצב העברת הנתונים של יצירת האינדקס שאתם רואים. באפליקציות ייצור, כדאי להשתמש במשבצות ייעודיות לעיבוד האינדקס.

שימוש בהזמנה שלכם

במקום להשתמש במאגר ברירת המחדל של משבצות משותפות, אתם יכולים להקצות משבצת משלכם כדי להוסיף את הטבלאות לאינדקס. שימוש בהזמנה משלכם מבטיח ביצועים צפויים ועקביים של משימות ניהול אינדקסים, כמו יצירה, רענון ואופטימיזציות ברקע.

  • אין הגבלות על גודל הטבלה כשמריצים עבודת אינדוקס בהזמנה.
  • שימוש בהזמנה משלכם מאפשר לכם גמישות בניהול האינדקס. אם אתם צריכים ליצור אינדקס גדול מאוד או לבצע עדכון משמעותי בטבלה עם אינדקס, אתם יכולים להוסיף זמנית עוד משבצות להקצאה.

כדי ליצור אינדקס לטבלאות בפרויקט עם הזמנה ייעודית, צריך ליצור הזמנה באזור שבו הטבלאות נמצאות. לאחר מכן, מקצים את הפרויקט להזמנה עם הערך job_type שמוגדר ל-BACKGROUND, שמשתף משאבים בין משימות אופטימיזציה ברקע:

SQL

משתמשים בהצהרת ה-DDL‏ CREATE ASSIGNMENT.

  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: מזהה הפרויקט של פרויקט הניהול שבבעלותו משאב המקום השמור
    • ‫LOCATION: המיקום של ההזמנה
    • ‫RESERVATION_NAME: השם של ההזמנה

    • ‫ASSIGNMENT_ID: מזהה ההקצאה

      המזהה צריך להיות ייחודי לפרויקט ולמיקום, להתחיל ולהסתיים באות קטנה או במספר, ולהכיל רק אותיות קטנות, מספרים ומקפים.

    • ‫PROJECT_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: מזהה הפרויקט של פרויקט הניהול שבבעלותו משאב המקום השמור
  • ‫LOCATION: המיקום של ההזמנה
  • ‫RESERVATION_NAME: השם של ההזמנה
  • ‫PROJECT_ID: המזהה של הפרויקט להקצאה להזמנה הזו

הצגת משימות האינדוקס

משימת אינדוקס חדשה נוצרת בכל פעם שנוצר או מתעדכן אינדקס בטבלה יחידה. כדי לראות מידע על המשימה, מריצים שאילתה על תצוגות INFORMATION_SCHEMA.JOBS*. אפשר לסנן משימות אינדוקס על ידי הגדרת job_type IS NULL AND SEARCH(job_id, '`search_index`') בסעיף WHERE של השאילתה. בדוגמה הבאה מוצגת רשימה של חמשת תהליכי הוספת האינדקס האחרונים בפרויקט 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 שהוחלו על הטבלה
  • העיכוב המקסימלי המותר ביצירה ובתחזוקה של האינדקס
  • מורכבות האינדקס, שנקבעת בדרך כלל לפי מאפייני הנתונים, כמו מספר המונחים הכפולים
הערכה ראשונית

ההערכות הבאות יכולות לעזור לכם להעריך כמה יחידות קיבולת נדרשות להזמנה. בגלל האופי המשתנה מאוד של עומסי העבודה של יצירת אינדקסים, כדאי להעריך מחדש את הדרישות אחרי שמתחילים ליצור אינדקסים של נתונים.

  • נתונים קיימים: בהזמנה של 1,000 משבצות, אפשר ליצור אינדקס לטבלה קיימת ב-BigQuery בקצב ממוצע של עד 4GiB לשנייה, שזה בערך 336TiB ביום.
  • נתונים חדשים שהועברו: בדרך כלל, יצירת אינדקס של נתונים חדשים שהועברו דורשת יותר משאבים, כי הטבלה והאינדקס שלה עוברים כמה סבבים של אופטימיזציות טרנספורמטיביות. בממוצע, יצירת אינדקס לנתונים חדשים שנבלעו צורכת פי שלושה יותר משאבים בהשוואה ליצירת אינדקס ראשונית של אותם נתונים.
  • נתונים שמשתנים לעיתים רחוקות: טבלאות עם אינדקס שכוללות מעט נתונים או לא כוללות נתונים בכלל, שנדרשים לשינוי, צורכות הרבה פחות משאבים לצורך תחזוקה שוטפת של האינדקס. נקודת התחלה מומלצת היא להקצות חמישית מהמשבצות שנדרשות למילוי החוזר הראשוני של אותם נתונים, ולא פחות מ-250 משבצות.
  • ההתקדמות באינדוקס משתנה באופן לינארי בערך בהתאם לגודל ההזמנה. עם זאת, לא מומלץ להשתמש בהזמנות של פחות מ-250 משבצות לאינדוקס, כי זה עלול להוביל לחוסר יעילות שיכול להאט את התקדמות האינדוקס.
  • ההערכות האלה עשויות להשתנות בהתאם לתכונות, לאופטימיזציות ולשימוש בפועל.
  • אם הגודל הכולל של הטבלה בארגון שלכם חורג ממגבלת האינדוקס באזור, אתם צריכים להקצות אינדוקס עם ערך שאינו אפס. אחרת, יכול להיות שהאינדקס יחזור לרמת ברירת המחדל, וכתוצאה מכך כל האינדקסים יימחקו שלא במכוון.
מעקב אחרי השימוש וההתקדמות

הדרך הכי טובה להעריך כמה משבצות צריך כדי להריץ ביעילות את משימות ניהול האינדקס היא לעקוב אחרי השימוש במשבצות ולהתאים את גודל ההזמנה בהתאם. השאילתה הבאה מפיקה את נתוני השימוש היומי במשבצות זמן למשימות של ניהול אינדקסים. הנתונים שמוצגים באזור us-west1 כוללים רק את 30 הימים האחרונים:

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, היא עוברת אינדוקס.
  • ביישומי ייצור, מומלץ להשתמש בהזמנה משלכם לניהול האינדקס. אם תבחרו להשתמש במאגר ברירת המחדל של משבצות שיתופיות לעבודות ניהול האינדקסים, יחולו המגבלות על גודל המאגר לכל ארגון.

מחיקת אינדקס חיפוש

אם אתם לא צריכים יותר אינדקס חיפוש או רוצים לשנות את העמודות שמתווספות לאינדקס בטבלה, אתם יכולים למחוק את האינדקס שקיים כרגע בטבלה. משתמשים בהצהרת ה-DDL‏ DROP SEARCH INDEX.

אם מוחקים טבלה עם אינדקס, האינדקס שלה נמחק אוטומטית.

דוגמה:

DROP SEARCH INDEX my_index ON dataset.simple_table;

המאמרים הבאים