ביקורים

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

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

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

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

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

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

סקירה כללית של ערוצי gRPC

הלקוח של Spanner משתמש בערוצי gRPC לתקשורת. ערוץ gRPC אחד שווה בערך לחיבור TCP. ערוץ gRPC אחד יכול לטפל בעד 100 בקשות בו-זמניות. כלומר, לאפליקציה צריך להיות לפחות מספר ערוצי gRPC ששווה למספר הבקשות המקבילות שהאפליקציה תבצע, חלקי 100.

לקוח Spanner יוצר מאגר של ערוצי gRPC כשיוצרים אותו.

שיטות מומלצות לשימוש בספריות הלקוח של Google

בהמשך מפורטות שיטות מומלצות לשימוש בספריות הלקוח של Google ל-Spanner.

הגדרת מספר הסשנים וערוצי ה-gRPC במאגרי המידע

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

C++‎

MinSessions: 100
MaxSessions: 400
NumChannels: 4

C#‎

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Go

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Java

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Node.js

הלקוח Node.js לא תומך בכמה ערוצי gRPC. לכן, מומלץ ליצור כמה לקוחות במקום להגדיל את גודל מאגר הסשנים מעבר ל-100 סשנים ללקוח יחיד.

MinSessions: 25
MaxSessions: 100

PHP

לקוח ה-PHP לא תומך במספר ערוצי gRPC שניתן להגדרה.

MinSessions: 1
MaxSessions: 500

Python

‫Python תומך בארבעה סוגים שונים של מאגרי סשנים שבהם אפשר להשתמש כדי לנהל סשנים.

Ruby

לקוח Ruby לא תומך בכמה ערוצי gRPC. לכן, מומלץ ליצור כמה לקוחות במקום להגדיל את גודל מאגר הסשנים מעבר ל-100 סשנים ללקוח יחיד.

MinSessions: 10
MaxSessions: 100

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

באפליקציות עם רמת מקביליות גבוהה מומלץ:

  1. מגדירים את MinSessions למספר הצפוי של עסקאות מקבילות שיתבצעו על ידי לקוח יחיד.
  2. מגדירים את MaxSessions למספר המקסימלי של עסקאות בו-זמניות שלקוח יחיד יכול לבצע.
  3. מגדירים את MinSessions=MaxSessions אם רמת המקביליות הצפויה לא משתנה באופן משמעותי במהלך משך החיים של האפליקציה. כך לא תהיה אפשרות להגדיל או להקטין את מאגר הסשנים. גם הגדלה או הקטנה של מאגר הסשנים צורכות משאבים.
  4. מגדירים את NumChannels להיות MaxSessions / 100. ערוץ gRPC אחד יכול לטפל בעד 100 בקשות בו-זמנית. כדאי להגדיל את הערך הזה אם מבחינים בזמן אחזור ארוך (זמן אחזור p95/p99), כי זה יכול להצביע על עומס בערוץ gRPC.

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

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

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

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

  1. כל ערוץ gRPC משתמש בחיבור TCP אחד.
  2. כל קריאה ל-gRPC דורשת שרשור. מספר השרשורים המקסימלי שספריית הלקוח משתמשת בו שווה למספר המקסימלי של שאילתות מקבילות שהאפליקציה מריצה. השרשורים האלה מופיעים מעל כל השרשורים שהאפליקציה משתמשת בהם ללוגיקה העסקית שלה.

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

ניהול השבר של סשנים עם הרשאה לכתיבה

בספריות לקוח מסוימות, Spanner שומר חלק מהסשנים לעסקאות קריאה-כתיבה. החלק הזה נקרא 'שבריר הסשנים לכתיבה'. אם האפליקציה שלכם משתמשת בכל סשני הקריאה, מערכת Spanner משתמשת בסשנים של קריאה וכתיבה, גם לעסקאות לקריאה בלבד. סשנים עם הרשאות קריאה וכתיבה דורשים spanner.databases.beginOrRollbackReadWriteTransaction. אם המשתמש נמצא בתפקיד IAM‏ spanner.databaseReader, השיחה תיכשל ו-Spanner יחזיר את הודעת השגיאה הבאה:

generic::permission_denied: Resource %resource% is missing IAM permission:
spanner.databases.beginOrRollbackReadWriteTransaction

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

C++‎

כל הסשנים של C++ זהים. אין סשנים עם הרשאת קריאה בלבד או הרשאת קריאה וכתיבה בלבד.

C#‎

ברירת המחדל של השבר של סשנים של כתיבה ב-C# ‎ היא 0.2. אפשר לשנות את השבר באמצעות השדה WriteSessionsFraction של SessionPoolOptions.

Go

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

Java

כל הסשנים של Java זהים. אין סשנים עם הרשאת קריאה בלבד או הרשאת קריאה וכתיבה בלבד.

Node.js

כל הסשנים של Node.js זהים. אין סשנים עם הרשאת קריאה בלבד או הרשאת קריאה וכתיבה בלבד.

PHP

כל הסשנים של PHP זהים. אין סשנים עם הרשאת קריאה בלבד או הרשאת קריאה וכתיבה בלבד.

Python

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

Ruby

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

שיטות מומלצות ליצירת ספריית לקוח או לשימוש ב-REST/RPC

בקטעים הבאים מפורטות שיטות מומלצות להטמעה של סשנים בספריית לקוח של Spanner, או לשימוש בסשנים עם ממשקי REST או RPC API.

ההמלצות האלה רלוונטיות רק אם אתם מפתחים ספריית לקוח, או אם אתם משתמשים בממשקי REST/RPC API. אם אתם משתמשים באחת מספריות הלקוח של Google ל-Spanner, כדאי לעיין במאמר שיטות מומלצות לשימוש בספריות לקוח של Google.

