נתונים סטטיסטיים של עסקאות

במסמך הזה מתוארים הנתונים הסטטיסטיים של העסקאות ש-Spanner מציע כטבלאות מובנות. אפשר לאחזר נתונים סטטיסטיים מהטבלאות SPANNER_SYS.TXN_STATS* האלה באמצעות הצהרות SQL.

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

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

איך ניגשים לסטטיסטיקות של עסקאות

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

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

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

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

נתונים סטטיסטיים של זמן ההמתנה לתגובה מקובצים לפי עסקה

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

‫SPANNER_SYS.TXN_STATS_TOP_MINUTE: נתונים סטטיסטיים של טרנזקציות שמצטברים במרווחי זמן של דקה.
‫SPANNER_SYS.TXN_STATS_TOP_10MINUTE: נתונים סטטיסטיים של טרנזקציות שמצטברים במרווחי זמן של 10 דקות.
‫SPANNER_SYS.TXN_STATS_TOP_HOUR: נתונים סטטיסטיים של טרנזקציות שמצטברים במרווחי זמן של שעה.

הטבלאות האלה כוללות את המאפיינים הבאים:

כל טבלה מכילה נתונים של מרווחי זמן לא חופפים, למשך הזמן שצוין בשם הטבלה.
המרווחים מבוססים על שעות
- מרווחי זמן של דקה אחת מסתיימים בדיוק בדקה.
- מרווחים של 10 דקות מסתיימים כל 10 דקות החל מתחילת השעה.
- מרווחים של שעה מסתיימים בשעה עגולה.
לדוגמה, בשעה 11:59:30, המרווחים האחרונים שזמינים לשאילתות SQL הם:
- דקה אחת: 11:58:00–11:58:59
- 10 דקות: 11:40:00–11:49:59
- שעה אחת: 10:00:00–10:59:59 AM
‫Spanner מקבץ את הנתונים הסטטיסטיים לפי FPRINT (טביעת אצבע) של העסקאות. אם קיים תג עסקה, FPRINT הוא הגיבוב של התג. אחרת, זהו הגיבוב שמחושב על סמך הפעולות שקשורות לעסקה.
מכיוון שהנתונים הסטטיסטיים מקובצים לפי FPRINT, אם אותה עסקה מבוצעת מספר פעמים בפרק זמן כלשהו, בטבלאות האלה תופיע רק רשומה אחת של העסקה הזו.
כל שורה מכילה נתונים סטטיסטיים לגבי כל ההרצות של טרנזקציה מסוימת ש-Spanner אוסף לגביה נתונים סטטיסטיים במהלך המרווח שצוין.
אם Spanner לא מצליח לאחסן נתונים סטטיסטיים של כל הטרנזקציות שמתבצעות במהלך המרווח בטבלאות האלה, המערכת נותנת עדיפות לטרנזקציות עם זמן האחזור הגבוה ביותר, ניסיונות הביצוע ומספר הבייטים שנכתבו במהלך המרווח שצוין.
כל העמודות בטבלאות הן nullable.

סכמת טבלאות

