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

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

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

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

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

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

מזהי מסמכים

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

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

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

שמות שדות

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

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

אינדקסים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המלצה פרטים
הפחת את קצב הנטישה של מאזינים של תמונת מצב

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

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

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

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

הגבל מאזיני תמונת מצב ללקוח

100

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

הגבל את קצב כתיבת האוסף

1,000 פעולות לשנייה

שמור את קצב פעולות הכתיבה עבור אוסף בודד מתחת ל-1,000 פעולות לשנייה.

הגבל את קצב הדחיפה של הלקוח הבודד

מסמך 1/שנייה

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

הגבל את קצב הדחיפה העולמי של הלקוח

1,000,000 מסמכים לשנייה

שמור על קצב המסמכים שמסד הנתונים דוחף לכל הלקוחות מתחת ל-1,000,000 מסמכים לשנייה.

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

הגבל את מטען המסמכים הבודדים

10 KiB/שנייה

שמור את גודל המסמך המרבי שהורד על ידי לקוח בודד מתחת ל-10 KiB/שנייה.

הגבל את עומס המסמכים הגלובלי

1 GiB/שנייה

שמור את גודל המסמך המרבי שהוורד בכל הלקוחות מתחת ל-1 GiB/שנייה.

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

100

המסמכים שלך צריכים לכלול פחות מ-100 שדות.

הבן את המגבלות הסטנדרטיות של Cloud Firestore

זכור את המגבלות הסטנדרטיות עבור Cloud Firestore .

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

פונקציות ענן

הפעלת פונקציית ענן עם יותר מ-2,000 אירועי 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 .