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

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

איך משתמשים באינדקסים של חיפושים

אפשר ליצור אינדקס חיפוש בכל העמודות שרוצים להפוך לזמינות לחיפושים של טקסט מלא. כדי ליצור אינדקס חיפוש, משתמשים בהצהרת ה-DDL‏ CREATE SEARCH INDEX. כדי לעדכן אינדקס, משתמשים בהצהרת DDL‏ ALTER SEARCH INDEX. ‫Spanner יוצר ומעדכן את אינדקס החיפוש באופן אוטומטי, כולל הוספה ועדכון של נתונים באינדקס החיפוש ברגע שהם משתנים במסד הנתונים.

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

אפשר לחלק אינדקס חיפוש או לא לחלק אותו, בהתאם לסוג השאילתות שרוצים להאיץ.

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

  • דוגמה למצב שבו שאילתה ללא חלוקה למחיצות היא הבחירה הטובה ביותר: שאילתה בכל קטגוריות המוצרים בקטלוג מוצרים.

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

בנוסף לחיפוש טקסט מלא, אינדקסים של חיפוש ב-Spanner תומכים גם באפשרויות הבאות:

  • חיפושים ב-JSON, שהם דרך יעילה ליצור אינדקס ולשאול שאילתות במסמכי JSON ו-JSONB.
  • חיפושים של מחרוזות משנה, שהם סוג של שאילתה שמחפשת מחרוזת קצרה יותר (מחרוזת המשנה) בתוך גוף טקסט גדול יותר.
  • שילוב תנאים בכל קבוצת משנה של נתונים שנוספו לאינדקס, כולל התאמה מדויקת ומספרית, לסריקת אינדקס אחת.

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

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

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

GoogleSQL 

CREATE TABLE Albums (
  AlbumId STRING(MAX) NOT NULL,
  AlbumTitle STRING(MAX)
) PRIMARY KEY(AlbumId);

PostgreSQL 

CREATE TABLE albums (
  albumid character varying NOT NULL,
  albumtitle character varying,
PRIMARY KEY(albumid));

ל-Spanner יש כמה פונקציות ליצירת טוקנים. כדי לשנות את הטבלה הקודמת כך שהמשתמשים יוכלו להריץ חיפוש טקסט מלא כדי למצוא שמות של אלבומים, משתמשים בפונקציה TOKENIZE_FULLTEXT כדי ליצור טוקנים משמות של אלבומים. לאחר מכן יוצרים עמודה שמשתמשת בסוג הנתונים TOKENLIST כדי לאחסן את הפלט של הטוקניזציה מ-TOKENIZE_FULLTEXT. בדוגמה הזו, אנחנו יוצרים את העמודה AlbumTitle_Tokens.

GoogleSQL 

ALTER TABLE Albums
  ADD COLUMN AlbumTitle_Tokens TOKENLIST
  AS (TOKENIZE_FULLTEXT(AlbumTitle)) HIDDEN;

PostgreSQL 

ALTER TABLE albums
  ADD COLUMN albumtitle_tokens spanner.tokenlist
    GENERATED ALWAYS AS (spanner.tokenize_fulltext(albumtitle)) VIRTUAL HIDDEN;

בדוגמה הבאה נעשה שימוש ב-DDL‏ CREATE SEARCH INDEX כדי ליצור אינדקס חיפוש (AlbumsIndex) באסימונים AlbumTitle (AlbumTitle_Tokens):

GoogleSQL 

CREATE SEARCH INDEX AlbumsIndex
  ON Albums(AlbumTitle_Tokens);

PostgreSQL

בדוגמה הזו נעשה שימוש ב-CREATE SEARCH INDEX.

CREATE SEARCH INDEX albumsindex ON albums(albumtitle_tokens);

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

GoogleSQL 

SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, "fifth symphony")

PostgreSQL 

SELECT albumid
FROM albums
WHERE spanner.search(albumtitle_tokens, 'fifth symphony')

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

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

GoogleSQL 

CREATE SCHEMA AlbumSchema;
CREATE TABLE AlbumSchema.Albums (
  AlbumId STRING(MAX) NOT NULL,
  AlbumTitle STRING(MAX),
  AlbumTitle_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumTitle)) STORED HIDDEN,
) PRIMARY KEY(AlbumId);