שם העמודה	סוג	תיאור
`INTERVAL_END`	`TIMESTAMP`	סוף מרווח הזמן שבו התרחשו הביצועים של העסקאות שנכללות.
`TRANSACTION_TAG`	`STRING`	תג העסקה האופציונלי של פעולת העסקה הזו. מידע נוסף על השימוש בתגים זמין במאמר פתרון בעיות באמצעות תגי טרנזקציות. נתונים סטטיסטיים של כמה עסקאות עם אותו מחרוזת תגים מקובצים בשורה אחת עם הערך `TRANSACTION_TAG` שתואם למחרוזת התגים הזו.
`FPRINT`	`INT64`	הגיבוב (hash) של `TRANSACTION_TAG` אם הוא קיים. אחרת, הגיבוב מחושב על סמך הפעולות שקשורות לעסקה. השילוב של `INTERVAL_END` ו-`FPRINT` משמש כמפתח ייחודי לטבלאות האלה.
`READ_COLUMNS`	`ARRAY<STRING>`	קבוצת העמודות שנקראו על ידי הטרנזקציה.
`WRITE_CONSTRUCTIVE_COLUMNS`	`ARRAY<STRING>`	קבוצת העמודות שנכתבו באופן קונסטרוקטיבי, כלומר הוקצו להן ערכים חדשים, על ידי העסקה. בסנכרון שינויים בזרמי נתונים, אם העסקה כללה כתיבה לעמודות ולטבלאות שנמצאות במעקב על ידי סנכרון שינויים בזרמי נתונים, `WRITE_CONSTRUCTIVE_COLUMNS` מכיל שתי עמודות – `.data` ו-`._exists` , עם קידומת של שם סנכרון שינויים בזרמי נתונים. ‫`_exists` הוא שדה שמשמש לבדיקה אם שורה מסוימת קיימת או לא.
`WRITE_DELETE_TABLES`	`ARRAY<STRING>`	קבוצת הטבלאות שהשורות שלהן נמחקו או הוחלפו על ידי הטרנזקציה.
`ATTEMPT_COUNT`	`INT64`	המספר הכולל של הניסיונות לביצוע העסקה, כולל הניסיונות שבוטלו לפני הקריאה ל-commit.
`COMMIT_ATTEMPT_COUNT`	`INT64`	המספר הכולל של ניסיונות לאישור עסקאות. המספר הזה צריך להיות זהה למספר השיחות לשיטת `commit` של העסקה.
`COMMIT_ABORT_COUNT`	`INT64`	המספר הכולל של ניסיונות לביצוע עסקאות שבוטלו, כולל ניסיונות שבוטלו לפני הקריאה לשיטת `commit` של העסקה.
`COMMIT_RETRY_COUNT`	`INT64`	המספר הכולל של ניסיונות חוזרים מניסיונות שבוטלו קודם. יכול להיות שיהיו כמה ניסיונות לבצע טרנזקציה ב-Spanner לפני שהיא תאושר, בגלל מחלוקות על נעילה או אירועים זמניים. מספר גבוה של ניסיונות חוזרים ביחס למספר הניסיונות לביצוע פעולות מצביע על כך שיכול להיות שיש בעיות שכדאי לבדוק. מידע נוסף זמין בקטע הסבר על עסקאות ומספרים של פעולות Commit שבדף הזה.
`COMMIT_FAILED_PRECONDITION_COUNT`	`INT64`	המספר הכולל של ניסיונות לאישור עסקאות שהחזירו שגיאות של תנאי קדם שנכשלו, כמו `UNIQUE` הפרות של אינדקסים, שורה שכבר קיימת או שורה שלא נמצאה.
`SERIALIZABLE_PESSIMISTIC_TXN_COUNT`	`INT64`	המספר הכולל של ניסיונות העסקה שהופעלו עם רמת הבידוד `SERIALIZABLE` ונעילת `PESSIMISTIC`. היא תת-קבוצה של `ATTEMPT_COUNT`.
`REPEATABLE_READ_OPTIMISTIC_TXN_COUNT`	`INT64`	המספר הכולל של ניסיונות העסקה שהופעלו עם רמת הבידוד `REPEATABLE READ` ונעילת `OPTIMISTIC`. היא תת-קבוצה של `ATTEMPT_COUNT`.
`AVG_PARTICIPANTS`	`FLOAT64`	המספר הממוצע של משתתפים בכל ניסיון לביצוע פעולת Commit. מידע נוסף על משתתפים זמין במאמר מחזור החיים של פעולות קריאה וכתיבה ב-Spanner.
`AVG_TOTAL_LATENCY_SECONDS`	`FLOAT64`	מספר השניות הממוצע שחלף מהפעולה הראשונה בעסקה ועד לאישור או לביטול שלה.
`AVG_COMMIT_LATENCY_SECONDS`	`FLOAT64`	מספר השניות הממוצע שנדרש לביצוע פעולת השמירה.
`AVG_BYTES`	`FLOAT64`	מספר הבייטים הממוצע שנכתב על ידי העסקה.
`TOTAL_LATENCY_DISTRIBUTION`	`ARRAY<STRUCT>`	היסטוגרמה של זמן האחזור הכולל של ביצוע פעולת ה-commit, שהוא הזמן שחל מתחילת הפעולה הראשונה של העסקה ועד לביצוע ה-commit או לביטול העסקה, עבור כל הניסיונות של העסקה. הערה לגבי ממשק PostgreSQL: מסדי נתונים בניב PostgreSQL לא תומכים בעמודה הזו. במקום זאת, משתמשים בעמודה `TOTAL_LATENCY_DISTRIBUTION_JSON_STRING` במסדי נתונים של ניב PostgreSQL. אם עסקה מבוטלת כמה פעמים ואז מתבצעת בהצלחה, זמן האחזור נמדד לכל ניסיון עד לביצוע הסופי. הערכים נמדדים בשניות. המערך מכיל רכיב יחיד והוא מהסוג הבא: `ARRAY<STRUCT< COUNT INT64, MEAN FLOAT64, SUM_OF_SQUARED_DEVIATION FLOAT64, NUM_FINITE_BUCKETS INT64, GROWTH_FACTOR FLOAT64, SCALE FLOAT64, BUCKET_COUNTS ARRAY<INT64>>>` מידע נוסף על הערכים מופיע במאמרים התפלגות ואקספוננציאלי. כדי לחשב את חביון האחוזון מההתפלגות, משתמשים בפונקציה `SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64)`, שמחזירה את האחוזון המשוער n. דוגמה קשורה מופיעה במאמר איך מוצאים את חביון האחוזון ה-99 של עסקאות. מידע נוסף זמין במאמר אחוזונים ומדדים של ערכי התפלגות.
`OPERATIONS_BY_TABLE`	`ARRAY<STRUCT>`	ההשפעה של פעולות `INSERT` או `UPDATE` לפי טבלה. הנתונים האלה מוצגים במספר הפעמים שהשורות מושפעות ובמספר הבייטים שנכתבים. הערה לגבי ממשק PostgreSQL: מסדי נתונים בניב PostgreSQL לא תומכים בעמודה הזו. במקום זאת, משתמשים בעמודה `OPERATIONS_BY_TABLE_JSON_STRING` במסדי נתונים של ניב PostgreSQL. העמודה הזו עוזרת להמחיש את העומס על הטבלאות ומספקת תובנות לגבי הקצב שבו טרנזקציה כותבת לטבלאות. מציינים את המערך באופן הבא: `ARRAY<STRUCT< TABLE STRING(MAX), INSERT_OR_UPDATE_COUNT INT64, INSERT_OR_UPDATE_BYTES INT64>>`
`TOTAL_LATENCY_DISTRIBUTION_JSON_STRING`	`STRING`	היסטוגרמה של זמן האחזור הכולל של ביצוע פעולת ה-commit, שהוא הזמן שחל מתחילת הפעולה הראשונה של העסקה ועד לביצוע ה-commit או לביטול העסקה, עבור כל הניסיונות של העסקה. ייצוג מחרוזת תואמת JSON של נתון הסטטיסטיקה `TOTAL_LATENCY_DISTRIBUTION`. מחרוזת ה-JSON היא אובייקט JSON עם אותו מבנה כמו STRUCT שמוגדר ב-`TOTAL_LATENCY_DISTRIBUTION`. אם עסקה מבוטלת כמה פעמים ואז מתבצעת בהצלחה, זמן האחזור נמדד לכל ניסיון עד לביצוע הסופי. הערכים נמדדים בשניות. העמודה הזו נתמכת במסדי נתונים של GoogleSQL-dialect ו-PostgreSQL-dialect. בעמודה הזו מופיע הפיזור. כדי לחשב את חביון האחוזון מההתפלגות, משתמשים בפונקציה `SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64)`, שמחזירה את האחוזון המשוער n. דוגמה קשורה: חיפוש ערך האחוזון ה-99 של זמן האחזור של עסקאות באמצעות העמודה `TOTAL_LATENCY_DISTRIBUTION_JSON_STRING`. מידע נוסף זמין במאמר אחוזונים ומדדים של ערכי התפלגות.
`OPERATIONS_BY_TABLE_JSON_STRING`	`STRING`	ההשפעה של פעולות `INSERT` או `UPDATE` לפי טבלה. הנתונים האלה מוצגים במספר הפעמים שהשורות מושפעות ובמספר הבייטים שנכתבים. ייצוג מחרוזת תואמת ל-JSON של העמודה `OPERATIONS_BY_TABLE`. מחרוזת ה-JSON היא אובייקט JSON עם אותו מבנה כמו STRUCT שמוגדר בעמודה `OPERATIONS_BY_TABLE`. העמודה הזו נתמכת במסדי נתונים של GoogleSQL-dialect ו-PostgreSQL-dialect. העמודה הזו עוזרת להמחיש את העומס על הטבלאות ומספקת תובנות לגבי הקצב שבו טרנזקציה כותבת לטבלאות.

