נתוני פיצול

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

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

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

הנתון הסטטיסטי של שימוש בלתי מאוזן במשאבים (hotspot) בחלוקה (שמזוהה במערכת כ-CPU_USAGE_SCORE) הוא מדד של העומס על חלוקה שמוגבל על ידי המשאבים שזמינים בשרת. הערך הזה מוצג באחוזים. אם יותר מ-50% מהעומס על פיצול מוגבלים על ידי המשאבים הזמינים, הפיצול נחשב חם. אם 100% מהעומס בפיצול מוגבל, הפיצול נחשב כפיצול חם. פיצולים חמים כאלה עשויים גם להשפיע על זמן האחזור של הבקשות שמטופלות על ידי השרתים האלה.

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

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

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

איך ניגשים לסטטיסטיקות של פיצול תנועה חם

‫Spanner מספק את הנתונים הסטטיסטיים של פיצול פעיל בסכימה SPANNER_SYS schema. נתוני SPANNER_SYS זמינים דרך ממשקי GoogleSQL ו-PostgreSQL. אפשר לגשת לנתונים האלה בדרכים הבאות:

דף Spanner Studio של מסד נתונים במסוף Google Cloud .
הפקודה gcloud spanner databases execute-sql.
השיטה executeSql או השיטה executeStreamingSql.

ה-methods הבאות של קריאה יחידה ש-Spanner מספק לא תומכות ב-SPANNER_SYS:

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

נתונים סטטיסטיים של פיצול תנועה

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

‫SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: מציג פיצולים שפופולריים במרווחי זמן של דקה אחת.
‫SPANNER_SYS.SPLIT_STATS_TOP_10MINUTE: מציג פיצולים שמושכים תשומת לב במהלך חלק כלשהו של מרווח של 10 דקות.
‫SPANNER_SYS.SPLIT_STATS_TOP_HOUR: מציג פיצולים שהיו פופולריים במהלך חלק כלשהו של פרק זמן של שעה.

לתצוגות האלה יש את המאפיינים הבאים:

כל תצוגה מכילה נתונים של מרווחי זמן לא חופפים, בהתאם למשך שצוין בשם התצוגה.
המרווחים מבוססים על שעות:
- מרווחי זמן של דקה אחת מסתיימים בתחילת הדקה.
- מרווחי זמן של 10 דקות מסתיימים בדקה העשירית של השעה, לדוגמה, 11:10:00, 11:20:00.
- מרווחים של שעה מסתיימים בתחילת השעה.
אחרי כל מרווח זמן, Spanner אוסף נתונים מכל השרתים ואז הנתונים זמינים בתצוגות של SPANNER_SYS זמן קצר לאחר מכן. לדוגמה, בשעה 11:59:30, המרווחים האחרונים שזמינים לשאילתות SQL הם:
- דקה אחת: 11:58:00-11:58:59
- ‫10 דקות: 11:40:00-11:49:59
- שעה אחת: 10:00:00-10:59:59
מערכת Spanner מקבצת את הנתונים הסטטיסטיים לפי פיצולים.
כל שורה מכילה נתונים סטטיסטיים, כולל CPU_USAGE_SCORE אחוזים שמציינים את מידת החלוקה של הפיצול, לכל פיצול ש-Spanner מציג לגביו נתונים סטטיסטיים במהלך המרווח שצוין.
בתצוגה SPANNER_SYS.SPLIT_STATS_TOP_MINUTE מוצגים נתונים סטטיסטיים מפורטים לגבי כל דקה. התצוגה הזו מאפשרת לבצע ניפוי באגים מפורט של אירועים מהזמן האחרון.
בתצוגות SPANNER_SYS.SPLIT_STATS_TOP_10MINUTE ו-SPANNER_SYS.SPLIT_STATS_TOP_HOUR מוצגת תצוגה מצטברת במרווחי זמן של 10 דקות ושעה, בהתאמה. אפשר להשתמש בתצוגות האלה כדי לנתח מגמות או לבדוק בעיות שהתרחשו בימים או בשבועות האחרונים. מידע נוסף על צבירה זמין במאמר הצגת צבירה של אירועים.
אם Spanner לא מצליח לאחסן את כל הפיצולים הפעילים במהלך המרווח, המערכת נותנת עדיפות לפיצולים עם אחוז CPU_USAGE_SCORE הכי גבוה במהלך המרווח שצוין. אם לא מוחזרים פיצולים, זה מצביע על כך שאין פיצולים פעילים.

