Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

במאמר הזה מתוארים הנתונים הסטטיסטיים של העסקאות ש-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`	הגיבוב של `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`	המספר הכולל של ניסיונות ביצוע (commit) של עסקאות שהחזירו שגיאות של תנאי קדם שנכשלו, כמו `UNIQUE` הפרות של אינדקסים, שורה שכבר קיימת או שורה שלא נמצאה.
`SERIALIZABLE_PESSIMISTIC_TXN_COUNT`	`INT64`	המספר הכולל של ניסיונות העסקה שהופעלו עם `SERIALIZABLE` רמת הבידוד ונעילת `PESSIMISTIC`. היא תת-קבוצה של `ATTEMPT_COUNT`.
`SERIALIZABLE_OPTIMISTIC_TXN_COUNT`	`INT64`	המספר הכולל של ניסיונות העסקה שהופעלו עם `SERIALIZABLE` רמת הבידוד ועם נעילה של `OPTIMISTIC`. זוהי קבוצת משנה של `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 וניב PostgreSQL. העמודה הזו עוזרת להמחיש את העומס על הטבלאות ומספקת תובנות לגבי הקצב שבו טרנזקציה כותבת לטבלאות.

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

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

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

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

השאילתה הבאה מחזירה את המספר הכולל של ניסיונות ביצוע (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 לכל משך זמן.

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

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

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

השאילתה הבאה מחזירה פרטים נוספים על העסקה עם טביעת האצבע 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
מידע נוסף על בדיקת שימוש גבוה במעבד

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

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

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

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

סכמת טבלאות

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

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

פלט השאילתה

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

פלט השאילתה

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

פלט השאילתה

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

פלט השאילתה

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

סכמת טבלאות

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

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

פלט השאילתה

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

פלט השאילתה

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

פלט השאילתה

שמירת נתונים

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

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

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

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

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

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

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

סיכום

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

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

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