שאילתות לדוגמה

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

הצגת הנתונים הסטטיסטיים הבסיסיים של כל עסקה בתקופה נתונה

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

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds,
       avg_commit_latency_seconds,
       operations_by_table,
       avg_bytes
FROM spanner_sys.txn_stats_top_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_top_minute);

פלט השאילתה

fprint	read_columns	write_constructive_columns	write_delete_tables	avg_total_latency_seconds	avg_commit_latency_seconds	operations_by_table	avg_bytes
`40015598317`	`[]`	`["Routes.name", "Cars.model"]`	`["Users"]`	`0.006578737`	`0.006547737`	`[["Cars",1107,30996],["Routes",560,26880]]`	`25286`
`20524969030`	`["id", "no"]`	`[]`	`[]`	`0.001732442`	`0.000247442`	`[]`	`0`
`77848338483`	`[]`	`[]`	`["Cars", "Routes"]`	`0.033467418`	`0.000251418`	`[]`	`0`

תכין רשימה של העסקאות עם חביון ההתחייבות הממוצע הכי גבוה

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

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds,
       avg_commit_latency_seconds,
       avg_bytes
FROM spanner_sys.txn_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_top_hour)
ORDER BY avg_commit_latency_seconds DESC;

פלט השאילתה

fprint	read_columns	write_constructive_columns	write_delete_tables	avg_total_latency_seconds	avg_commit_latency_seconds	avg_bytes
`40015598317`	`[]`	`["Routes.name", "Cars.model"]`	`["Users"]`	`0.006578737`	`0.006547737`	`25286`
`77848338483`	`[]`	`[]`	`["Cars", "Routes"]`	`0.033467418`	`0.000251418`	`0`
`20524969030`	`["id", "no"]`	`[]`	`[]`	`0.001732442`	`0.000247442`	`0`

מציאת זמן האחזור הממוצע של עסקאות שקוראות עמודות מסוימות

השאילתה הבאה מחזירה את נתוני השהייה הממוצעת של טרנזקציות שקוראות את העמודה ADDRESS מנתונים סטטיסטיים של שעה אחת:

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds
FROM spanner_sys.txn_stats_top_hour
WHERE 'ADDRESS' IN UNNEST(read_columns)
ORDER BY avg_total_latency_seconds DESC;

פלט השאילתה

fprint	read_columns	write_constructive_columns	write_delete_tables	avg_total_latency_seconds
`77848338483`	`["ID", "ADDRESS"]`	`[]`	`["Cars", "Routes"]`	`0.033467418`
`40015598317`	`["ID", "NAME", "ADDRESS"]`	`[]`	`["Users"]`	`0.006578737`

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

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

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_bytes
FROM spanner_sys.txn_stats_top_hour
ORDER BY avg_bytes DESC;

פלט השאילתה

fprint	read_columns	write_constructive_columns	write_delete_tables	avg_bytes
`40015598317`	`[]`	`[]`	`["Users"]`	`25286`
`77848338483`	`[]`	`[]`	`["Cars", "Routes"]`	`12005`
`20524969030`	`["ID", "ADDRESS"]`	`[]`	`["Users"]`	`10923`

נתונים סטטיסטיים מצטברים

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