שמירת נתונים

הכמות המקסימלית של נתונים ש-Spanner שומר לכל תצוגה, בכל נקודת זמן, היא כדלקמן:

‫SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: מרווחי זמן שכוללים את 24 השעות האחרונות.
‫SPANNER_SYS.SPLIT_STATS_TOP_10MINUTE: מרווחי זמן שכוללים את 4 הימים האחרונים.
‫SPANNER_SYS.SPLIT_STATS_TOP_HOUR: מרווחי זמן שכוללים את 30 הימים הקודמים.

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

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

הצגת הסכימה

בטבלה הבאה מוצגת הסכימה של נתוני הפיצול הפעיל:

שם העמודה	סוג	תיאור
`INTERVAL_END`	`TIMESTAMP`	סוף מרווח הזמן שבו הפיצול היה חם או לוהט.
`SPLIT_START`	`STRING`	המפתח ההתחלתי של טווח השורות בפיצול. התג split start יכול להיות גם <begin>, שמציין את תחילת מרחב המפתחות.
`SPLIT_LIMIT`	`STRING`	מפתח ההגבלה לטווח השורות בפיצול. מפתח המגבלה יכול להיות גם <end>, שמציין את סוף מרחב המפתחות.
`CPU_USAGE_SCORE`	`INT64`	`CPU_USAGE_SCORE` אחוז הפיצולים. `CPU_USAGE_SCORE` אחוז של 50% מציין שיש פיצולים חמים או חמימים.
`AFFECTED_TABLES`	`STRING ARRAY`	הטבלאות שהשורות שלהן עשויות להיות בפיצול.
`UNSPLITTABLE_REASONS`	`STRING ARRAY`	מזהה את סוגי הנקודות החמות שפיצול מבוסס עומס לא יכול לצמצם, לרוב בגלל אנטי-דפוסים. אם מופיעה סיבה כלשהי, סביר להניח שנדרשת התערבות של המשתמש, כמו התאמות של סכימה או עומס עבודה. מערך ריק מציין שלא זוהו תנאים שלא ניתן לפצל במהלך המרווח הזה, או שהעומס הגבוה היה קצר מדי מכדי ש-Spanner יוכל לקבוע אם ניתן לפצל אותו. פרטים נוספים מופיעים במאמר בנושא סוגי `UNSPLITTABLE_REASONS`.

הערה: אפשר להשתמש בחלוקות עם אחוזים של CPU_USAGE_SCORE שקטנים מ-100% כדי לעקוב אחרי מגמות לאורך זמן. ‫Spanner משתמש בפיצול מבוסס-עומס כדי לאזן את העומס בין השרתים, ולכן יכול להיות שתראו שהפיצולים משתנים או מצטמצמים לאורך זמן. עם זאת, יכול להיות שמערכת Spanner לא תוכל לאזן את העומס בגלל דפוסים בעייתיים באפליקציה, ופיצולים פעילים עלולים להימשך ולגרום לUNSPLITTABLE_REASONS. אם אתם רואים פיצולים חמים עם סיבות שלא מאפשרות פיצול שנמשכים יותר מ-10 דקות, מומלץ לבדוק אם יש בעיות בסכימה או בעומס העבודה.

מפתחות של פיצול התחלה ומכסת פיצול

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

העמודות SPLIT_START ו-SPLIT_LIMIT מציינות את המפתחות הראשיים של פיצול חם או חם מאוד.

סכימה לדוגמה

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

GoogleSQL

CREATE TABLE Users (
  UserId INT64 NOT NULL,
  FirstName STRING(MAX),
  LastName STRING(MAX),
) PRIMARY KEY(UserId);

CREATE INDEX UsersByFirstName ON Users(FirstName DESC);

CREATE TABLE Threads (
  UserId INT64 NOT NULL,
  ThreadId INT64 NOT NULL,
  Starred BOOL,
) PRIMARY KEY(UserId, ThreadId),
  INTERLEAVE IN PARENT Users ON DELETE CASCADE;

CREATE TABLE Messages (
  UserId INT64 NOT NULL,
  ThreadId INT64 NOT NULL,
  MessageId INT64 NOT NULL,
  Subject STRING(MAX),
  Body STRING(MAX),
) PRIMARY KEY(UserId, ThreadId, MessageId),
  INTERLEAVE IN PARENT Threads ON DELETE CASCADE;