CREATE SEARCH INDEX AlbumSchema.AlbumsIndex ON AlbumSchema.Albums(AlbumTitle_Tokens);

PostgreSQL

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

CREATE SCHEMA AlbumSchema;
CREATE TABLE AlbumSchema.albums (
  albumid character varying NOT NULL,
  albumtitle character varying,
  albumtitle_tokens spanner.tokenlist GENERATED ALWAYS AS (spanner.tokenize_fulltext(albumtitle)) STORED HIDDEN,
  PRIMARY KEY(albumid)
);
CREATE SEARCH INDEX albumsindex ON AlbumSchema.albums(albumtitle_tokens);

בדוגמאות הבאות מוצגות שאילתות לאינדקס החיפוש בסכימה שצוינה:

GoogleSQL 

SELECT AlbumId
FROM AlbumSchema.Albums
WHERE SEARCH(AlbumTitle_Tokens, "fifth symphony")

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

SELECT AlbumId
FROM AlbumSchema.Albums@{FORCE_INDEX="AlbumSchema.AlbumsIndex"}
WHERE SEARCH(AlbumTitle_Tokens, "fifth symphony")

PostgreSQL

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

SELECT albumid
FROM AlbumSchema.albums
WHERE spanner.search(albumtitle_tokens, 'fifth symphony')

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

SELECT albumid
FROM AlbumSchema.albums /*@ FORCE_INDEX = albumsindex */
WHERE spanner.search(albumtitle_tokens, 'fifth symphony')

עקביות הנתונים

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

הגדרות סכימת אינדקס החיפוש

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

  • טבלת בסיס: טבלת Spanner שצריך להוסיף לה אינדקס.
  • העמודה TOKENLIST: אוסף של עמודות שמגדירות את הטוקנים שצריך ליצור להם אינדקס. אין חשיבות לסדר העמודות.

לדוגמה, בהצהרה הבאה, טבלת הבסיס היא Albums. TOKENLIST העמודות נוצרות ב-AlbumTitle (AlbumTitle_Tokens) וב-Rating (Rating_Tokens).

GoogleSQL 

CREATE TABLE Albums (
  AlbumId STRING(MAX) NOT NULL,
  SingerId INT64 NOT NULL,
  ReleaseTimestamp INT64 NOT NULL,
  AlbumTitle STRING(MAX),
  Rating FLOAT64,
  AlbumTitle_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumTitle)) HIDDEN,
  Rating_Tokens TOKENLIST AS (TOKENIZE_NUMBER(Rating)) HIDDEN
) PRIMARY KEY(AlbumId);

PostgreSQL 

CREATE TABLE albums (
  albumid character varying NOT NULL,
  singerid bigint NOT NULL,
  releasetimestamp bigint NOT NULL,
  albumtitle character varying,
  rating double precision,
  albumtitle_tokens spanner.tokenlist GENERATED ALWAYS AS (spanner.tokenize_fulltext(albumtitle)) VIRTUAL HIDDEN,
  rating_tokens spanner.tokenlist GENERATED ALWAYS AS (spanner.tokenize_fulltext(rating)) VIRTUAL HIDDEN,
PRIMARY KEY(AlbumId));

משתמשים בהצהרה CREATE SEARCH INDEX הבאה כדי ליצור אינדקס חיפוש באמצעות הטוקנים של AlbumTitle ו-Rating:

GoogleSQL 

CREATE SEARCH INDEX AlbumsIndex
ON Albums(AlbumTitle_Tokens, Rating_Tokens)
PARTITION BY SingerId
ORDER BY ReleaseTimestamp DESC

PostgreSQL 

CREATE SEARCH INDEX albumsindex
ON albums(albumtitle_tokens, rating_tokens)
PARTITION BY singerid
ORDER BY releasetimestamp DESC

אלה האפשרויות שזמינות במדדי חיפוש:

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

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

אלמנט חשוב בייצוג הפנימי של אינדקסים של חיפושים הוא docid, שמשמש כייצוג יעיל מבחינת נפח האחסון של המפתח הראשי של טבלת הבסיס, שיכול להיות ארוך ככל שנדרש. היא גם יוצרת את הסדר של פריסת הנתונים הפנימית בהתאם לעמודות ORDER BY שסופקו על ידי המשתמש בהצהרת CREATE SEARCH INDEX. הוא מיוצג כמספר שלם אחד או שניים בני 64 ביט.

