Spanner מספק קבוצה של טבלאות נתונים סטטיסטיים מובנות כדי לעזור לכם לקבל תובנות לגבי השאילתות, הקריאות והעסקאות שלכם. כדי ליצור קורלציה בין נתונים סטטיסטיים לבין קוד האפליקציה ולשפר את פתרון הבעיות, אפשר להוסיף תג (מחרוזת חופשית) לפעולות קריאה, שאילתה ועסקאות ב-Spanner בקוד האפליקציה. התגים האלה מאוכלסים בטבלאות סטטיסטיות, ועוזרים לכם ליצור קורלציה ולחפש על סמך תגים.
Spanner תומך בשני סוגים של תגים: תגי request ותגי transaction. כפי שהשמות שלהם מרמזים, אפשר להוסיף תגי עסקאות לעסקאות, ותגי בקשות לממשקי API של שאילתות וקריאות בודדות. אפשר להגדיר תג עסקה בהיקף העסקה ולהגדיר תגי בקשה נפרדים לכל בקשת API רלוונטית בעסקה. תגי בקשה ותגי עסקאות שמוגדרים בקוד האפליקציה מאוכלסים בעמודות של הטבלאות הבאות של נתונים סטטיסטיים.
| טבלת נתונים סטטיסטיים | סוג התגים שמופיעים בטבלת הנתונים הסטטיסטיים |
|---|---|
| נתונים סטטיסטיים של שאילתות TopN | בקשת תגים |
| TopN Read Statistics | בקשת תגים |
| TopN Transaction Statistics | תגי עסקאות |
| TopN Lock Statistics | תגי עסקאות |
בקשת תגים
אפשר להוסיף תג בקשה אופציונלי לשאילתה או לבקשת קריאה.
ב-Spanner, הנתונים הסטטיסטיים מקובצים לפי תג בקשה, שמופיע בשדה REQUEST_TAG של הטבלאות query statistics ו-read statistics.
מתי כדאי להשתמש בתגי בקשה
ריכזנו כאן כמה תרחישים שבהם כדאי להשתמש בתגי בקשות.
- איתור המקור של שאילתה או קריאה בעייתיות: Spanner אוסף נתונים סטטיסטיים לגבי קריאות ושאילתות בטבלאות סטטיסטיות מובנות. אם מצאתם בטבלת הנתונים הסטטיסטיים שאילתות איטיות או קריאות שצורכות הרבה CPU, ואם כבר הקציתם תגים לאותן שאילתות, תוכלו לזהות את המקור (האפליקציה או שירות המיקרו) שמבצע את הפעולות האלה על סמך המידע בתג.
- זיהוי קריאות או שאילתות בטבלאות נתונים סטטיסטיים: הקצאת תגי בקשה עוזרת לסנן שורות בטבלת הנתונים הסטטיסטיים על סמך התגים שמעניינים אתכם.
- איך בודקים אם שאילתות מאפליקציה או ממיקרו-שירות מסוימים פועלות לאט: תגי בקשה יכולים לעזור לזהות אם לשאילתות מאפליקציה או ממיקרו-שירות מסוימים יש חביון גבוה יותר.
- קיבוץ נתונים סטטיסטיים של קבוצת קריאות או שאילתות: אפשר להשתמש בתגי בקשה כדי לעקוב אחרי הביצועים של קבוצה של קריאות או שאילתות דומות, להשוות ביניהם ולדווח עליהם. לדוגמה, אם כמה שאילתות ניגשות לטבלה או לקבוצה של טבלאות עם אותו דפוס גישה, אפשר להוסיף את אותו תג לכל השאילתות האלה כדי לעקוב אחריהן יחד.
איך מקצים תגי בקשות
בדוגמה הבאה מוצג איך להגדיר תגי בקשות באמצעות ספריות הלקוח של Spanner.
C++
C#
המשך
Java
Node.js
PHP
Python
Ruby
איך מציגים תגי בקשות בטבלת הנתונים הסטטיסטיים
השאילתה הבאה מחזירה את נתוני השאילתה במרווחי זמן של 10 דקות.
SELECT t.text,
t.request_tag,
t.execution_count,
t.avg_latency_seconds,
t.avg_rows,
t.avg_bytes
FROM SPANNER_SYS.QUERY_STATS_TOP_10MINUTE AS t
LIMIT 3;
הנתונים הבאים הם דוגמה לתוצאות שמוחזרות מהשאילתה.
| טקסט | request_tag | execution_count | avg_latency_seconds | avg_rows | avg_bytes |
|---|---|---|---|---|---|
| SELECT SingerId, AlbumId, AlbumTitle FROM Albums | app=concert,env=dev,action=select | 212 | 0.025 | 21 | 2365 |
| select * from orders; | app=catalogsearch,env=dev,action=list | 55 | 0.02 | 16 | 33.35 |
| SELECT SingerId, FirstName, LastName FROM Singers; | [empty string] | 154 | 0.048 | 42 | 486.33 |
מהטבלה הזו של התוצאות, אפשר לראות שאם הקציתם REQUEST_TAG
לשאילתה, היא מאוכלסת בטבלת הנתונים הסטטיסטיים. אם לא הוקצה תג בקשה, מוצגת מחרוזת ריקה.
לגבי השאילתות שתויגו, הנתונים הסטטיסטיים מצטברים לפי תג (לדוגמה, לתג הבקשה app=concert,env=dev,action=select יש זמן אחזור ממוצע של 0.025 שניות). אם לא הוקצה תג, הנתונים הסטטיסטיים מצטברים לפי שאילתה (לדוגמה, השאילתה בשורה השלישית כוללת חביון ממוצע של 0.048 שניות).
תגי עסקאות
אפשר להוסיף תג עסקה אופציונלי לעסקאות ספציפיות.
ב-Spanner, הנתונים הסטטיסטיים מקובצים לפי תג העסקה, שמופיע בשדה TRANSACTION_TAG של טבלאות transaction statistics.
מתי כדאי להשתמש בתגי עסקאות
אלה כמה תרחישים שבהם כדאי להשתמש בתגי עסקאות.
- איתור המקור של עסקה בעייתית: Spanner אוסף נתונים סטטיסטיים של עסקאות קריאה-כתיבה בטבלת הנתונים הסטטיסטיים של העסקאות. אם אתם מוצאים עסקאות איטיות בטבלת נתוני העסקאות, ואם כבר הקציתם להן תגים, תוכלו לזהות את המקור (האפליקציה או המיקרו-שירות) שקורא לעסקאות האלה על סמך המידע בתג.
- זיהוי עסקאות בטבלאות נתונים סטטיסטיים: הקצאת תגי עסקאות עוזרת לסנן שורות בטבלת הנתונים הסטטיסטיים של העסקאות לפי התגים שמעניינים אתכם. אם לא משתמשים בתגי עסקאות, יכול להיות שתהליך גילוי הפעולות שמיוצגות על ידי נתון מסוים יהיה מסורבל. לדוגמה, כדי לזהות עסקה לא מתויגת בנתונים הסטטיסטיים של העסקאות, צריך לבדוק את הטבלאות והעמודות שקשורות לעסקה.
- איך בודקים אם טרנזקציות מאפליקציה או ממיקרו-שירות מסוימים מתבצעות לאט: תגי טרנזקציות יכולים לעזור לזהות אם לטרנזקציות מאפליקציה או ממיקרו-שירות מסוימים יש השהיות ארוכות יותר.
- קיבוץ נתונים סטטיסטיים של קבוצת טרנזקציות: אפשר להשתמש בתגי טרנזקציות כדי לעקוב אחרי הביצועים של קבוצת טרנזקציות דומות, להשוות ביניהם ולדווח עליהם.
- איך מוצאים אילו עסקאות ניגשות לעמודות שמעורבות בקונפליקט הנעילה: תגי עסקאות יכולים לעזור לזהות עסקאות בודדות שגורמות לקונפליקטים של נעילה בטבלאות Lock statistics.
- הזרמת נתוני שינויים של משתמשים מ-Spanner באמצעות סנכרון שינויים בזרמי נתונים: רשומות של נתוני סנכרון שינויים בזרמי נתונים מכילות תגי טרנזקציות של הטרנזקציות ששינו את נתוני המשתמשים. כך הקורא של זרם השינויים יכול לשייך שינויים לסוג העסקה על סמך תגים.
איך מקצים תגי עסקאות
בדוגמה הבאה מוצג איך להגדיר תגי טרנזקציות באמצעות ספריות הלקוח של Spanner. כשמשתמשים בספריית לקוח, אפשר להגדיר תג עסקה בתחילת קריאת העסקה, והתג יחול על כל הפעולות הנפרדות בתוך העסקה.
C++
C#
המשך
Java
Node.js
PHP
Python
Ruby
איך רואים תגי עסקאות בטבלת נתוני העסקאות
השאילתה הבאה מחזירה את הנתונים הסטטיסטיים של העסקאות במרווחי זמן של 10 דקות.
SELECT t.fprint,
t.transaction_tag,
t.read_columns,
t.commit_attempt_count,
t.avg_total_latency_seconds
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE AS t
LIMIT 3;
הנתונים הבאים הם דוגמה לתוצאות שמוחזרות מהשאילתה.
| fprint | transaction_tag | read_columns | commit_attempt_count | avg_total_latency_seconds |
|---|---|---|---|---|
| 40015598317 | app=concert,env=dev | [Venues._exists, Venues.VenueId, Venues.VenueName, Venues.Capacity] |
278802 | 0.3508 |
| 20524969030 | app=product,service=payment | [Singers.SingerInfo] | 129012 | 0.0142 |
| 77848338483 | [empty string] | [Singers.FirstName, Singers.LastName, Singers._exists] | 5357 | 0.048 |
מהטבלה הזו של התוצאות אפשר לראות שאם הקציתם TRANSACTION_TAG לעסקה, היא תאוכלס בטבלת הנתונים הסטטיסטיים של העסקאות. אם לא הוקצה תג עסקה, הערך שיוצג יהיה מחרוזת ריקה.
לגבי העסקאות שתויגו, הנתונים הסטטיסטיים מצטברים לפי תג עסקה
(לדוגמה, לתג העסקה app=concert,env=dev a יש זמן אחזור ממוצע של
0.3508 שניות). אם לא הוקצה תג, הנתונים הסטטיסטיים מצטברים לפי FPRINT (למשל, 77848338483 בשורה השלישית הוא זמן האחזור הממוצע של 0.048 שניות).
איך מציגים תגי עסקאות בטבלת הנתונים הסטטיסטיים של הנעילה
השאילתה הבאה מחזירה את נתוני הנעילה במרווחי זמן של 10 דקות.
הפונקציה CAST() ממירה את השדה row_range_start_key BYTES למחרוזת.
SELECT
CAST(s.row_range_start_key AS STRING) AS row_range_start_key,
s.lock_wait_seconds,
s.sample_lock_requests
FROM SPANNER_SYS.LOCK_STATS_TOP_10MINUTE s
LIMIT 2;
הנתונים הבאים הם דוגמה לתוצאות שמוחזרות מהשאילתה.
| row_range_start_key | lock_wait_seconds | sample_lock_requests |
|---|---|---|
| שירים(2,1,1) | 0.61 | LOCK_MODE: ReaderShared COLUMN: Singers.SingerInfo TRANSACTION_TAG: app=product,service=shipping LOCK_MODE: WriterShared COLUMN: Singers.SingerInfo TRANSACTION_TAG: app=product,service=payment |
| אלבומים(2 ומעלה) | 0.48 | LOCK_MODE: ReaderShared COLUMN: users._exists1 TRANSACTION_TAG: [empty string] LOCK_MODE: WriterShared COLUMN: users._exists TRANSACTION_TAG: [empty string] |
מטבלת התוצאות הזו אפשר לראות שאם הקציתם TRANSACTION_TAG לעסקה, הוא יאוכלס בטבלת הנתונים הסטטיסטיים של הנעילה. אם לא הוקצה תג עסקה, הערך שיוצג יהיה מחרוזת ריקה.
הקצאת תגים באופן אוטומטי
ספריות הלקוח של Spanner תומכות בתיוג אוטומטי של מחסנית הקריאות. כשהתיוג האוטומטי מופעל, ספריית הלקוח בודקת את מחסנית הקריאות לביצוע של האפליקציה כדי לקבוע איזו מחלקה ואיזו method יזמו את הבקשה למסד הנתונים. המערכת יוצרת באופן אוטומטי תג על סמך השמות האלה (לדוגמה, OrderDao.placeOrder ב-Java או db__OrderDao__PlaceOrder ב-Go) ומאכלסת את request_tag או transaction_tag.
התיוג האוטומטי נתמך בספריות הלקוח הבאות:
- Java בגרסה 6.118.0 ואילך.
- Go בגרסה 1.92.0 ואילך.
שיקולים לגבי תיוג אוטומטי
לפני שמשתמשים בתיוג אוטומטי, כדאי להביא בחשבון את הנקודות הבאות:
- תקורה של מעבד וחביון: בדיקה של מחסניות קריאות בזמן ריצה באמצעות רפלקציה או מעקב אחר המתקשר בזמן ריצה בכל בקשה ועסקה יוצרת תקורה של מעבד וחביון. לפני שמפעילים אוטומטית תיוג אוטומטי באופן גלובלי בסביבות ייצור עם QPS גבוה, כדאי להעריך את ההשפעה על הביצועים של השירותים.
- הבדלים מתיוג של זוגות מפתח/ערך: תגים שנוצרו אוטומטית (כמו
OrderDao.placeOrder) מזהים סמלים של מקור הקוד ולא מטא-נתונים מובנים של זוגות מפתח/ערך (כמוapp=cart,env=dev). אם שאילתות המעקב שלכם מסננות טבלאות נתונים סטטיסטיים באמצעות קידומות של מפתחות כמוSTARTS_WITH(request_tag, "app="), פעולות שתויגו אוטומטית לא יתאימו למסננים האלה. - עוצמת התג: שמות של שיטות דינמיות או עמוסות מדי יכולים להגדיל את עוצמת התג בטבלאות הנתונים הסטטיסטיים. אם מספר התגים הייחודיים חורג מיכולת המעקב של Spanner במהלך מרווח זמן מסוים, Spanner נותן עדיפות לפעולות מעקב עם צריכת המשאבים הגבוהה ביותר.
- חשיפת מידע: התגים מאוחסנים בטבלאות נתונים סטטיסטיים של
SPANNER_SYSבטקסט פשוט, ולכן שמות של שיטות וסיווגים פנימיים גלויים לכל מי שיש לו גישה לשאילתות של נתונים סטטיסטיים של מסד הנתונים. אם הגישה למעקב משותפת בין גבולות, מומלץ להימנע משימוש במינוח עסקי רגיש בשמות של שיטות או מחלקות.
הפעלה והשבתה של תיוג אוטומטי
אפשר להגדיר תיוג אוטומטי בקוד, או להגדיר הגדרות באופן גלובלי באמצעות משתני סביבה.
כללי עדיפות להגדרות
אם מקצים ידנית תג request_tag או transaction_tag בבקשה או בכלי ליצירת טרנזקציות, התג הזה תמיד מקבל עדיפות על פני כל תג של מחסנית קריאות שנוצר אוטומטית. אם לא קיים תג ידני, הגדרת התיוג האוטומטי פועלת לפי כללי העדיפות הבאים:
- השבתה של שינוי ברירת המחדל: אם הערך של
SPANNER_DISABLE_AUTO_TAGGING=trueהוא true, התיוג האוטומטי מושבת לחלוטין בכל מקום, והוא מבטל את ההגדרות שנקבעו באמצעות תכנות. - הפעלה מאולצת של שינוי ברירת המחדל: אם ההגדרה
SPANNER_ENABLE_AUTO_TAGGING=trueמוגדרת, התיוג האוטומטי מופעל באופן גלובלי, ומשנה את הגדרות ברירת המחדל של ההגדרות שנקבעו באמצעות תכנות. - הגדרה באמצעות קוד: אם לא מוגדרים משתני סביבה לשינוי ברירת המחדל, הספרייה משתמשת בהגדרה באמצעות קוד שמוגדרת ב-
SpannerOptions(Java) או ב-ClientConfig(Go). - התנהגות ברירת המחדל: אם לא מגדירים תיוג אוטומטי, הוא מושבת כברירת מחדל.
שינויים גלובליים מברירת המחדל
כדי להפעיל או להשבית בכוח את התיוג האוטומטי באופן גלובלי בלי לשנות את קוד האפליקציה, צריך להגדיר משתני סביבה בסביבת זמן הריצה:
# Force-enable globally
export SPANNER_ENABLE_AUTO_TAGGING=true
# Force-disable globally (overrides code configuration)
export SPANNER_DISABLE_AUTO_TAGGING=true
הגדרה פרוגרמטית
בדוגמאות הבאות מוצג איך להפעיל תיוג אוטומטי של מחסנית הקריאות באמצעות ספריות הלקוח של Spanner.
המשך
package main
import (
"context"
"cloud.google.com/go/spanner"
)
func main() {
ctx := context.Background()
config := spanner.ClientConfig{
// Enable call-stack autotagging
EnableAutoTagging: true,
// Optional: Specify target application package prefixes
AutoTaggingPackages: []string{"github.com/mycompany/orderingservice"},
// Optional: Set maximum stack depth to inspect (default is 50)
AutoTaggingTracerLimit: 50,
}
client, err := spanner.NewClientWithConfig(ctx, "projects/p/instances/i/databases/d", config)
if err != nil {
panic(err)
}
defer client.Close()
}
Java
import com.google.cloud.spanner.Spanner;
import com.google.cloud.spanner.SpannerOptions;
import java.util.Arrays;
SpannerOptions options = SpannerOptions.newBuilder()
// Enable call-stack autotagging
.enableAutoTagging()
// Optional: Specify target application package prefixes
.setAutoTaggingPackages(Arrays.asList("com.mycompany.orderingservice."))
// Optional: Set maximum stack depth to inspect (default is 50)
.setAutoTaggingTracerLimit(100)
.build();
Spanner spanner = options.getService();
מיפוי בין שיטות API לתגי בקשה ועסקה
תגי בקשה ותגי עסקאות רלוונטיים לשיטות ספציפיות של API, בהתאם למצב העסקה: עסקה לקריאה בלבד או עסקה לקריאה ולכתיבה. באופן כללי, תגי עסקאות רלוונטיים לעסקאות עם הרשאת קריאה וכתיבה, ותגי בקשות רלוונטיים לעסקאות עם הרשאת קריאה בלבד. בטבלה הבאה מוצג המיפוי משיטות API לסוגי התגים הרלוונטיים.
| API Methods | מצבי עסקה | Request Tag | תג עסקה |
|---|---|---|---|
| קריאה, סטרימינג |
עסקה עם הרשאת קריאה בלבד | כן | לא |
| עסקת קריאה וכתיבה | כן | כן | |
| ExecuteSql, ExecuteStreamingSql1 |
טרנזקציה לקריאה בלבד1 | כן1 | לא |
| עסקת קריאה וכתיבה | כן | כן | |
| ExecuteBatchDml | עסקת קריאה וכתיבה | כן | כן |
| BeginTransaction | עסקת קריאה וכתיבה | לא | כן |
| שמירה (commit) | עסקת קריאה וכתיבה | לא | כן |
1 בשאילתות של שינוי סטרימינג שמופעלות באמצעות המחבר Apache Beam SpannerIO
Dataflow, REQUEST_TAG מכיל שם של משימת Dataflow.
מגבלות
כשמוסיפים תגים לקריאות, לשאילתות ולעסקאות, חשוב לשים לב למגבלות הבאות:
- האורך של מחרוזת תגים מוגבל ל-50 תווים. מחרוזות שחורגות מהמגבלה הזו נחתכות.
- מותר להשתמש בתג רק בתווי ASCII (32-126). תווי Unicode שרירותיים מוחלפים בקווים תחתונים.
- כל התווים של קו תחתון (_) בתחילת המחרוזת מוסרים.
- התגים הם תלויי אותיות רישיות. לדוגמה, אם מוסיפים את תג הבקשה
APP=cart,ENV=devלקבוצה אחת של שאילתות, ואת התגapp=cart,env=devלקבוצה אחרת של שאילתות, Spanner יצבור נתונים סטטיסטיים בנפרד לכל תג. יכול להיות שבתנאים הבאים לא יופיעו תגים בטבלאות הנתונים הסטטיסטיים:
- אם Spanner לא מצליח לאחסן בטבלאות נתונים סטטיסטיים של כל הפעולות המתויגות שמופעלות במהלך המרווח, המערכת נותנת עדיפות לפעולות עם צריכת המשאבים הגבוהה ביותר במהלך המרווח שצוין.
מתן שמות לתגים
כשמקצים תגים לפעולות במסד הנתונים, חשוב לחשוב איזה מידע רוצים להעביר בכל מחרוזת תגים. המוסכמה או התבנית שתבחרו ישפרו את היעילות של התגים. לדוגמה, מתן שמות מתאימים לתגים מקל על התאמת נתונים סטטיסטיים לקוד האפליקציה.
אפשר לבחור כל תג במסגרת המגבלות שצוינו. עם זאת, מומלץ ליצור מחרוזת תגים כקבוצה של צמדי מפתח-ערך שמופרדים באמצעות פסיקים.
לדוגמה, נניח שאתם משתמשים במסד נתונים של Spanner לתרחיש שימוש של מסחר אלקטרוני. כדאי לכלול מידע על האפליקציה, על סביבת הפיתוח ועל הפעולה שהשאילתה מבצעת בתג הבקשה שאתם מתכוונים להקצות לשאילתה מסוימת. אפשר להקצות את מחרוזת התג בפורמט מפתח/ערך כ-app=cart,env=dev,action=update. כלומר, השאילתה מופעלת מאפליקציית עגלת הקניות בסביבת הפיתוח, והיא משמשת לעדכון עגלת הקניות.
נניח שיש לכם שאילתה נוספת מאפליקציית חיפוש בקטלוג, ואתם מקצים את מחרוזת התג כ-app=catalogsearch,env=dev,action=list. אם אחת מהשאילתות האלה מופיעה בטבלת הנתונים הסטטיסטיים של השאילתות כשאילתה עם זמן אחזור גבוה, אפשר לזהות את המקור באמצעות התג.
הנה כמה דוגמאות לשימוש בתבנית תיוג כדי לארגן את נתוני הפעילות. הדוגמאות האלה לא ממצות את כל האפשרויות. אפשר גם לשלב אותן במחרוזת התג באמצעות תו מפריד כמו פסיק.
| Tag keys | דוגמאות לצמד תג/ערך | תיאור |
|---|---|---|
| בקשת הצטרפות | app=cart app=frontend app=catalogsearch |
עוזר לזהות את האפליקציה שמפעילה את הפעולה. |
| סביבה | env=prod env=dev env=test env=staging |
עוזר לזהות את הסביבה שמשויכת לפעולה. |
| Framework | framework=spring framework=django framework=jetty |
עוזרת לזהות את המסגרת שמשויכת לפעולה. |
| פעולה | action=list action=retrieve action=update |
עוזר לזהות את הפעולה שבוצעה על ידי הפעולה. |
| שירות | service=payment service=shipping |
עוזר לזהות את המיקרו-שירות שקורא לפעולה. |
הערות חשובות
- כשמקצים
REQUEST_TAG, הנתונים הסטטיסטיים של כמה שאילתות עם אותו מחרוזת תגים מקובצים בשורה אחת בטבלה query statistics. רק הטקסט של אחת מהשאילתות האלה מוצג בשדהTEXT. - כשמקצים
REQUEST_TAG, הנתונים הסטטיסטיים של כמה קריאות עם אותו מחרוזת תגים מקובצים בשורה אחת בטבלה read statistics. קבוצת כל העמודות שנקראות מתווספת לשדהREAD_COLUMNS. - כשמקצים
TRANSACTION_TAG, הנתונים הסטטיסטיים של עסקאות עם אותו מחרוזת תגים מקובצים בשורה אחת בטבלה transaction statistics. קבוצת כל העמודות שנכתבות על ידי העסקאות מתווספת לשדהWRITE_CONSTRUCTIVE_COLUMNS, וקבוצת כל העמודות שנקראות מתווספת לשדהREAD_COLUMNS.
תרחישים לפתרון בעיות באמצעות תגים
בתרחישים הבאים מוסבר איך להשתמש בתגים כדי לפתור בעיות בביצועים.
איתור המקור של עסקה בעייתית
השאילתה הבאה מחזירה את הנתונים הגולמיים של העסקאות המובילות בתקופת הזמן שנבחרה.
SELECT
fprint,
transaction_tag,
ROUND(avg_total_latency_seconds,4) as avg_total_latency_sec,
ROUND(avg_commit_latency_seconds,4) as avg_commit_latency_sec,
commit_attempt_count,
commit_abort_count
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC;
בטבלה הבאה מפורטים נתונים לדוגמה שמוחזרים מהשאילתה שלנו, שבה יש שלוש אפליקציות – cart, product ו-frontend – שבבעלותן או שהן שולחות שאילתות לאותו מסד נתונים.
אחרי שמזהים את הטרנזקציות עם זמן האחזור הגבוה, אפשר להשתמש בתגים המשויכים כדי לזהות את החלק הרלוונטי בקוד האפליקציה, ולפתור את הבעיה באמצעות סטטיסטיקות של טרנזקציות.
| fprint | transaction_tag | avg_total_latency_sec | avg_commit_latency_sec | commit_attempt_count | commit_abort_count |
|---|---|---|---|---|---|
| 7129109266372596045 | app=cart,service=order | 0.3508 | 0.0139 | 278802 | 142205 |
| 9353100217060788102 | app=cart,service=redis | 0.1633 | 0.0142 | 129012 | 27177 |
| 9353100217060788102 | app=product,service=payment | 0.1423 | 0.0133 | 5357 | 636 |
| 898069986622520747 | app=product,service=shipping | 0.0159 | 0.0118 | 4269 | 1 |
| 9521689070912159706 | app=frontend,service=ads | 0.0093 | 0.0045 | 164 | 0 |
| 11079878968512225881 | [empty string] | 0.031 | 0.015 | 14 | 0 |
באופן דומה, אפשר להשתמש בתג Request כדי למצוא את המקור של שאילתה בעייתית מטבלת query statistics ואת המקור של קריאה בעייתית מטבלת read statistics.
איך מוצאים את זמן האחזור ונתונים סטטיסטיים אחרים של טרנזקציות מאפליקציה או ממיקרו-שירות מסוימים
אם השתמשתם בשם האפליקציה או בשם המיקרו-שירות במחרוזת התג, תוכלו לסנן את טבלת נתוני העסקאות לפי תגים שמכילים את שם האפליקציה או שם המיקרו-שירות.
נניח שהוספתם עסקאות חדשות לאפליקציית התשלומים ואתם רוצים לראות את זמני האחזור ונתונים סטטיסטיים אחרים של העסקאות החדשות האלה. אם השתמשתם בשם של אפליקציית התשלום בתוך התג, תוכלו לסנן את טבלת הנתונים הסטטיסטיים של העסקאות כך שיוצגו רק התגים שמכילים את app=payment.
השאילתה הבאה מחזירה את נתוני העסקאות של אפליקציית התשלומים במרווחי זמן של 10 דקות.
SELECT
transaction_tag,
avg_total_latency_sec,
avg_commit_latency_sec,
commit_attempt_count,
commit_abort_count
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE STARTS_WITH(transaction_tag, "app=payment")
LIMIT 3;
הנה פלט לדוגמה:
| transaction_tag | avg_total_latency_sec | avg_commit_latency_sec | commit_attempt_count | commit_abort_count |
|---|---|---|---|---|
| app=payment,action=update | 0.3508 | 0.0139 | 278802 | 142205 |
| app=payment,action=transfer | 0.1633 | 0.0142 | 129012 | 27177 |
| app=payment, action=retrieve | 0.1423 | 0.0133 | 5357 | 636 |
באופן דומה, אפשר למצוא שאילתות או קריאות מאפליקציה ספציפית בטבלה query statistics או read statistics באמצעות תגי בקשה.
איתור העסקאות שמעורבות בקונפליקט נעילה
כדי לגלות אילו טרנזקציות ומפתחות שורה חוו זמני המתנה ארוכים לנעילה, אנחנו שולחים שאילתה לטבלה LOCK_STAT_TOP_10MINUTE, שבה מפורטים מפתחות השורה, העמודות והטרנזקציות התואמות שמעורבות בעימות הנעילה.
SELECT CAST(s.row_range_start_key AS STRING) AS row_range_start_key,
t.total_lock_wait_seconds,
s.lock_wait_seconds,
s.lock_wait_seconds/t.total_lock_wait_seconds frac_of_total,
s.sample_lock_requests
FROM spanner_sys.lock_stats_total_10minute t, spanner_sys.lock_stats_top_10minute s
WHERE
t.interval_end = "2020-05-17T18:40:00" and s.interval_end = t.interval_end;
הנה דוגמה לפלט מהשאילתה:
| row_range_start_key | total_lock_wait_seconds | lock_wait_seconds | frac_of_total | sample_lock_requests |
|---|---|---|---|---|
| זמרים(32) | 2.37 | 1.76 | 1 | LOCK_MODE: WriterShared COLUMN: Singers.SingerInfo TRANSACTION_TAG: app=cart,service=order LOCK_MODE: ReaderShared COLUMN: Singers.SingerInfo TRANSACTION_TAG: app=cart,service=redis |
מטבלת התוצאות הזו אפשר לראות שההתנגשות התרחשה בטבלה Singersבמפתח SingerId=32. Singers.SingerInfo היא העמודה שבה התרחש העימות בנוגע לנעילה בין ReaderShared לבין WriterShared. אפשר גם לזהות את העסקאות התואמות (app=cart,service=order ו-app=cart,service=redis) שבהן מתרחש העימות.
אחרי שמזהים את העסקאות שגורמות לבעיות נעילה, אפשר להתמקד בהן באמצעות Transaction Statistics כדי להבין טוב יותר מה העסקאות עושות, ואם אפשר להימנע מבעיה או לקצר את משך הזמן שבו הנעילות מתבצעות. מידע נוסף זמין במאמר בנושא שיטות מומלצות לצמצום התחרות על נעילה.
המאמרים הבאים
- מידע נוסף על כלים אחרים לבדיקת נתונים
- מידע נוסף על נתונים אחרים שמאוחסנים ב-Spanner עבור כל מסד נתונים זמין בטבלאות של סכימת המידע של מסד הנתונים.
- מידע נוסף על שיטות מומלצות ל-SQL ב-Spanner
- מידע נוסף על בדיקת שימוש גבוה במעבד