CREATE INDEX MessagesIdx ON Messages(UserId, ThreadId, Subject),
INTERLEAVE IN Threads;

PostgreSQL

CREATE TABLE users
(
   userid    BIGINT NOT NULL PRIMARY KEY,-- INT64 to BIGINT
   firstname VARCHAR(max),-- STRING(MAX) to VARCHAR(MAX)
   lastname  VARCHAR(max)
);

CREATE INDEX usersbyfirstname
  ON users(firstname DESC);

CREATE TABLE threads
  (
    userid   BIGINT NOT NULL,
    threadid BIGINT NOT NULL,
    starred  BOOLEAN, -- BOOL to BOOLEAN
    PRIMARY KEY (userid, threadid),
    CONSTRAINT fk_threads_user FOREIGN KEY (userid) REFERENCES users(userid) ON
    DELETE CASCADE -- Interleave to Foreign Key constraint
  );

CREATE TABLE messages
  (
    userid    BIGINT NOT NULL,
    threadid  BIGINT NOT NULL,
    messageid BIGINT NOT NULL PRIMARY KEY,
    subject   VARCHAR(max),
    body      VARCHAR(max),
    CONSTRAINT fk_messages_thread FOREIGN KEY (userid, threadid) REFERENCES
    threads(userid, threadid) ON DELETE CASCADE
  -- Interleave to Foreign Key constraint
  );

CREATE INDEX messagesidx ON messages(userid, threadid, subject), REFERENCES
threads(userid, threadid);

תארו לעצמכם שהמרחב של מילות המפתח נראה כך:

מפתח ראשי
`<begin>`
`Users()`
`Threads()`
`Users(2)`
`Users(3)`
`Threads(3)`
`Threads(3,"a")`
`Messages(3,"a",1)`
`Messages(3,"a",2)`
`Threads(3, "aa")`
`Users(9)`
`Users(10)`
`Threads(10)`
`UsersByFirstName("abc")`
`UsersByFirstName("abcd")`
`<end>`

דוגמה לפיצולים

בדוגמאות הבאות אפשר לראות איך נראים פיצולים.

הערכים SPLIT_START ו-SPLIT_LIMIT יכולים לציין את השורה של טבלה או אינדקס, או שהם יכולים להיות <begin> ו-<end>, שמייצגים את הגבולות של מרחב המפתחות של מסד הנתונים. יכול להיות שהתאים SPLIT_START ו-SPLIT_LIMIT יכילו גם מפתחות קטומים, שהם מפתחות שמופיעים לפני מפתח מלא כלשהו בטבלה. לדוגמה, Threads(10) היא תחילית לכל שורה של Threads שמשולבת ב-Users(10).