‫SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: נתונים סטטיסטיים מצטברים לכל העסקאות במרווחי זמן של דקה
‫SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: נתונים סטטיסטיים מצטברים לכל העסקאות במרווחי זמן של 10 דקות
‫SPANNER_SYS.TXN_STATS_TOTAL_HOUR: סיכום נתונים סטטיסטיים של כל העסקאות במרווחי זמן של שעה

לטבלאות של נתונים סטטיסטיים מצטברים יש את המאפיינים הבאים:

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

לדוגמה, בשעה 11:59:30, המרווחים האחרונים שזמינים לשאילתות SQL על נתונים סטטיסטיים מצטברים של עסקאות הם:
- דקה אחת: 11:58:00–11:58:59
- 10 דקות: 11:40:00–11:49:59
- שעה אחת: 10:00:00–10:59:59 AM
כל שורה מכילה נתונים סטטיסטיים של כל העסקאות שבוצעו במסד הנתונים במהלך המרווח שצוין, כשהם מצטברים יחד. יש רק שורה אחת לכל מרווח זמן.
יכול להיות שהנתונים הסטטיסטיים שמתועדים בטבלאות SPANNER_SYS.TXN_STATS_TOTAL_* כוללים עסקאות שלא תועדו בטבלאות SPANNER_SYS.TXN_STATS_TOP_* ב-Spanner.
חלק מהעמודות בטבלאות האלה מוצגות כמדדים ב-Cloud Monitoring. אלה המדדים שמוצגים:
- מספר הניסיונות לביצוע פעולת Commit
- מספר הניסיונות החוזרים לביצוע Commit
- משתתפים בעסקה
- זמני האחזור של העסקאות
- בייטים שנכתבו
מידע נוסף מופיע במאמר בנושא מדדים של Spanner.

סכמת טבלאות