אינדקסים של חיפוש מיושמים באופן פנימי כמיפוי דו-רמתי:

  1. טוקנים למזהי מסמכים
  2. מזהי מסמכים למפתחות ראשיים של טבלת הבסיס

השיטה הזו מאפשרת חיסכון משמעותי בנפח האחסון, כי Spanner לא צריך לאחסן את המפתח הראשי המלא של טבלת הבסיס עבור כל זוג של <token, document>.

יש שני סוגים של אינדקסים פיזיים שמטמיעים את שתי רמות המיפוי:

  1. אינדקס משני שממפה מפתחות של מחיצות ומזהה מסמך למפתח הראשי של טבלת הבסיס. בדוגמה שבקטע הקודם, המיפוי הוא מ-{SingerId, ReleaseTimestamp, uid} ל-{AlbumId}. בנוסף, האינדקס המשני מאחסן את כל העמודות שצוינו בסעיף STORING של CREATE SEARCH INDEX.
  2. אינדקס של טוקנים שממפה טוקנים למסמכי docid, בדומה לאינדקסים הפוכים בספרות בנושא אחזור מידע. ‫Spanner שומר אינדקס נפרד של טוקנים לכל TOKENLIST של אינדקס החיפוש. באופן לוגי, באינדקסים של הטוקנים מתנהלות רשימות של מספרי docid לכל טוקן בכל מחיצה (שנקראות באחזור מידע רשימות של פוסטים). הרשימות מסודרות לפי אסימונים כדי לאפשר שליפה מהירה, ובתוך הרשימות, הסדר נקבע לפי docid. אינדקסים של טוקנים נפרדים הם פרט הטמעה שלא נחשף דרך ממשקי ה-API של Spanner.

‫Spanner תומך באפשרויות הבאות ל-docid.

אינדקס החיפוש מזהה מסמך התנהגות
הסעיף ORDER BY מושמט מאינדקס החיפוש {uid} מערכת Spanner מוסיפה ערך ייחודי (UID) מוסתר כדי לזהות כל שורה.
ORDER BY column {column, uid} ‫Spanner מוסיף את העמודה UID כפתרון למקרים שבהם יש שורות עם אותם ערכים של column במחיצה.

הערות שימוש:

  • העמודה של מזהה המשתמש הפנימי לא נחשפת דרך Spanner API.
  • באינדקסים שלא נוסף להם UID, טרנזקציות שמוסיפות שורה עם (מחיצה,סדר מיון) שכבר קיים נכשלות.

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

AlbumId SingerId ReleaseTimestamp SongTitle
a1 1 997 ימים יפים
a2 1 743 עיניים יפות

בהנחה שהעמודה שלפני המיון היא בסדר עולה, התוכן של אינדקס האסימון SingerId מחלק את התוכן של אינדקס האסימון באופן הבא:

SingerId ‎_token ReleaseTimestamp uid
1 יפה 743 uid1
1 יפה 997 uid2
1 ימים 743 uid1
1 עיניים 997 uid2

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

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

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

יש שני מצבי הפצה לאינדקסים של חיפוש:

  • חלוקה אחידה לשברי מסד נתונים (ברירת מחדל). בחלוקת נתונים אחידה, נתונים עם אינדקס של כל שורה בטבלת הבסיס מוקצים באופן אקראי לפיצול אינדקס של מחיצה.
  • חלוקה לשברי מידע לפי סדר מיון. בחלוקה למחיצות לפי סדר המיון, הנתונים של כל שורה בטבלת הבסיס מוקצים לפיצול אינדקס של מחיצה על סמך העמודות ORDER BY (כלומר, עמודות המיון המוקדם). לדוגמה, במקרה של סדר מיון יורד, כל השורות עם ערכי סדר המיון הגדולים ביותר מופיעות בחלוקה הראשונה של אינדקס המחיצה, והקבוצה הבאה של ערכי סדר המיון מופיעה בחלוקה הבאה.

