כדי לעזור לכם להבין, לשפר ולאבחן בעיות בעסקאות, Spanner מאפשר לכם לגשת לנתונים סטטיסטיים של אישור עסקאות. נכון לעכשיו, אפשר לאחזר את המספר הכולל של מוטציות לעסקה.
מתי כדאי להשתמש בנתוני סטטוס של שליחת שינויים
הידיעה כמה מוטציות יש בטרנזקציה יכולה להיות שימושית בתרחישים הבאים.
אופטימיזציה של נסיעות הלוך ושוב
כדי לשפר את הביצועים של האפליקציה, אפשר לצמצם את מספר הנסיעות הלוך ושוב למסד הנתונים על ידי ביצוע כמה שיותר פעולות בכל טרנזקציה. במקרה כזה, כדאי להגדיל את מספר המוטציות לכל טרנזקציה, תוך שמירה על מגבלות המערכת.
כדי לקבוע כמה שורות אפשר לבצע בכל טרנזקציה בלי לחרוג מהמגבלה, קודם צריך לבצע שורה אחת בטרנזקציה. כך מקבלים קו בסיס של מספר המוטציות לכל שורה. לאחר מכן מחלקים את המגבלה של המערכת בערך הבסיסי כדי לקבל את מספר השורות לכל עסקה. מידע נוסף על אופן הספירה של מוטציות זמין בהערה הזו.
כשמשתמשים ב-DML, המגבלה של 80,000 (כולל אינדקסים) חלה על כל הצהרה, ולא על כל טרנזקציה. אפשר להריץ כמה הצהרות DML בעסקה אחת כדי לבצע יותר מ-80,000 שינויים, בכפוף למגבלת גודל העסקה של 100MiB. במקרה כזה, הערך mutation_count שמוחזר בנתוני הסטטיסטיקה של ה-commit משקף את סך המוטציות המצטברות (כולל אינדקסים) בכל ההצהרות, ויכול להיות גבוה מ-80,000.
חשוב לזכור: אופטימיזציה של נסיעות הלוך ושוב לא תמיד מועילה, במיוחד אם היא מובילה ליותר התנגשויות של נעילות. אפשר לפתור בעיות שקשורות לנעילות במסד הנתונים באמצעות נתונים סטטיסטיים על נעילות.
מעקב אחרי העסקאות כדי לא לחרוג ממגבלות המערכת
ככל שהשימוש באפליקציה גדל, יכול להיות שגם מספר השינויים בעסקה יגדל. כדי להימנע מהגעה למגבלת המערכת ומהמצב שבו העסקה תיכשל בסופו של דבר, אפשר לעקוב באופן יזום אחרי נתון הסטטיסטיקה של מספר השינויים שבוצעו לאורך זמן. אם אתם רואים שהערך הזה עולה עבור אותה עסקה, יכול להיות שהגיע הזמן לבצע אופטימיזציה מחדש של העסקה, כמו שמתואר בקטע הקודם.
איך ניגשים לסטטיסטיקות של פעולות Commit
כברירת מחדל, הסטטיסטיקה של פעולות ה-Commit לא מוחזרת. במקום זאת, צריך להגדיר את הדגל return_commit_stats לערך true בכל CommitRequest. אם אתם משתמשים ב-Mutation API וניסיון השמירה שלכם חורג ממספר המוטציות המקסימלי המותר (כולל אינדקסים), השמירה נכשלת ומוחזרת שגיאת INVALID_ARGUMENT. ב-DML, חריגה ממגבלת השינויים (כולל אינדקסים) גורמת לכך שפקודת ה-DML תיכשל במהלך ההרצה עם שגיאה BadUsage, במקום להיכשל בזמן השמירה.
הנה דוגמה להחזרת נתוני סטטיסטיקה של ביצוע פעולות (commit) באמצעות ספריות הלקוח של Spanner.
אחזור נתוני קומיטים
בדוגמה הבאה מוצג איך מקבלים נתונים סטטיסטיים של ביצוע פעולות Commit באמצעות ספריות הלקוח של Spanner.
C++
הקוד הבא קורא ל-set_return_stats() ב-CommitOptions ומחזיר ספירת מוטציות של 6, כי אנחנו מוסיפים או מעדכנים 2 שורות ו-3 עמודות בכל שורה.
C#
ב-C#, נתוני קומיטים לא מוחזרים ישירות דרך ה-API. במקום זאת, הם מתועדים ברמת היומן Information על ידי הכלי לתיוג היומנים שמוגדר כברירת מחדל.
הקוד הבא מפעיל רישום ביומן של נתוני אישור לכל העסקאות על ידי הגדרת המאפיין LogCommitStats ב-SpannerConnectionStringBuilder לערך true. הקוד גם מטמיע כלי לרישום פעולות לדוגמה, ששומר הפניה לתגובת השליחה האחרונה שנראתה. לאחר מכן, המערכת מאחזרת את MutationCount מהתשובה הזו ומציגה אותו.
המשך
הקוד הבא מגדיר את הדגל ReturnCommitStats ומדפיס את מספר השינויים כשמתבצעת התחייבות לעסקה בהצלחה.
Java
Node.js
הקוד הבא מגדיר את הדגל returnCommitStats ומחזיר את מספר השינויים 6, כי אנחנו מוסיפים או מעדכנים 2 שורות ו-3 עמודות בכל שורה.
PHP
Python
במקום להחזיר את נתוני השליחה ישירות דרך ה-API, ספריית הלקוח של Python מתעדת אותם באמצעות stdout ברמה Info.
הקוד הבא מאפשר רישום ביומן של נתונים סטטיסטיים לגבי ביצוע פעולות (commit) לכל העסקאות על ידי הגדרת database.log_commit_stats = True. הקוד גם מטמיע כלי לרישום ביומן לדוגמה, ששומר הפניה לתגובת השמירה האחרונה שנראתה. התשובה mutation_count מאוחזרת מהתגובה הזו ומוצגת.
Ruby
הקוד הבא מגדיר את הדגל return_commit_stats ומחזיר את מספר השינויים 6, כי אנחנו מוסיפים או מעדכנים 2 שורות ו-3 עמודות בכל שורה.