שם העמודה	סוג	תיאור
`INTERVAL_END`	`TIMESTAMP`	סוף מרווח הזמן שבו נאסף הנתון הסטטיסטי הזה.
`ATTEMPT_COUNT`	`INT64`	המספר הכולל של הניסיונות לבצע את העסקאות, כולל הניסיונות שבוטלו לפני הקריאה ל-commit.
`COMMIT_ATTEMPT_COUNT`	`INT64`	המספר הכולל של ניסיונות לאישור עסקאות. המספר הזה צריך להיות זהה למספר השיחות אל שיטת `commit` של העסקה.
`COMMIT_ABORT_COUNT`	`INT64`	המספר הכולל של ניסיונות לביצוע עסקאות שבוטלו, כולל ניסיונות שבוטלו לפני הפעלת השיטה `commit` של העסקה.
`COMMIT_RETRY_COUNT`	`INT64`	מספר ניסיונות השמירה שהם ניסיונות חוזרים מניסיונות שבוטלו בעבר. יכול להיות שהייתה יותר מניסיון אחד לבצע טרנזקציה ב-Spanner לפני שהיא אושרה, בגלל מחלוקות על נעילה או אירועים זמניים. מספר גבוה של ניסיונות חוזרים ביחס למספר הניסיונות לביצוע פעולות מצביע על כך שיכול להיות שיש בעיות שכדאי לבדוק. מידע נוסף זמין בקטע הסבר על עסקאות ומספרים של פעולות Commit שבדף הזה.
`COMMIT_FAILED_PRECONDITION_COUNT`	`INT64`	המספר הכולל של ניסיונות ביצוע (commit) של עסקאות שהחזירו שגיאות של תנאי מוקדם שנכשל, כמו הפרות של אינדקס `UNIQUE`, שורה שכבר קיימת או שורה שלא נמצאה.
`SERIALIZABLE_PESSIMISTIC_TXN_COUNT`	`INT64`	המספר הכולל של ניסיונות העסקה שהופעלו עם `SERIALIZABLE` רמת הבידוד ו-`PESSIMISTIC` נעילה. היא תת-קבוצה של `ATTEMPT_COUNT`.
`REPEATABLE_READ_OPTIMISTIC_TXN_COUNT`	`INT64`	המספר הכולל של ניסיונות העסקה שהופעלו עם `REPEATABLE READ` רמת הבידוד ו-`OPTIMISTIC` נעילה. היא תת-קבוצה של `ATTEMPT_COUNT`.
`AVG_PARTICIPANTS`	`FLOAT64`	המספר הממוצע של משתתפים בכל ניסיון לביצוע פעולת Commit. מידע נוסף על משתתפים זמין במאמר מחזור החיים של פעולות קריאה וכתיבה ב-Spanner.
`AVG_TOTAL_LATENCY_SECONDS`	`FLOAT64`	מספר השניות הממוצע שחלף מהפעולה הראשונה בעסקה ועד לאישור או לביטול שלה.
`AVG_COMMIT_LATENCY_SECONDS`	`FLOAT64`	מספר השניות הממוצע שנדרש לביצוע פעולת השמירה.
`AVG_BYTES`	`FLOAT64`	מספר הבייטים הממוצע שנכתב על ידי העסקה.
`TOTAL_LATENCY_DISTRIBUTION`	`ARRAY<STRUCT>`	היסטוגרמה של זמן האחזור הכולל של ביצוע השינויים, שהוא הזמן שחל מתחילת הפעולה הראשונה של העסקה ועד לביצוע השינויים או לביטול שלה, בכל הניסיונות לבצע את העסקה. הערה לגבי ממשק PostgreSQL: מסדי נתונים בניב PostgreSQL לא תומכים בעמודה הזו. במקום זאת, משתמשים בעמודה `TOTAL_LATENCY_DISTRIBUTION_JSON_STRING` במסדי נתונים של ניב PostgreSQL. אם עסקה מבוטלת כמה פעמים ואז מתבצעת בהצלחה, זמן האחזור נמדד לכל ניסיון עד להתחייבות הסופית המוצלחת. הערכים נמדדים בשניות. המערך מכיל רכיב יחיד והוא מהסוג הבא: `ARRAY<STRUCT< COUNT INT64, MEAN FLOAT64, SUM_OF_SQUARED_DEVIATION FLOAT64, NUM_FINITE_BUCKETS INT64, GROWTH_FACTOR FLOAT64, SCALE FLOAT64, BUCKET_COUNTS ARRAY<INT64>>>` מידע נוסף על הערכים מופיע במאמרים התפלגות ואקספוננציאלי. כדי לחשב את חביון האחוזון מההתפלגות, משתמשים בפונקציה `SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64)`, שמחזירה את האחוזון המשוער n. לדוגמה, אפשר לעיין במאמר בנושא חיפוש חביון באחוזון ה-99 של עסקאות. מידע נוסף זמין במאמר אחוזונים ומדדים של ערכי התפלגות.
`OPERATIONS_BY_TABLE`	`ARRAY<STRUCT>`	ההשפעה של פעולות `INSERT` או `UPDATE` על כל העסקאות, בכל טבלה בנפרד. הנתון הזה מצוין על ידי מספר הפעמים שהשורות מושפעות ומספר הבייטים שנכתבים. הערה לגבי ממשק PostgreSQL: מסדי נתונים בניב PostgreSQL לא תומכים בעמודה הזו. במקום זאת, משתמשים בעמודה `OPERATIONS_BY_TABLE_JSON_STRING` במסדי נתונים של ניב PostgreSQL. העמודה הזו עוזרת להמחיש את העומס על הטבלאות ומספקת תובנות לגבי קצב הכתיבה של העסקאות לטבלאות. מציינים את המערך באופן הבא: `ARRAY<STRUCT< TABLE STRING(MAX), INSERT_OR_UPDATE_COUNT INT64, INSERT_OR_UPDATE_BYTES INT64>>`
`TOTAL_LATENCY_DISTRIBUTION_JSON_STRING`	`STRING`	היסטוגרמה של זמן האחזור הכולל של ביצוע פעולת ה-commit, שהוא הזמן שחל מתחילת הפעולה הראשונה של העסקה ועד לביצוע ה-commit או לביטול העסקה, עבור כל הניסיונות של העסקה. ייצוג מחרוזת תואמת JSON של נתון הסטטיסטיקה `TOTAL_LATENCY_DISTRIBUTION`. מחרוזת ה-JSON היא אובייקט JSON עם אותו מבנה כמו STRUCT שמוגדר ב-`TOTAL_LATENCY_DISTRIBUTION`. אם עסקה מבוטלת כמה פעמים ואז מתבצעת בהצלחה, זמן האחזור נמדד לכל ניסיון עד לביצוע הסופי. הערכים נמדדים בשניות. העמודה הזו נתמכת במסדי נתונים של GoogleSQL-dialect ו-PostgreSQL-dialect. בעמודה הזו מופיע הפיזור. כדי לחשב את חביון האחוזון מההתפלגות, משתמשים בפונקציה `SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64)`, שמחזירה את האחוזון המשוער n. דוגמה קשורה: חיפוש ערך האחוזון ה-99 של זמן האחזור של עסקאות באמצעות העמודה `TOTAL_LATENCY_DISTRIBUTION_JSON_STRING`. מידע נוסף זמין במאמר אחוזונים ומדדים של ערכי התפלגות.
`OPERATIONS_BY_TABLE_JSON_STRING`	`STRING`	ההשפעה של פעולות `INSERT` או `UPDATE` לפי טבלה. הנתונים האלה מוצגים במספר הפעמים שהשורות מושפעות ובמספר הבייטים שנכתבים. ייצוג מחרוזת תואמת ל-JSON של העמודה `OPERATIONS_BY_TABLE`. מחרוזת ה-JSON היא אובייקט JSON עם אותו מבנה כמו STRUCT שמוגדר בעמודה `OPERATIONS_BY_TABLE`. העמודה הזו נתמכת במסדי נתונים של GoogleSQL-dialect ו-PostgreSQL-dialect. העמודה הזו עוזרת להמחיש את העומס על הטבלאות ומספקת תובנות לגבי הקצב שבו טרנזקציה כותבת לטבלאות.

שאילתות לדוגמה

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

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

SELECT interval_end,
       commit_attempt_count
FROM spanner_sys.txn_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_minute)
ORDER BY interval_end;

פלט השאילתה

interval_end	commit_attempt_count
`2020-01-17 11:46:00-08:00`	`21`

שימו לב: יש רק שורה אחת בתוצאה כי לסטטיסטיקות המצטברות יש רק רשומה אחת לכל interval_end לכל משך זמן.

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

השאילתה הבאה מחזירה את זמן האחזור הכולל של ביצוע פעולות (commit) בכל העסקאות ב-10 הדקות האחרונות:

SELECT (avg_commit_latency_seconds * commit_attempt_count / 60 / 60)
  AS total_commit_latency_hours
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute);

פלט השאילתה

total_commit_latency_hours
`0.8967`