במצבי השארדינג האלה יש איזון בין הסיכון לנקודות חמות לבין עלות השאילתה:

  • מומלץ להשתמש באינדקסים אחידים של חיפוש עם חלוקה למקטעים כשדפוסי קריאה או כתיבה באינדקס החיפוש עלולים להוביל לנקודות חמות. חלוקת נתונים אחידה מקטינה את הסיכון לשימוש בלתי מאוזן במשאבים (hotspotting) על ידי חלוקת עומס הקריאה והכתיבה באופן שווה בין הפיצולים, אבל בתמורה היא עלולה להגדיל את השימוש במשאבים במהלך ביצוע שאילתות. באינדקסים של חיפוש עם חלוקה אחידה, השאילתות צריכות לקרוא את כל הפיצולים במחיצה, בגלל הפיזור האקראי של הנתונים. כשניגשים לאינדקסים עם חלוקה אחידה, Spanner קורא את כל הפיצולים במקביל כדי להקטין את זמן האחזור הכולל של השאילתה.
  • מומלץ להשתמש באינדקסים של חיפושים עם חלוקה למקטעים לפי סדר מיון, אם סביר להניח שדפוסי קריאה או כתיבה לא יגרמו לנקודות חמות. הגישה הזו יכולה להפחית את העלות של שאילתות שבהן ORDER BY תואם ל-ORDER BY של האינדקס, ומוגדר בהן LIMIT נמוך יחסית. כשמבצעים שאילתות כאלה, Spanner קורא באופן מצטבר החל מהפיצולים הראשונים של מחיצה, והשאילתה יכולה להסתיים בלי לקרוא את כל הפיצולים אם אפשר להגיע ל-LIMIT מוקדם.

  • מגדירים את מצב הפיצול של אינדקס חיפוש באמצעות פסקה OPTIONS.

GoogleSQL 

CREATE SEARCH INDEX AlbumsIndex
ON Albums(AlbumTitle_Tokens, Rating_Tokens)
PARTITION BY SingerId
ORDER BY ReleaseTimestamp DESC
OPTIONS (sort_order_sharding = true);

PostgreSQL

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

CREATE SEARCH INDEX albumsindex
ON albums(albumtitle_tokens, rating_tokens)
PARTITION BY singerid
ORDER BY releasetimestamp DESC
WITH (sort_order_sharding = true);

אם המדיניות sort_order_sharding=false מוגדרת או לא מוגדרת, אינדקס החיפוש נוצר באמצעות חלוקה אחידה.

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

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

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

ההגבלות הבאות חלות על אינדקסים של חיפוש משולב:

  1. אפשר לשלב רק אינדקסים עם חלוקה לפי סדר מיון.
  2. אפשר לשלב אינדקסים של חיפוש רק בטבלאות ברמה העליונה (לא בטבלאות צאצא).
  3. בדומה לטבלאות משולבות ולאינדקסים משניים, צריך להגדיר את המפתח של טבלת האב כקידומת של העמודות PARTITION BY באינדקס החיפוש המשולב.

הגדרה של אינדקס חיפוש משולב

בדוגמה הבאה אפשר לראות איך מגדירים אינדקס חיפוש משולב:

GoogleSQL 

CREATE TABLE Singers (
  SingerId INT64 NOT NULL
) PRIMARY KEY(SingerId);

CREATE TABLE Albums (
  SingerId INT64 NOT NULL,
  AlbumId STRING(MAX) NOT NULL,
  AlbumTitle STRING(MAX),
  AlbumTitle_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumTitle)) HIDDEN
) PRIMARY KEY(SingerId, AlbumId),
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

CREATE SEARCH INDEX AlbumsIndex
ON Albums(AlbumTitle_Tokens)
PARTITION BY SingerId,
INTERLEAVE IN Singers
OPTIONS (sort_order_sharding = true);

PostgreSQL 

CREATE TABLE singers(
  singerid bigint NOT NULL
PRIMARY KEY(singerid));

CREATE TABLE albums(
  singerid bigint NOT NULL,
  albumid character varying NOT NULL,
  albumtitle character varying,
  albumtitle_tokens spanner.tokenlist
  GENERATED ALWAYS
AS (
  spanner.tokenize_fulltext(albumtitle)
) VIRTUAL HIDDEN,
  PRIMARY KEY(singerid, albumid)),
