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