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

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

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

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

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

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

מזהי מסמכים

  • הימנע מזהי המסמכים . ו ..
  • הימנע משימוש / העברה באלכסונים במזהי מסמכים.
  • אל תשתמש במזהי מסמכים בעלי הגדלה מונוטונית כגון:

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

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

שמות שדות

  • הימנע מהתווים הבאים בשמות שדות מכיוון שהם דורשים אסקייפ נוסף:

    • . פרק זמן
    • [ סוגר שמאל
    • ] סוגר ימין
    • * כוכבית
    • ` תקתק לאחור

אינדקסים

הפחת את זמן השהייה בכתיבה

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

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

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

פטורים ממדדים

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

מקרה תיאור
שדות מיתר גדולים

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

שיעורי כתיבה גבוהים לאוסף המכיל מסמכים עם ערכים עוקבים

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

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

שדות TTL

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

מערך גדול או שדות מפה

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

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

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

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

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

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

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

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

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

עיצוב לפי קנה מידה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 אולי לא תוכל להכין ביעילות את האוסף החדש לתעבורה מוגברת, במיוחד כאשר הוא מכיל מעט מסמכים.

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

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

קריאה מקבילה

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

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

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

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

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

פְּרָטִיוּת

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

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

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

למידע נוסף על שימוש בכללי האבטחה של Cloud Firestore .