שיטות מומלצות עבור Cloud Firestore

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

מיקום מסד הנתונים

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

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

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

מזהי מסמכים

• אין להשתמש במזהי המסמכים . ו-...
• במזהי מסמכים אין להשתמש בקו נטוי / לפנים.

• אין להשתמש בהגדלת מזהי מסמכים באופן מונוטוני, כמו:

  • Customer1, Customer2, Customer3, ...
  • Product 1, Product 2, Product 3, ...

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

שמות שדות

• מומלץ להימנע משימוש בתווים הבאים בשמות השדות, מפני שהם דורשים תוספת Escape:

  • תקופה של .
  • [ סוגר מרובע שמאלי
  • ] סוגר מרובע ימני
  • כוכבית *
  • סימן דיאקריטי (`)

מדדים

מפחיתים את זמן האחזור לכתיבה

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

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

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

פטורים מאינדקס

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

פעולות קריאה וכתיבה

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

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

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

ניסיונות חוזרים של עסקאות

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

עדכונים בזמן אמת

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

תכנון לפי קנה מידה

השיטות המומלצות הבאות מתארות איך להימנע ממצבים ליצור בעיות שקשורות לטענות.

עדכונים למסמך יחיד

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

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

שיעורי קריאה, כתיבה ומחיקה גבוהים בטווח מצומצם של מסמכים

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

• יוצר מסמכים חדשים ברקצב גבוה ומקצה מזהי monotonically increasing משלו.

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

• יצירת מסמכים חדשים בקצב גבוה באוסף עם מעט מסמכים.

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

• מחיקה של מסמכים באוסף בקצב גבוה.

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

איך להימנע מדילוג על נתונים שנמחקו

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

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

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

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

כדי לשפר את הביצועים, כדאי להשתמש בשיטה start_at מקום להתחיל בו. לדוגמה:

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

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

הגדלת נפח התנועה

עליכם להגביר את התנועה בהדרגה לאוספים חדשים או באופן לקסיקוגרפי לסגור מסמכים כדי לתת לCloud Firestore מספיק זמן להתכונן מסמכים כדי להגדיל את התנועה. מומלץ להתחיל במקסימום 500 פעולות לשנייה באוסף חדש ואז הגדלת התנועה ב-50% כל 5 דקות. אפשר להגביר את תנועת הכתיבה באופן דומה, אבל חשוב לזכור המגבלות הרגילות של Cloud Firestore. חשוב שהפעולות יחולקו באופן שווה יחסית לאורך טווח המפתחות. הזה נקרא "500/50/5" כלל.

העברת תנועה לאוסף חדש

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

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

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

קריאות מקבילות

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

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

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

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

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

פרטיות

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

מניעת גישה לא מורשית

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

מידע נוסף על השימוש ב-Cloud Firestore Security Rules.