SPLIT_START	SPLIT_LIMIT	AFFECTED_TABLES	הסבר
`Users(3)`	`Users(10)`	`UsersByFirstName`, `Users`, `Threads`, `Messages`, `MessagesIdx`	הפיצול מתחיל בשורה עם `UserId=3` ומסתיים בשורה שלפני השורה עם `UserId = 10`. הפיצול מכיל את השורות של הטבלה `Users` ואת כל השורות של הטבלאות המשולבות שלה, מ-`UserId=3` עד 10.
`Messages(3,"a",1)`	`Threads(3,"aa")`	`Threads`, `Messages`, `MessagesIdx`	הפיצול מתחיל בשורה עם `UserId=3`, `ThreadId="a"` ו-`MessageId=1` ומסתיים בשורה שלפני השורה עם המפתח של `UserId=3` ו-`ThreadsId = "aa"`. הפיצול מכיל את כל הטבלאות בין `Messages(3,"a",1)` לבין `Threads(3,"aa")`. מכיוון שהתגים `split_start` ו-`split_limit` משולבים באותה שורה בטבלה ברמה העליונה, הפיצול מכיל את השורות המשולבות בטבלה בין ההתחלה לבין המגבלה. במאמר schemas-overview מוסבר איך טבלאות משולבות ממוקמות יחד.
`Messages(3,"a",1)`	`<end>`	`UsersByFirstName`, `Users`, `Threads`, `Messages`, `MessagesIdx`	הפיצול מתחיל בטבלת ההודעות בשורה עם המפתח `UserId=3`, `ThreadId="a"` ו-`MessageId=1`. הפיצול מכיל את כל השורות מ-`split_start` עד `<end>`, סוף מרחב המפתחות של מסד הנתונים. כל השורות בטבלאות שמופיעות אחרי `split_start`, כמו `Users(4)`, נכללות בפיצול.
`<begin>`	`Users(9)`	`UsersByFirstName`, `Users`, `Threads`, `Messages`, `MessagesIdx`	הפיצול מתחיל ב-`<begin>`, תחילת מרחב המפתחות של מסד הנתונים, ומסתיים בשורה שלפני השורה `Users` עם `UserId=9`. לכן, הפיצול כולל את כל השורות בטבלה שלפני `Users` ואת כל השורות בטבלה של `Users` שלפני `UserId=9` ואת השורות בטבלאות המשולבות שלה.
`Messages(3,"a",1)`	`Threads(10)`	`UsersByFirstName`, `Users`, `Threads`, `Messages`, `MessagesIdx`	הפיצול מתחיל בשורה `Messages(3,"a", 1)` שמשולבת ב-`Users(3)` ומסתיים בשורה שלפני `Threads(10)`. ‫`Threads(10)` הוא מפתח מפוצל קטום שהוא קידומת של כל מפתח בטבלת השרשורים שמשולב ב-`Threads(10)`.`Users(10)`
`Users()`	`<end>`	`UsersByFirstName`, `Users`, `Threads`, `Messages`, `MessagesIdx`	הפיצול מתחיל במפתח המפוצל הקטום של `Users()` שקודם לכל מפתח מלא של הטבלה `Users`. הפיצול נמשך עד סוף מרחב המפתחות האפשרי במסד הנתונים. לכן, הטבלאות שיושפעו כוללות את הטבלה `Users`, את הטבלאות והאינדקסים שלה שמשולבים בטבלאות אחרות ואת כל הטבלאות שעשויות להופיע אחרי המשתמשים.
`Threads(10)`	`UsersByFirstName("abc")`	`UsersByFirstName`, `Users`, `Threads`, `Messages`, `MessagesIdx`	הפיצול מתחיל בשורה `Threads` עם `UserId = 10` ומסתיים באינדקס `UsersByFirstName` במפתח שלפני `"abc"`.

`UNSPLITTABLE_REASONS` סוגים

אם Spanner לא מצליח לצמצם את ההשפעה של נקודה חמה באמצעות פיצול מבוסס עומס, בעמודה UNSPLITTABLE_REASONS בתצוגות SPLIT_STATS_TOP_* מפורטות אחת או יותר מהסיבות הבאות:

`HOT_ROW`

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

סיבות נפוצות:

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

אסטרטגיות לצמצום הסיכון:

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

`MOVING_HOT_SPOT`

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

סיבות נפוצות:

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

אסטרטגיות לצמצום הסיכון:

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

`LARGE_SCAN_HOT_SPOT`

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

סיבות נפוצות:

שאילתות או פעולות קריאה שמבצעות סריקות בטווח רחב של נתונים שמתבצעת אליהם גישה בתדירות גבוהה.
הצהרות DML ‏ (UPDATE, DELETE) עם פסוקיות WHERE שדורשות סריקה של טווחים.
אין אינדקסים מתאימים, ולכן מתבצעות סריקות של טבלת הבסיס.

אסטרטגיות לצמצום הסיכון:

אופטימיזציה של הצהרות SQL ‏ (SELECT, UPDATE, DELETE) כדי לצמצם את מספר השורות שנסרקות.
יוצרים אינדקסים מתאימים לתמיכה בפרדיקטים נפוצים של שאילתות ו-DML, ומצמצמים את מספר השורות שנסרקות.

`UNISOLATABLE_HOT_ROW`

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

סיבות נפוצות:

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

אסטרטגיות לצמצום הסיכון:

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

`UNSPECIFIED`

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

אסטרטגיות לצמצום הסיכון:

בודקים את עומסי העבודה, השאילתות או העסקאות של האפליקציה שניגשים לטבלאות בפיצול הפעיל (שמופיעות ב-AFFECTED_TABLES) שבהן נצפה עומס מוגבר.
כדאי להשתמש בכלים כמו Query Insights ו-Transaction Insights כדי לזהות פעולות יקרות.
כדאי להעריך את נפח העבודה ולוודא שאתם פועלים לפי השיטות המומלצות לעיצוב סכימה והשיטות המומלצות ל-SQL.
אם הבעיה נמשכת יותר מ-10 דקות למרות האופטימיזציות הקודמות, צריך לפתוח בקשת תמיכה.