INTERLEAVE IN PARENT singers ON DELETE CASCADE;

CREATE
  SEARCH INDEX albumsindex
ON
  albums(albumtitle_tokens)
  PARTITION BY singerid INTERLEAVE IN singers WITH(sort_order_sharding = true);

סדר המיון של אינדקס החיפוש

הדרישות להגדרת סדר המיון של אינדקס החיפוש שונות מהדרישות של אינדקסים משניים.

לדוגמה, נניח את הטבלה הבאה:

GoogleSQL 

CREATE TABLE Albums (
  AlbumId STRING(MAX) NOT NULL,
  ReleaseTimestamp INT64 NOT NULL,
  AlbumName STRING(MAX),
  AlbumName_Token TOKENLIST AS (TOKEN(AlbumName)) HIDDEN
) PRIMARY KEY(AlbumId);

PostgreSQL 

CREATE TABLE albums (
  albumid character varying NOT NULL,
  releasetimestamp bigint NOT NULL,
  albumname character varying,
  albumname_token spanner.tokenlist
      GENERATED ALWAYS AS(spanner.token(albumname)) VIRTUAL HIDDEN,
PRIMARY KEY(albumid));

יכול להיות שהאפליקציה תגדיר אינדקס משני כדי לחפש מידע באמצעות AlbumName מיון לפי ReleaseTimestamp:

CREATE INDEX AlbumsSecondaryIndex ON Albums(AlbumName, ReleaseTimestamp DESC);

אינדקס החיפוש המקביל נראה כך (הוא משתמש בפיצול לטוקנים בהתאמה מדויקת, כי אינדקסים משניים לא תומכים בחיפושי טקסט מלא):

CREATE SEARCH INDEX AlbumsSearchIndex
ON Albums(AlbumName_Token)
ORDER BY ReleaseTimestamp DESC;

סדר המיון של אינדקס החיפוש צריך לעמוד בדרישות הבאות:

  1. אפשר להשתמש בעמודות INT64 רק כדי להגדיר את סדר המיון של אינדקס חיפוש. עמודות עם גדלים שרירותיים צורכות יותר מדי משאבים באינדקס החיפוש, כי Spanner צריך לאחסן docid לצד כל טוקן. במילים אחרות, אי אפשר להשתמש בסוג TIMESTAMP בעמודה sort_order כי TIMESTAMP משתמש בדיוק של ננו-שנייה, שלא מתאים למספר שלם של 64 ביט.

  2. העמודות של סדר המיון לא יכולות להיות NULL. יש שתי דרכים לעמוד בדרישה הזו:

    1. מגדירים את עמודת סדר המיון כ-NOT NULL.
    2. מגדירים את האינדקס כך שערכי NULL יוחרגו.

חותמת זמן משמשת לעיתים קרובות לקביעת סדר המיון. נהוג להשתמש במיקרו-שניות מאז ראשית זמן יוניקס (Unix epoch) עבור חותמות זמן כאלה.

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

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

אפשר להשתמש בתחביר WHERE column_name IS NOT NULL כדי להחריג שורות של טבלת בסיס באינדקסים של חיפוש. סינון של ערכי NULL יכול לחול על מפתחות חלוקה למחיצות, על עמודות של סדר מיון ועל עמודות מאוחסנות. אסור לסנן ערכי NULL בעמודות של מערכים מאוחסנים.

דוגמה

GoogleSQL 

CREATE SEARCH INDEX AlbumsIndex
ON Albums(AlbumTitle_Tokens)
STORING (Genre)
WHERE Genre IS NOT NULL

PostgreSQL 

CREATE SEARCH INDEX albumsindex
ON albums(albumtitle_tokens)
INCLUDE (genre)
WHERE genre IS NOT NULL

בשילוב WHERE של השאילתה צריך לציין את תנאי הסינון NULL (Genre IS NOT NULL בדוגמה הזו). אחרת, כלי האופטימיזציה של השאילתות לא יוכל להשתמש באינדקס החיפוש. מידע נוסף זמין במאמר בנושא דרישות לשאילתות SQL.

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

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