שימו לב: יש רק שורה אחת בתוצאה כי לסטטיסטיקות המצטברות יש רק רשומה אחת לכל interval_end לכל משך זמן.

איתור חביון באחוזון ה-99 של עסקאות

השאילתות הבאות מחזירות את האחוזון ה-99 של זמן הביצוע של שאילתות שהופעלו ב-10 הדקות האחרונות.

במסדי נתונים של ניב GoogleSQL, אפשר להשתמש בעמודה TOTAL_LATENCY_DISTRIBUTION:

SELECT interval_end, avg_total_latency_seconds,
       SPANNER_SYS.DISTRIBUTION_PERCENTILE(total_latency_distribution[OFFSET(0)], 99.0)
  AS percentile_latency
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute)
ORDER BY interval_end;

במסדי נתונים של ניב PostgreSQL, משתמשים בעמודה TOTAL_LATENCY_JSON_DISTRIBUTION_JSON_STRING במקום זאת:

SELECT interval_end, avg_total_latency_seconds,
       SPANNER_SYS.DISTRIBUTION_PERCENTILE(total_latency_distribution_json_string, 99.0)
  AS percentile_latency
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute)
ORDER BY interval_end;

פלט השאילתה

interval_end	avg_total_latency_seconds	percentile_latency
`2022-08-17 11:46:00-08:00`	`0.34576998305986395`	`9.00296190476190476`

שימו לב להבדל הגדול בין זמן האחזור הממוצע לבין זמן האחזור באחוזון ה-99. האחוזון ה-99 של זמן האחזור עוזר לזהות עסקאות חריגות אפשריות עם זמן אחזור גבוה.

יש רק שורה אחת בתוצאה כי לנתונים סטטיסטיים מצטברים יש רק רשומה אחת לכל interval_end לכל משך זמן.

שמירת נתונים

לפחות, Spanner שומר נתונים לכל טבלה למשך תקופות הזמן הבאות:

‫SPANNER_SYS.TXN_STATS_TOP_MINUTE ו-SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: מרווחי זמן שכוללים את 6 השעות האחרונות.
‫SPANNER_SYS.TXN_STATS_TOP_10MINUTE ו-SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: מרווחי זמן שכוללים את 4 הימים הקודמים.
‫SPANNER_SYS.TXN_STATS_TOP_HOUR ו-SPANNER_SYS.TXN_STATS_TOTAL_HOUR: מרווחי זמן שכוללים את 30 הימים האחרונים.

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

הסבר על טרנזקציות ומספרים של פעולות Commit

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

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

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

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

בטבלה הבאה מפורטות כמה דוגמאות לאופן שבו COMMIT_ATTEMPT_COUNT,‏ COMMIT_ABORT_COUNT ו-COMMIT_RETRY_COUNT מתועדים בתרחישים שונים.

תרחיש	COMMIT_ATTEMPT_COUNT	COMMIT_ABORT_COUNT	COMMIT_RETRY_COUNT
העסקה בוצעה בהצלחה בניסיון הראשון.	1	0	0
העסקה בוטלה בגלל שגיאת פסק זמן.	1	1	0
העסקה בוטלה בגלל בעיה זמנית ברשת, והושלמה בהצלחה אחרי ניסיון חוזר אחד.	2	1	1
בוצעו 5 עסקאות עם אותו FPRINT במרווח של 10 דקות. 3 מהעסקאות בוצעו בהצלחה בניסיון הראשון, בעוד ש-2 עסקאות בוטלו ואז בוצעו בהצלחה בניסיון הראשון לביצוע חוזר.	7	2	2

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

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

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

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

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

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

אפשר למצוא את המזהה הזה באפליקציה שמשתמשת ב-Spanner.

לצורך התרגיל הזה, נניח שהבעיה התחילה בערך בשעה 17:20 ב-17 במאי 2020.

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

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

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

לדוגמה, השאילתה הבאה מחזירה את נתוני העסקאות המצטברים מהתאריך 4:30 pm עד התאריך 7:40 pm (כולל).

SELECT
  interval_end,
  ROUND(avg_total_latency_seconds,4) as avg_total_latency_seconds,
  commit_attempt_count,
  commit_abort_count
FROM SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE
WHERE
  interval_end >= "2020-05-17T16:40:00"
  AND interval_end <= "2020-05-17T19:40:00"
ORDER BY interval_end;

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

interval_end	avg_total_latency_seconds	commit_attempt_count	commit_abort_count
2020-05-17 16:40:00-07:00	0.0284	315691	5170
2020-05-17 16:50:00-07:00	0.0250	302124	3828
2020-05-17 17:00:00-07:00	0.0460	346087	11382
2020-05-17 17:10:00-07:00	0.0864	379964	33826
2020-05-17 17:20:00-07:00	0.1291	390343	52549
2020-05-17 17:30:00-07:00	0.1314	456455	76392
2020-05-17 17:40:00-07:00	0.1598	507774	121458
2020-05-17 17:50:00-07:00	0.1641	516587	115875
2020-05-17 18:00:00-07:00	0.1578	552711	122626
2020-05-17 18:10:00-07:00	0.1750	569460	154205
2020-05-17 18:20:00-07:00	0.1727	613571	160772
2020-05-17 18:30:00-07:00	0.1588	601994	143044
2020-05-17 18:40:00-07:00	0.2025	604211	1700019
2020-05-17 18:50:00-07:00	0.1615	601622	135601
2020-05-17 19:00:00-07:00	0.1653	596804	129511
2020-05-17 19:10:00-07:00	0.1414	560023	112247
2020-05-17 19:20:00-07:00	0.1367	570864	100596
2020-05-17 19:30:00-07:00	0.0894	539729	65316
2020-05-17 19:40:00-07:00	0.0820	479151	40398