צפייה בצבירת אירועים

הערכים בתצוגות SPANNER_SYS.SPLIT_STATS_TOP_10MINUTE ו-SPANNER_SYS.SPLIT_STATS_TOP_HOUR מייצגים צבירה של מרווחי זמן של דקה אחת בחלונות המתאימים:

‫CPU_USAGE_SCORE: כאן מוצג הערך המקסימלי של CPU_USAGE_SCORE שנרשם עבור הפיצול בכל מרווח של דקה אחת בתוך חלון של 10 דקות או שעה אחת.

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

הפיצול מופיע בתצוגות האלה אם הערך CPU_USAGE_SCORE שלו היה 50% ומעלה לפחות באחד ממרווחי הדקה שמרכיבים אותו.

דוגמה לצבירה

כדאי לבדוק את הפיצול מ-Users(101) עד Users(102). בטבלה הבאה מוצגות רשומות פוטנציאליות בתצוגה MINUTE במהלך תקופה של 10 דקות, מ-10:00:00 עד 10:10:00:

`INTERVAL_END`	`SPLIT_START`	`SPLIT_LIMIT`	`CPU_USAGE_SCORE`	`AFFECTED_TABLES`	`UNSPLITTABLE_REASONS`
10:01:00	משתמשים(101)	משתמשים(102)	60	[Messages,Users,Threads]	[]
10:02:00	משתמשים(101)	משתמשים(102)	95	[Messages,Users,Threads]	[HOT_ROW]
10:03:00	משתמשים(101)	משתמשים(102)	80	[Messages,Users,Threads]	[HOT_ROW]
10:04:00	משתמשים(101)	משתמשים(102)	55	[Users,Threads]	[]
10:06:00	משתמשים(101)	משתמשים(102)	70	[Users,Threads]	[LARGE_SCAN_HOT_SPOT]
10:07:00	משתמשים(101)	משתמשים(102)	65	[Users,Threads]	[LARGE_SCAN_HOT_SPOT]
10:09:00	משתמשים(101)	משתמשים(102)	52	[Users,Threads]	[]

הערך המצטבר התואם ב-10MINUTE למרווח הזמן שמסתיים בשעה 10:10:00 עבור הפיצול הזה יהיה:

`INTERVAL_END`	`SPLIT_START`	`SPLIT_LIMIT`	`CPU_USAGE_SCORE`	`AFFECTED_TABLES`	`UNSPLITTABLE_REASONS`
10:10:00	משתמשים(101)	משתמשים(102)	95	[Messages,Users,Threads]	[HOT_ROW, LARGE_SCAN_HOT_SPOT]

‫CPU_USAGE_SCORE: 95 הוא הערך המקסימלי מהעמודה CPU_USAGE_SCORE בתצוגה של דקה אחת עבור הפיצול הזה בחלון.
‫UNSPLITTABLE_REASONS: [HOT_ROW, LARGE_SCAN_HOT_SPOT] הוא איחוד של כל הסיבות הייחודיות שמופיעות בעמודה UNSPLITTABLE_REASONS בתצוגה של דקה אחת.

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

חיפוש פיצולים עם תנודות חדות

אפשר להשתמש בהצהרת ה-SQL הבאה כדי לאחזר נתונים סטטיסטיים של פיצול חם. אפשר להריץ את הצהרות ה-SQL האלה באמצעות ספריות הלקוח, Google Cloud CLI או מסוףGoogle Cloud .

SELECT
  t.interval_end,
  t.split_start,
  t.split_limit,
  t.cpu_usage_score,
  t.affected_tables,
  t.unsplittable_reasons
FROM
  SPANNER_SYS.SPLIT_STATS_TOP_DURATION AS t
WHERE
  -- Optional: Filter by a specific interval end time
  -- t.interval_end = 'INTERVAL_END_TIME'
ORDER BY
  t.interval_end DESC, t.cpu_usage_score DESC;

מחליפים את מה שכתוב בשדות הבאים:

‫DURATION: בוחרים באפשרות MINUTE,‏ 10MINUTE או HOUR, בהתאם לתקופת התצפית. לדוגמה, SPANNER_SYS.SPLIT_STATS_TOP_HOUR.
‫INTERVAL_END_TIME: מחליפים בTIMESTAMP של שעת הסיום של תקופת התצפית. לדוגמה, 2072-06-08 08:30:00Z.