יצירה של מאגר סשנים והגדרת הגודל שלו

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

טיפול בסשנים שנמחקו

יש שלוש דרכים למחוק סשן:

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

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

איך שומרים על סשן לא פעיל

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

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

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

הסתרת פרטי הסשן מהמשתמש בספריית הלקוח

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

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

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

אלה דרכים אפשריות לטפל בתרחיש הזה כשמטמיעים ספריית לקוח משלכם או משתמשים ב-API בארכיטקטורת REST:

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

שמירה על חיבורים יציבים

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

מעקב אחרי סשנים פעילים

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

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

מידע נוסף על השימוש ב-ListSessions זמין במאמרי העזרה בנושא הפניית API בארכיטקטורת REST, ‏הפניית API של RPC או הפניית כלי שורת הפקודה של gcloud.

ניקוי אוטומטי של דליפות בסשן

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

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

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

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

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

Java

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

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnAndCloseIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

כדי לקבל רק יומני אזהרה, משתמשים ב-setWarnIfInactiveTransactions.

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

Go

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

 client, err := spanner.NewClientWithConfig(
     ctx, database, spanner.ClientConfig{SessionPoolConfig: spanner.SessionPoolConfig{
         InactiveTransactionRemovalOptions: spanner.InactiveTransactionRemovalOptions{
         ActionOnInactiveTransaction: spanner.WarnAndClose,
         }
     }},
 )
 if err != nil {
     return err
 }
 defer client.Close()

כדי לקבל רק יומני אזהרה, משתמשים בפונקציה customLogger.

 customLogger := log.New(os.Stdout, "spanner-client: ", log.Lshortfile)
 // Create a logger instance using the golang log package
 cfg := spanner.ClientConfig{
         Logger: customLogger,
     }
 client, err := spanner.NewClientWithConfig(ctx, db, cfg)

סשנים מרובי-ערוצים

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

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

הסשנים המרובבים נתמכים במוצרים הבאים:

  • ספריות הלקוח של C++‎,‏ Go,‏ Java,‏ Node.js,‏ PHP,‏ Python ו-Ruby.

  • כלים במערכת האקולוגית של Spanner שתלויים בספריות הלקוח שצוינו, כמו PGAdapter, ‏ JDBC, ‏ Hibernate, ‏ database/sql driver, ‏ dbAPI driver ו-GORM.

  • כלים במערכת האקולוגית של Spanner שתלויים בספריות הלקוח של Java ו-Go, כמו PGAdapter,‏ JDBC,‏ Hibernate, מנהל מסדי נתונים או מנהל SQL ו-GORM. אתם יכולים להשתמש במדדים של OpenTelemetry כדי לראות איך התנועה מתחלקת בין מאגר הסשנים הקיים לבין הסשן המרובה. ל-OpenTelemetry יש מסנן מדדים, is_multiplexed, שמציג סשנים מרובי-ערוצים כשהוא מוגדר ל-true.

יש תמיכה בסשנים מרובי-ערוצים בכל סוגי הטרנזקציות.

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

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

לתשומת ליבכם

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

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

הפעלת סשנים מרובים

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

  • ‫C++ בגרסה 2.41.0 ואילך.
  • בגרסה 1.85.0 ואילך.
  • ‫Java בגרסה 6.98.0 ואילך.
  • ‫Node.js בגרסה 8.3.0 ואילך.
  • ‫PHP בגרסה 2.0.0 ואילך.
  • ‫Python בגרסה 3.57.0 ואילך.
  • ‫Ruby בגרסה 2.30.0 ואילך.

כדי להשתמש בסשנים מרובי-ערוצים בגרסאות קודמות של ספריות הלקוח של Node.js,‏ Java ו-Go, צריך קודם להגדיר משתנה סביבה כדי להפעיל את התכונה.

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

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS=TRUE

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

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_PARTITIONED_OPS=TRUE

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

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_FOR_RW=True

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

צפייה בתנועה של סשנים רגילים וסשנים מרובי-ערוצים

ב-OpenTelemetry יש מסנן is_multiplexed להצגת התנועה בסשנים מרובי-ערוצים. כדי לראות סשנים רגילים, מגדירים את המסנן הזה לערך true to view multiplexed sessions andfalse`.

  1. מגדירים את OpenTelemetry ל-Spanner באמצעות ההוראות שבקטע Before you begin (לפני שמתחילים) במאמר בנושא Spanner OpenTelemetry.

  2. עוברים אל Metrics Explorer.

    לדף Metrics Explorer

  3. בתפריט הנפתח מדד, מסננים לפי generic.

  4. לוחצים על Generic Task ועוברים אל Spanner > Spanner/num_acquired_sessions.

  5. בשדה Filter, בוחרים מבין האפשרויות הבאות:

    א. ‫is_multiplexed = false כדי לראות סשנים רגילים. ב. ‫is_multiplexed = true כדי לראות סשנים מרובי-ערוצים.

    בתמונה הבאה מוצגת האפשרות Filter עם בחירה של הפעלות מרובות.

מידע נוסף על שימוש ב-OpenTelemetry עם Spanner זמין במאמרים Leveraging OpenTelemetry to democratize Spanner Observability ו-Examine latency in a Spanner component with OpenTelemetry.

לוח בקרה של Opentelemetry שבו מוצג המסנן is-multiplexed.

פתרון בעיות

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

  • Session not found
  • RESOURCE_EXHAUSTED

מידע נוסף זמין במאמר בנושא שגיאות בסשן.