החביון המצטבר ומספר הביטולים גבוהים יותר בתקופות שמסומנות. בוחרים מרווח של 10 דקות שבו זמן האחזור המצטבר ומספר הביטולים או שניהם גבוהים. מרווח הזמן שמסתיים ב-2020-05-17T18:40:00 משמש בשלב הבא כדי לזהות אילו טרנזקציות תורמות לזמן טעינה ארוך ולמספר גבוה של ביטולים.

זיהוי עסקאות עם זמן אחזור גבוה

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

מריצים את השאילתה הבאה כדי לקבל את העסקאות שהכי משפיעות על הביצועים בסדר יורד של זמן האחזור הכולל עבור המרווח לדוגמה שמסתיים ב-2020-05-17T18:40:00.

SELECT
  interval_end,
  fprint,
  ROUND(avg_total_latency_seconds,4) as avg_total_latency_seconds,
  ROUND(avg_commit_latency_seconds,4) as avg_commit_latency_seconds,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC;

interval_end	fprint	avg_total_latency_seconds	avg_commit_latency_seconds	commit_attempt_count	commit_abort_count	commit_retry_count
2020-05-17 18:40:00-07:00	15185072816865185658	0.3508	0.0139	278802	142205	129884
2020-05-17 18:40:00-07:00	15435530087434255496	0.1633	0.0142	129012	27177	24559
2020-05-17 18:40:00-07:00	14175643543447671202	0.1423	0.0133	5357	636	433
2020-05-17 18:40:00-07:00	898069986622520747	0.0198	0.0158	6	0	0
2020-05-17 18:40:00-07:00	10510121182038036893	0.0168	0.0125	7	0	0
2020-05-17 18:40:00-07:00	9287748709638024175	0.0159	0.0118	4269	1	0
2020-05-17 18:40:00-07:00	7129109266372596045	0.0142	0.0102	182227	0	0
2020-05-17 18:40:00-07:00	15630228555662391800	0.0120	0.0107	58	0	0
2020-05-17 18:40:00-07:00	7907238229716746451	0.0108	0.0097	65	0	0
2020-05-17 18:40:00-07:00	10158167220149989178	0.0095	0.0047	3454	0	0
2020-05-17 18:40:00-07:00	9353100217060788102	0.0093	0.0045	725	0	0
2020-05-17 18:40:00-07:00	9521689070912159706	0.0093	0.0045	164	0	0
2020-05-17 18:40:00-07:00	11079878968512225881	0.0064	0.0019	65	0	0

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

זיהוי העמודות שמשתתפות בעסקה עם זמן אחזור גבוה

בשלב הזה, כדי לבדוק אם עסקאות עם זמן טעינה גבוה פועלות על אותו סט של עמודות, מאחזרים את הנתונים של read_columns, write_constructive_columns ו-write_delete_tables עבור עסקאות עם מספר גבוה של ביטולים. הערך FPRINT יהיה שימושי גם בשלב הבא.

SELECT
  fprint,
  read_columns,
  write_constructive_columns,
  write_delete_tables
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC LIMIT 3;

fprint	read_columns	write_constructive_columns	write_delete_tables
15185072816865185658	`[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.shares]`	`[TestHigherLatency._exists,TestHigherLatency.shares,TestHigherLatency_lang_status_score_index.shares]`	[]
15435530087434255496	`[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.likes,globalTagAffinity.score]`	`[TestHigherLatency._exists,TestHigherLatency.likes,TestHigherLatency_lang_status_score_index.likes]`	[]
14175643543447671202	`[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.ugcCount]`	`[TestHigherLatency._exists,TestHigherLatency.ugcCount,TestHigherLatency_lang_status_score_index.ugcCount]`	[]

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

קובעים איך ביצועי העסקאות השתנו לאורך זמן

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

SELECT
  interval_end,
  ROUND(avg_total_latency_seconds, 3) AS latency,
  ROUND(avg_commit_latency_seconds, 3) AS commit_latency,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count,
  commit_failed_precondition_count,
  avg_bytes
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end >= "2020-05-17T16:40:00"
  AND interval_end <= "2020-05-17T19:40:00"
  AND fprint = $FPRINT
ORDER BY interval_end;

interval_end	זמן אחזור	commit_latency	commit_attempt_count	commit_abort_count	commit_retry_count	avg_bytes
2020-05-17 16:40:00-07:00	0.095	0.010	53230	4752	4330	91
2020-05-17 16:50:00-07:00	0.069	0.009	61264	3589	3364	91
2020-05-17 17:00:00-07:00	0.150	0.010	75868	10557	9322	91
2020-05-17 17:10:00-07:00	0.248	0.013	103151	30220	28483	91
2020-05-17 17:20:00-07:00	0.310	0.012	130078	45655	41966	91
‫2020-05-17 17:30:00-07:00	0.294	0.012	160064	64930	59933	91
2020-05-17 17:40:00-07:00	0.315	0.013	209614	104949	96770	91
2020-05-17 17:50:00-07:00	0.322	0.012	215682	100408	95867	90
2020-05-17 18:00:00-07:00	0.310	0.012	230932	106728	99462	91
2020-05-17 18:10:00-07:00	0.309	0.012	259645	131049	125889	91
2020-05-17 18:20:00-07:00	0.315	0.013	272171	137910	129411	90
2020-05-17 18:30:00-07:00	0.292	0.013	258944	121475	115844	91
2020-05-17 18:40:00-07:00	0.350	0.013	278802	142205	134229	91
2020-05-17 18:50:00-07:00	0.302	0.013	256259	115626	109756	91
2020-05-17 19:00:00-07:00	0.315	0.014	250560	110662	100322	91
2020-05-17 19:10:00-07:00	0.271	0.014	238384	99025	90187	91
2020-05-17 19:20:00-07:00	0.273	0.014	219687	84019	79874	91
2020-05-17 19:30:00-07:00	0.198	0.013	195357	59370	55909	91
2020-05-17 19:40:00-07:00	0.181	0.013	167514	35705	32885	91