פירוש תוצאות השאילתה

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

`SPLIT_START`	`SPLIT_LIMIT`	`CPU_USAGE_SCORE`	`AFFECTED_TABLES`	`UNSPLITTABLE_REASONS`
Threads(10)	Threads(10, "aa")	100	Messages,Threads	[UNISOLATABLE_HOT_ROW]
Messages(631, "abc", 1)	Messages(631, "abc", 3)	100	Messages	[HOT_ROW]
משתמשים(620)	<end>	100	הודעות,משתמשים,שרשורים	[MOVING_HOT_SPOT]
משתמשים(101)	משתמשים(102)	90	הודעות,משתמשים,שרשורים	[HOT_ROW]
משתמשים(13)	משתמשים(76)	82	הודעות,משתמשים,שרשורים	[LARGE_SCAN_HOT_SPOT]
Threads(12, "zebra")	משתמשים(14)	76	הודעות,משתמשים,שרשורים	[]

מהתוצאות האלה אפשר להסיק את הבעיות הבאות:

‫Threads(10) to Threads(10, "aa"): Hot at 100% with [UNISOLATABLE_HOT_ROW]. מפתח יחיד, קידומת של טווח מפתחות בטבלה Threads או טבלה משולבת הם חמים, ו-Spanner לא יכול לפצל את הטווח עוד יותר.
Messages(631, "abc", 1) to Messages(631, "abc", 3): Hot at 100% with [HOT_ROW]. העומס מרוכז ב-MessageId 1 ו-2 עבור המשתמש והשרשור הזה.
משתמשים(620) עד <end>: חם ב-100% עם [MOVING_HOT_SPOT]. לרוב, זה מצביע על דפוס של הוספות עם מזהי משתמשים שעולים או יורדים באופן מונוטוני, מה שגורם לכך שסוף מרחב המפתחות יהיה חם באופן קבוע.
משתמשים(101) עד משתמשים(102): חם ב-90% עם [HOT_ROW]. העומס מרוכז בשורה Users עם UserId = 101 ובצאצאים שלה.
משתמשים(13) עד משתמשים(76): פופולרי ב-82% עם [LARGE_SCAN_HOT_SPOT]. ההודעה הזו מצביעה על סריקות תכופות או יקרות בטווח הזה של מזהי משתמשים.
‫Threads(12, "zebra") to Users(14): Warm at 76% usage. לא זוהו סיבות שלא מאפשרות פיצול במרווח הזה. יכול להיות ש-Spanner עדיין יוכל לפצל את הנתונים האלה אם העומס יימשך או יגדל.

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

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

בחירת תקופת זמן לבדיקה

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

בדיקה אם יש סיבות שלא ניתן לפצל

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

אפשר לשלוח שאילתה לגבי UNSPLITTABLE_REASONS כמו בדוגמה הבאה:

SELECT
  reason,
  COUNT(*) AS occurrences
FROM
  SPANNER_SYS.SPLIT_STATS_TOP_MINUTE AS t,
  UNNEST(t.unsplittable_reasons) AS reason
WHERE
  t.cpu_usage_score >= 50
  AND ARRAY_LENGTH(t.unsplittable_reasons) > 0
  AND t.interval_end >= "2072-05-18T17:40:00Z"  -- Start of window
  AND t.interval_end <= "2072-05-18T17:50:00Z"  -- End of window
GROUP BY
  reason
ORDER BY
  occurrences DESC;

הנוכחות של UNSPLITTABLE_REASONS מצביעה על הצורך בניפוי באגים נוסף.

אפשר גם לעקוב אחרי סיבות שלא מאפשרות פיצול באמצעות Cloud Monitoring. המדד שבו צריך להשתמש הוא unsplittable_reason_count. מידע נוסף זמין במאמר בנושא מדדי Spanner.

איך מוצאים את הפילוחים עם הערך `CPU_USAGE_SCORE` הכי גבוה ואת הערך `UNSPLITTABLE_REASONS` שלהם

בדוגמה הזו, מריצים את פקודת ה-SQL הבאה כדי למצוא את טווחי השורות עם הרמה הכי גבוהה של CPU_USAGE_SCORE ואת הערכים התואמים של UNSPLITTABLE_REASONS:

GoogleSQL

SELECT t.split_start,
     t.split_limit,
     t.cpu_usage_score,
     t.affected_tables,
     t.unsplittable_reasons
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.cpu_usage_score >= 50
AND  t.interval_end = "interval_end_date_time";

במקום interval_end_date_time, מזינים את התאריך והשעה של המרווח בפורמט YYYY-MM-DDTHH:MM:SSZ. לדוגמה, 2072-05-18T17:40:00Z.

PostgreSQL

SELECT t.split_start,
     t.split_limit,
     t.cpu_usage_score,
     t.affected_tables,
     t.unsplittable_reasons
FROM   spanner_sys.split_stats_top_minute t
WHERE  t.cpu_usage_score >= 50
AND  t.interval_end = 'interval_end_date_time'::timestamptz;

במקום interval_end_date_time, מזינים את התאריך והשעה של המרווח בפורמט YYYY-MM-DDTHH:MM:SSZ. לדוגמה, 2072-05-18T17:40:00Z.

הפלט של ה-SQL הקודם הוא:

`SPLIT_START`	`SPLIT_LIMIT`	`CPU_USAGE_SCORE`	`AFFECTED_TABLES`	`UNSPLITTABLE_REASONS`
`Users(180)`	`<end>`	`85`	`Messages,Users,Threads`	`[MOVING_HOT_SPOT]`
`Users(24)`	`Users(76)`	`76`	`Messages,Users,Threads`	`[HOT_ROW, LARGE_SCAN_HOT_SPOT]`
`Threads(10)`	`UsersByFirstName("abc")`	`100`	`UsersByFirstName, Users, Threads, Messages, MessagesIdx`	`[]`

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

שיטות מומלצות לצמצום אזורים חמים

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

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

זיהוי הסיבה

אפשר להשתמש בנעילה ותובנות לגבי עסקאות כדי לחפש עסקאות עם זמן המתנה ארוך לנעילה, שבהן מפתח ההתחלה של טווח השורות נמצא בפיצול הפעיל.
אפשר להשתמש בתובנות לגבי שאילתות כדי לחפש שאילתות שקוראות מהטבלה שמכילה את הפיצול הפעיל, ושזמן האחזור שלהן גדל לאחרונה, או שיש להן יחס גבוה יותר בין זמן האחזור לבין המעבד (CPU).
כדי לחפש שאילתות שקוראות מהטבלה שמכילה את הפיצול הפעיל, ושהחביון שלהן גבוה מהצפוי, אפשר להשתמש באפשרות Oldest Active Queries (השאילתות הפעילות הכי ישנות).

כמה מקרים מיוחדים שכדאי לשים לב אליהם:

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

אופטימיזציה של עומס העבודה

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

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

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

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

איך ניגשים לסטטיסטיקות של פיצול תנועה חם

נתונים סטטיסטיים של פיצול תנועה

שמירת נתונים

הצגת הסכימה

מפתחות של פיצול התחלה ומכסת פיצול

סכימה לדוגמה

GoogleSQL

PostgreSQL

דוגמה לפיצולים

UNSPLITTABLE_REASONS סוגים

HOT_ROW

MOVING_HOT_SPOT

LARGE_SCAN_HOT_SPOT

UNISOLATABLE_HOT_ROW

UNSPECIFIED

צפייה בצבירת אירועים

דוגמה לצבירה

חיפוש פיצולים עם תנודות חדות

פירוש תוצאות השאילתה

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

בחירת תקופת זמן לבדיקה

בדיקה אם יש סיבות שלא ניתן לפצל

איך מוצאים את הפילוחים עם הערך CPU_USAGE_SCORE הכי גבוה ואת הערך UNSPLITTABLE_REASONS שלהם

GoogleSQL

PostgreSQL

שיטות מומלצות לצמצום אזורים חמים

זיהוי הסיבה

אופטימיזציה של עומס העבודה

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

נתוני פיצול

`UNSPLITTABLE_REASONS` סוגים

`HOT_ROW`

`MOVING_HOT_SPOT`

`LARGE_SCAN_HOT_SPOT`

`UNISOLATABLE_HOT_ROW`

`UNSPECIFIED`

איך מוצאים את הפילוחים עם הערך `CPU_USAGE_SCORE` הכי גבוה ואת הערך `UNSPLITTABLE_REASONS` שלהם