יכולת סריאליזציה ובידוד של עסקאות

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

טרנזקציות ומאבק על נתונים

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

תחרות על נתונים

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

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

ABORTED: Too much contention on these documents. Please try again.

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

• ב-SDK לנייד או לאינטרנט נעשה שימוש באמצעי בקרה על עקביות אופטימיסטית.

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

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

התחרות על נתונים ב-SDK לנייד או לאינטרנט

ב-SDK לנייד או לאינטרנט (פלטפורמות של Apple, ‏ Android, ‏ Web, ‏ C++) נעשה שימוש באמצעי בקרה אופטימיים על בו-זמניות כדי לפתור מאבקי שליטה על נתונים.

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

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

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

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

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

ספריות הלקוח של השרת (C#‎,‏ Go, ‏ Java, ‏ Node.js, ‏ PHP, ‏ Python, ‏ Ruby) משתמשות באמצעי בקרה על בו-זמניות פסימיים כדי לפתור מאבקי שליטה על נתונים.

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

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

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

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

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

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

בידוד סריאליזציה

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

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

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

בידוד של Serializable מגדיר את רמת הבידוד הגבוהה ביותר. בידוד של סריאליזציה פירושו:

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

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

Cloud Firestore מבטיח בידוד של טרנזקציות שניתן לסדר. העסקאות ב-Cloud Firestore עוברות סריאליזציה והן מבודדות לפי זמן ההתחייבות.

בידוד של Serializable לפי זמן ההתחייבות

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

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

• Cloud Firestore מבצע את ההתחייבות לעסקאות לפי סדר זמן ההתחייבות.
• Cloud Firestore מבודד עסקאות מפעולות בו-זמניות עם זמן אישור מאוחר יותר.

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

בידוד בתוך טרנזקציה

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

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

בעיות במאבק על נתונים

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