בפלט הזה אפשר לראות שזמן האחזור הכולל גבוה בתקופה המודגשת. בנוסף, בכל מקום שבו זמן האחזור הכולל גבוה, גם commit_attempt_count commit_abort_count ו-commit_retry_count גבוהים, למרות שזמן האחזור של ה-commit‏ (commit_latency) לא השתנה באופן משמעותי. מאחר שהתחייבויות לעסקאות מבוטלות בתדירות גבוהה יותר, גם מספר הניסיונות להתחייבות גבוה בגלל ניסיונות חוזרים להתחייבות.

סיכום

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

זיהוי עסקאות שלא בוצע ניסיון חוזר שלהן בצורה תקינה

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

SELECT
  *
FROM (
  SELECT
    fprint,
    SUM(commit_attempt_count) AS total_commit_attempt_count,
    SUM(commit_abort_count) AS total_commit_abort_count,
    SUM(commit_retry_count) AS total_commit_retry_count
  FROM
    SPANNER_SYS.TXN_STATS_TOP_10MINUTE
  GROUP BY
    fprint )
WHERE
  total_commit_retry_count = 0
  AND total_commit_abort_count > 0
ORDER BY
  total_commit_abort_count DESC;

fprint	total_commit_attempt_count	total_commit_abort_count	total_commit_retry_count
1557557373282541312	3367894	44232	0
5776062322886969344	13566	14	0

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

השאילתה הבאה מחזירה פרטים נוספים על העסקה עם fprint‏ 1557557373282541312,כולל read_columns, ‏ write_constructive_columns ו-write_delete_tables. המידע הזה עוזר לזהות את העסקה בקוד הלקוח, שבו אפשר לבדוק את לוגיקת הניסיון החוזר בתרחיש הזה.

SELECT
  interval_end,
  fprint,
  read_columns,
  write_constructive_columns,
  write_delete_tables,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count
FROM
  SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  fprint = 1557557373282541312
ORDER BY
  interval_end DESC;

interval_end	fprint	read_columns	write_constructive_columns	write_delete_tables	commit_attempt_count	commit_abort_count
2021-01-27T18:30:00Z	1557557373282541312	‪['Singers._exists']	‪['Singers.FirstName', 'Singers.LastName', 'Singers._exists']	[]	805228	1839
2021-01-27T18:20:00Z	1557557373282541312	‪['Singers._exists']	‪['Singers.FirstName', 'Singers.LastName', 'Singers._exists']	[]	1034429	38779
2021-01-27T18:10:00Z	1557557373282541312	‪['Singers._exists']	‪['Singers.FirstName', 'Singers.LastName', 'Singers._exists']	[]	833677	2266
2021-01-27T18:00:00Z	1557557373282541312	‪['Singers._exists']	‪['Singers.FirstName', 'Singers.LastName', 'Singers._exists']	[]	694560	1348

העסקה כוללת קריאה של העמודה המוסתרת Singers._exists כדי לבדוק אם קיימת שורה. העסקה נרשמת גם בעמודות Singers.FirstName ו-Singer.LastName. המידע הזה יכול לעזור לכם לקבוע אם מנגנון הניסיון החוזר של העסקאות שהוטמע בספריית הלקוח המותאמת אישית שלכם פועל כמצופה.

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

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

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

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

איך ניגשים לסטטיסטיקות של עסקאות

נתונים סטטיסטיים של זמן ההמתנה לתגובה מקובצים לפי עסקה

סכמת טבלאות

שאילתות לדוגמה

הצגת הנתונים הסטטיסטיים הבסיסיים של כל עסקה בתקופה נתונה

פלט השאילתה

תכין רשימה של העסקאות עם חביון ההתחייבות הממוצע הכי גבוה

פלט השאילתה

מציאת זמן האחזור הממוצע של עסקאות שקוראות עמודות מסוימות

פלט השאילתה

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

פלט השאילתה

נתונים סטטיסטיים מצטברים

סכמת טבלאות

שאילתות לדוגמה

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

פלט השאילתה

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

פלט השאילתה

איתור חביון באחוזון ה-99 של עסקאות

פלט השאילתה

שמירת נתונים

הסבר על טרנזקציות ומספרים של פעולות Commit

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

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

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

זיהוי עסקאות עם זמן אחזור גבוה

זיהוי העמודות שמשתתפות בעסקה עם זמן אחזור גבוה

קובעים איך ביצועי העסקאות השתנו לאורך זמן

סיכום

זיהוי עסקאות שלא בוצע ניסיון חוזר שלהן בצורה תקינה

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

נתונים סטטיסטיים של עסקאות