גרסאות של אופטימיזציית שאילתות ב-Spanner

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

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

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

היסטוריית הגרסאות של כלי אופטימיזציית השאילתות

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

גרסה 8: 28 באוקטובר 2024 (ברירת המחדל והגרסה העדכנית)

• סעיפי WITH נלקחים בחשבון כשבוחרים תוכניות שמבוססות על עלות.

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

• שיפור JOIN הסדר מחדש.

• שיפור הביצועים של שאילתות עם תנאי IN (...) גדולים.

• שיפור בביצועים של GROUP BY במקרים מסוימים.

• שיפורים נוספים, כולל טיפול יעיל יותר בשאילתות עם LIMIT, מפתחות זרים ובחירת אינדקס.

גרסה 7: 22 במאי 2024

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

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

• הוספנו תמיכה בבחירה של הצטרפויות גיבוב (hash joins) על סמך עלות.

גרסה 6: 11 בספטמבר 2023

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

• שיפור ההערכה של עוצמת הקבוצה ומודל העלויות.

• הופעלה אופטימיזציה מבוססת-עלות לשאילתות DML.

גרסה 5: 15 ביולי 2022

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

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

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

גרסה 4: 1 במרץ 2022

• שיפורים בבחירה של אינדקס משני.

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

• הוספנו הצטרפות גיבוב חד-מעברית, שמופעלת על ידי הרמז החדש hash_join_execution.

  רמז להצטרפות:

  GoogleSQL

  SELECT ...
  FROM (...)
  JOIN@{join_method=hash_join, hash_join_execution=one_pass} (...)
  

  PostgreSQL

  SELECT ...
  FROM (...)
  JOIN/*@ join_method=hash_join, hash_join_execution=one_pass */ (...)
  

  המצב החדש מועיל כשקלט הצד של ה-build של ה-hash join גדול. הביצועים של הצטרפות גיבוב במעבר אחד צפויים להיות טובים יותר אם רואים את הדברים הבאים בפרופיל הביצוע של השאילתה:

  • מספר ההרצות בצד השמאלי של הגיבוב גדול ממספר ההרצות של אופרטור הגיבוב.
  • גם זמן האחזור של צאצא ימני של אופרטור ה-hash join גבוה.

  כברירת מחדל (hash_join_execution=multi_pass), אם קלט הצד של ה-build של ה-hash join גדול מדי מכדי להיכנס לזיכרון, הצד של ה-build מפולח למספר אצוות, ויכול להיות שנסרוק את הצד של ה-probe מספר פעמים. במצב החדש (hash_join_execution=one_pass), פעולת hash join תגלוש לדיסק אם קלט הצד של ה-build לא נכנס לזיכרון, ותמיד תסרוק את הצד של ה-probe רק פעם אחת.

• שיפור בבחירת מספר המקשים שמשמשים להזזה.

גרסה 3: 1 באוגוסט 2021

• נוסף אלגוריתם חדש לצירוף, merge join, שמופעל באמצעות ערך חדש של רמז לשאילתה JOIN METHOD.

  רמז להצהרה:

  GoogleSQL

  @{join_method=merge_join}
  SELECT ...
  

  PostgreSQL

  /*@ join_method=merge_join */
  SELECT ...
  

  רמז להצטרפות:

  GoogleSQL

  SELECT ...
  FROM (...)
  JOIN@{join_method=merge_join} (...)
  

  PostgreSQL

  SELECT ...
  FROM (...)
  JOIN/*@ join_method=merge_join */ (...)
  

• הוספת אלגוריתם חדש לצירוף, push broadcast hash join, שמופעל באמצעות ערך חדש של רמז לשאילתה JOIN METHOD.

  רמז להצטרפות:

  GoogleSQL

  SELECT ...
  FROM (...)
  JOIN@{join_method=push_broadcast_hash_join} (...)
  

  PostgreSQL

  SELECT ...
  FROM (...)
  JOIN/*@ join_method=push_broadcast_hash_join} */ (...)
  

• הוספנו את האופרטור distributed merge union, שמופעל כברירת מחדל כשזה רלוונטי. הפעולה הזו משפרת את הביצועים של השאילתות.

• שיפור קל בביצועים של סריקה ב-GROUP BY כשאין צבירה MAX או MIN (או HAVING MAX/MAX) ברשימת ה-SELECT. לפני השינוי הזה, Spanner טען את העמודה הנוספת שלא מקובצת, גם אם היא לא נדרשה על ידי השאילתה.

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

  GoogleSQL

  CREATE TABLE myTable(
    a INT64,
    b INT64,
    c INT64,
    d INT64)
  PRIMARY KEY (a, b, c);
  

  PostgreSQL

  CREATE TABLE myTable(
    a bigint,
    b bigint,
    c bigint,
    d bigint,
    PRIMARY KEY(a, b, c)
  );
  

  לפני השינוי הזה, השאילתה הבאה הייתה טוענת את העמודה c גם אם היא לא נדרשת על ידי השאילתה.

  SELECT a, b
  FROM myTable
  GROUP BY a, b
  

• שיפור הביצועים של חלק מהשאילתות עם LIMIT כשיש אופרטור cross apply שהוצג על ידי joins והשאילתה מבקשת תוצאות ממוינות עם LIMIT. בעקבות השינוי הזה, האופטימיזציה מחילה את המיון עם המגבלה בצד הקלט של cross apply קודם.

  דוגמה:

  GoogleSQL

  SELECT a2.*
  FROM Albums@{FORCE_INDEX=_BASE_TABLE} a1
  JOIN Albums@{FORCE_INDEX=_BASE_TABLE} a2 USING(SingerId)
  ORDER BY a1.AlbumId
  LIMIT 2;
  

  PostgreSQL

  SELECT a2.*
  FROM albums/*@ force_index=_base_table */ a1
  JOIN albums/*@ force_index=_base_table */ a2 USING(singerid)
  ORDER BY a1.albumid
  LIMIT 2;
  

• משפר את הביצועים של השאילתות על ידי העברת יותר חישובים דרך JOIN.

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

  דוגמה:

  SELECT
    t.ConcertDate,
    (
      SELECT COUNT(*) FROM UNNEST(t.TicketPrices) p WHERE p > 10
    ) AS expensive_tickets,
    u.VenueName
  FROM Concerts t
  JOIN Venues u ON t.VenueId = u.VenueId
  ORDER BY expensive_tickets
  LIMIT 2;
  

גרסה 2: 1 במרץ 2020

• הוספת אופטימיזציות לבחירת אינדקס.
• שיפור הביצועים של פרדיקטים מסוג REGEXP_CONTAINS ו-LIKE בנסיבות מסוימות.
• משפר את הביצועים של סריקה בGROUP BY במצבים מסוימים.

גרסה 1: 18 ביוני 2019

• כולל הרבה אופטימיזציות מבוססות-כללים, כמו predicate pushdown, ‏ limit pushdown, ‏ redundant join ו-redundant expression removal.

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

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

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