בדף הזה מתוארים התנגשות נתונים טרנזקציוניים, אפשרות להרצה טורית ובידוד. דוגמאות קוד של טרנזקציות זמינות במאמר בנושא טרנזקציות וכתיבות באצווה.
טרנזקציות ועימות נתונים
כדי שעסקה תצליח, המסמכים שאוחזרו על ידי פעולות הקריאה שלה צריכים להישאר ללא שינוי על ידי פעולות מחוץ לעסקה. אם פעולה אחרת מנסה לשנות אחד מהמסמכים האלה, הפעולה הזו נכנסת למצב של התנגשות נתונים עם העסקה.
- התנגשות נתונים
- כששתי פעולות או יותר מתחרות על השליטה באותו מסמך. לדוגמה, יכול להיות שנדרש לשמור על עקביות של מסמך מסוים בזמן שמבצעים פעולה מקבילה שמנסה לעדכן את ערכי השדות של המסמך הזה.
Cloud Firestore resolves data contention by delaying or failing one of the operations. Cloud Firestore ספריות הלקוח מנסות באופן אוטומטי לבצע מחדש טרנזקציות שנכשלות בגלל התנגשות נתונים. אחרי מספר סופי של ניסיונות חוזרים, פעולת העסקה נכשלת ומוחזרת הודעת שגיאה:
ABORTED: Too much contention on these documents. Please try again.
כשמחליטים איזו פעולה תיכשל או תתעכב, ההתנהגות תלויה בסוג של אמצעי הבקרה של הגישה בו-זמנית.
אמצעי בקרה לבו-זמניות
מצב הבו-זמניות הוא אפשרות להגדרה במסד הנתונים. Cloud Firestore תומך במצבי הבו-זמניות הבאים:
PESSIMISTIC: אמצעי בקרה אופטימיים של פעולות בו-זמניות מניחים שסביר להניח שיהיו התנגשויות בנתונים. בטרנזקציות פסימיות נעשה שימוש בנעילות של מסדי נתונים כדי למנוע מפעולות אחרות לשנות את הנתונים.באמצעות אמצעי בקרה אופטימיים על מקביליות, טרנזקציות מציבות נעילות על המסמכים שהן קוראות. נעילה של מסמך על ידי טרנזקציה חוסמת טרנזקציות אחרות, כתיבות באצווה וכתיבות לא טרנזקציוניות מלשנות את המסמך הזה. A transaction releases its document locks at commit time. הוא גם משחרר את הנעילות שלו אם הוא מגיע לזמן קצוב או נכשל מסיבה כלשהי.
כשעסקה נועלת מסמך, פעולות כתיבה אחרות צריכות להמתין עד שהעסקה תשחרר את הנעילה. הנעילות של העסקאות מתבצעות לפי הסדר הכרונולוגי.
OPTIMISTIC: אמצעי בקרה אופטימיים של פעולות בו-זמניות מניחים שאין סיכוי גבוה למחלוקת על נתונים, או שלא יעיל להחזיק נעילות של מסד נתונים. בטרנזקציות אופטימיות לא נעשה שימוש בנעילות של מסדי נתונים כדי לחסום פעולות אחרות שמשנות נתוניםבאמצעות אמצעי בקרה אופטימיים של פעולות בו-זמניות, העסקה עוקבת אחרי כל המסמכים שקוראים בתוך העסקה. פעולות הכתיבה של העסקה יושלמו רק אם אף אחד מהמסמכים האלה לא השתנה במהלך ביצוע העסקה. אם חל שינוי במסמך כלשהו, המטפל בעסקאות מנסה שוב לבצע את העסקה. אם העסקה לא יכולה להניב תוצאה נקייה אחרי כמה ניסיונות חוזרים, העסקה נכשלת בגלל התנגשות נתונים.
הגדרות ברירת המחדל של מצב בו-זמניות
ערך ברירת המחדל במהדורת Standard הוא PESSIMISTIC. ערך ברירת המחדל במהדורת Enterprise הוא OPTIMISTIC. עם זאת, ההתנהגות תלויה גם בסוג ספריית הלקוח:
- ה-SDK לנייד ול-SDK לאינטרנט משתמשים בבקרות מקבילות אופטימיסטיות. ערכות ה-SDK לנייד ולאינטרנט פועלות באופן עצמאי מההגדרה הזו, כי הן תמיד מדמות אופטימיזציה של פעולות בו-זמנית.
- ספריות הלקוח של השרת משתמשות באמצעי בקרה של מקביליות בהגדרת מסד הנתונים.
הצגת מצב ההפעלה בו-זמנית
מריצים את הפקודה gcloud firestore databases describe כדי לראות את מצב המקבילות בצד השרת של מסד הנתונים:
gcloud firestore databases describe \
--project=PROJECT_ID \
--database=DATABASE_ID
שינוי מצב ההפעלה בו-זמנית
מריצים את הפקודה gcloud firestore databases update כדי לשנות את מצב הבו-זמניות בצד השרת של מסד הנתונים:
gcloud firestore databases update \
--project=PROJECT_ID \
--database=DATABASE_ID \
--concurrency-mode=CONCURRENCY_MODE
where:
- CONCURRENCY_MODE הוא
PESSIMISTICאוOPTIMISTIC. - PROJECT_ID הוא המזהה של פרויקט Google Cloud.
- DATABASE_ID הוא המזהה של מסד הנתונים Cloud Firestore.
התנגשות נתונים בערכות SDK לניידים ולאתרים
ערכות SDK לנייד ולאינטרנט מדמות טרנזקציות של אופטימיזציה של פעולות בו-זמניות באמצעות תנאים מוקדמים לכתיבה בגרסאות של מסמכים. האמולציה הזו מתרחשת ללא קשר להגדרת מצב הגישה המקבילית של מסד הנתונים. ערכות ה-SDK לנייד ולאינטרנט לא משתמשות בתכונה built-in transactions, ולכן גם אם מצב הבו-זמניות של מסד הנתונים מוגדר ל-PESSIMISTIC, לקוחות לנייד עדיין מתנהגים בצורה אופטימית.
ערכות SDK לנייד ולאינטרנט משתמשות באמצעי בקרה אופטימיים של פעולות מקבילות, כי הן יכולות לפעול בסביבות עם חביון גבוה וחיבור רשת לא אמין. נעילת מסמכים בסביבה עם זמן אחזור גבוה תגרום ליותר מדי כשלים בגלל התנגשות נתונים.
התנגשות נתונים בספריות הלקוח של השרת
ספריות לקוח של שרת (C#, Go, Java, Node.js, PHP, Python, Ruby) משתמשות בתכונה מוכללת של טרנזקציות. העסקאות האלה משתמשות בהגדרה של מצב מקביליות ברמת מסד הנתונים, וערך ברירת המחדל תלוי במהדורה:
מהדורת Enterprise משתמשת כברירת מחדל באמצעי בקרה אופטימיים של פעולות בו-זמניות כדי לתמוך בפעולות שסורקות אוספים שלמים. אמצעי בקרה אופטימיים של פעולות בו-זמניות עוזרים להימנע מפעולות סריקה שנועלות מספר גדול של מסמכים.
מהדורת Standard משתמשת באמצעים פסימיים לבקרת מקביליות, ומניחה שיש זמן אחזור נמוך וחיבור אמין למסד הנתונים.
בידוד ניתן לסריאליזציה
התחרות על נתונים בין טרנזקציות קשורה קשר הדוק לרמות הבידוד של מסד הנתונים. רמת הבידוד של מסד נתונים מתארת את היכולת של המערכת לטפל בקונפליקטים בין פעולות מקבילות. הבעיה נובעת מהדרישות הבאות של מסד הנתונים:
- כדי שהדיווח על עסקאות יהיה מדויק, הנתונים צריכים להיות מדויקים ועקביים.
- כדי להשתמש במשאבים בצורה יעילה, מסדי נתונים מבצעים פעולות במקביל.
במערכות עם רמת בידוד נמוכה, פעולת קריאה בתוך טרנזקציה עשויה לקרוא נתונים לא מדויקים משינויים שלא בוצעו בפעולה מקבילה.
בידוד ניתן לסדרות מגדיר את רמת הבידוד הגבוהה ביותר. בידוד מסוג Serializable פירושו:
- אפשר להניח שמסד הנתונים מבצע עסקאות בסדרה.
- שינויים שלא בוצעו בפעולות מקבילות לא משפיעים על עסקאות.
ההבטחה הזו צריכה להתקיים גם בזמן שמסד הנתונים מבצע כמה טרנזקציות במקביל. במסד הנתונים צריך להטמיע אמצעי בקרה של פעולות מקבילות כדי לפתור קונפליקטים שיפגעו בהבטחה הזו.
Cloud Firestore מבטיח בידוד של טרנזקציות שניתן לסדר אותן בסדרות. העסקאות ב-Cloud Firestore עוברות סריאליזציה ומבודדות לפי זמן ביצוע השינויים.
בידוד ניתן לסדר לפי זמן ביצוע (commit)
Cloud Firestore מקצה לכל עסקה זמן אישור שמייצג נקודה אחת בזמן. כשמשתמש Cloud Firestore מבצע פעולת אישור (commit) של שינויים בעסקה במסד הנתונים, אפשר להניח שכל פעולות הקריאה והכתיבה בתוך העסקה מתבצעות בדיוק בזמן האישור.
ביצוע בפועל של עסקה דורש פרק זמן מסוים. ההרצה של טרנזקציה מתחילה לפני זמן השמירה, וההרצה של כמה פעולות עשויה לחפוף. Cloud Firestore תומך בבידוד שניתן לסדר בסדרות ומבטיח את הדברים הבאים:
- Cloud Firestore מבצעת עסקאות לפי סדר הזמן של ביצוע השינויים.
- Cloud Firestore מבודד עסקאות מפעולות מקבילות עם זמן אישור מאוחר יותר.
במקרה של מחלוקת על נתונים בין פעולות מקבילות, Cloud Firestore משתמש בבקרת בו-זמניות אופטימית ופסימית כדי לפתור את המחלוקת.
בידוד בתוך טרנזקציה
רמת הבידוד של טרנזקציה חלה גם על פעולות כתיבה בתוך טרנזקציה. שאילתות ופעולות קריאה בתוך טרנזקציה לא רואות את התוצאות של פעולות כתיבה קודמות בתוך אותה טרנזקציה. גם אם משנים או מוחקים מסמך בתוך עסקה, כל פעולות הקריאה של המסמך בעסקה מחזירות את גרסת המסמך בזמן השמירה, לפני פעולות הכתיבה של העסקה. פעולות קריאה לא מחזירות כלום אם המסמך לא היה קיים באותו זמן.
בעיות שקשורות להתנגשות נתונים
מידע נוסף על התנגשות נתונים ועל פתרון בעיות מופיע בדף לפתרון בעיות.