קרא את המסמך הזה לקבלת הדרכה לגבי שינוי קנה המידה של האפליקציה ללא שרת שלך מעבר לאלפי פעולות בשנייה או למאות אלפי משתמשים במקביל. מסמך זה כולל נושאים מתקדמים שיעזרו לך להבין את המערכת לעומק. אם אתה רק מתחיל עם Cloud Firestore, עיין במדריך ההתחלה המהירה במקום זאת.
Cloud Firestore ו-SDK של Firebase לנייד/אינטרנט מספקים מודל רב עוצמה לפיתוח אפליקציות ללא שרתים שבהם קוד בצד הלקוח ניגש ישירות למסד הנתונים. ה-SDKs מאפשרים ללקוחות להאזין לעדכונים לנתונים בזמן אמת. אתה יכול להשתמש בעדכונים בזמן אמת כדי לבנות אפליקציות רספונסיביות שאינן דורשות תשתית שרת. אמנם קל מאוד להפעיל משהו, אבל זה עוזר להבין את האילוצים במערכות המרכיבות את Cloud Firestore, כך שהאפליקציה ללא שרת שלך מתרחבת ומתפקדת היטב כשהתנועה גדלה.
עיין בסעיפים הבאים לקבלת עצות לגבי שינוי קנה המידה של האפליקציה שלך.
בחר מיקום מסד נתונים קרוב למשתמשים שלך
התרשים הבא מדגים את הארכיטקטורה של אפליקציה בזמן אמת:
כאשר אפליקציה שפועלת במכשיר של משתמש (נייד או אינטרנט) יוצרת חיבור ל-Cloud Firestore, החיבור מנותב לשרת חזיתי של Cloud Firestore באותו אזור שבו נמצא מסד הנתונים שלך. לדוגמה, אם מסד הנתונים שלך נמצא ב- us-east1 , החיבור עובר גם ל-frontend של Cloud Firestore גם ב- us-east1 . חיבורים אלה מאריכים ימים ונשארים פתוחים עד לסגירה מפורשת על ידי האפליקציה. ה-frontend קורא נתונים ממערכות האחסון הבסיסיות של Cloud Firestore.
המרחק בין המיקום הפיזי של המשתמש למיקום מסד הנתונים של Cloud Firestore משפיע על זמן ההשהיה שחווה המשתמש. לדוגמה, משתמש בהודו שהאפליקציה שלו מדברת עם מסד נתונים באזור Google Cloud בצפון אמריקה עשוי למצוא את החוויה איטית יותר והאפליקציה פחות קלה מאשר אם מסד הנתונים היה ממוקם קרוב יותר, כגון בהודו או בחלק אחר של אסיה .
עיצוב לאמינות
הנושאים הבאים משפרים או משפיעים על מהימנות האפליקציה שלך:
הפעל מצב לא מקוון
ערכות ה-SDK של Firebase מספקות התמדה של נתונים לא מקוונים. אם האפליקציה במכשיר של המשתמש לא יכולה להתחבר ל-Cloud Firestore, האפליקציה נשארת שמישה על ידי עבודה עם נתונים שמור מקומיים. זה מבטיח גישה לנתונים גם כאשר משתמשים חווים חיבורי אינטרנט נקודתיים או מאבדים לחלוטין גישה במשך מספר שעות או ימים. לפרטים נוספים על מצב לא מקוון, ראה הפעלת נתונים לא מקוונים .
הבן ניסיונות חוזרים אוטומטיים
ערכות ה-SDK של Firebase דואגות לניסיון חוזר של פעולות וליצור מחדש חיבורים שבורים. זה עוזר לעקוף שגיאות חולפות הנגרמות כתוצאה מהפעלה מחדש של שרתים או בעיות רשת בין הלקוח למסד הנתונים.
בחר בין מיקומים אזוריים ורב-אזוריים
ישנן מספר פשרות בעת בחירה בין מיקומים אזוריים ורב-אזוריים. ההבדל העיקרי הוא איך הנתונים משוכפלים. זה מניע את ערבויות הזמינות של האפליקציה שלך. מופע מרובה אזורים נותן אמינות הגשה חזקה יותר ומגביר את העמידות של הנתונים שלך, אך ההחלפה היא עלות.
הבן את מערכת השאילתות בזמן אמת
שאילתות בזמן אמת, הנקראות גם מאזינים ל-Snapshot, מאפשרות לאפליקציה להאזין לשינויים במסד הנתונים ולקבל התראות עם אחזור נמוך ברגע שהנתונים משתנים. אפליקציה יכולה לקבל את אותה תוצאה על ידי בדיקת מסד נתונים מעת לעת לעדכונים, אך לרוב היא איטית יותר, יקרה יותר ודורשת יותר קוד. לדוגמאות כיצד להגדיר ולהשתמש בשאילתות בזמן אמת, ראה קבלת עדכונים בזמן אמת . הסעיפים הבאים מתייחסים לפרטים כיצד פועלים מאזיני תמונת מצב ומתארים כמה מהשיטות המומלצות להגדלת שאילתות בזמן אמת תוך שמירה על ביצועים.
תארו לעצמכם שני משתמשים שמתחברים ל-Cloud Firestore דרך אפליקציית הודעות שנבנתה עם אחת מה-SDKs לנייד.
לקוח א' כותב למסד הנתונים כדי להוסיף ולעדכן מסמכים באוסף הנקרא chatroom :
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
לקוח ב' מאזין לעדכונים באותו אוסף באמצעות מאזין תמונת מצב. לקוח ב' מקבל הודעה מיידית בכל פעם שמישהו יוצר הודעה חדשה. התרשים הבא מציג את הארכיטקטורה מאחורי מאזין תמונת מצב:
רצף האירועים הבא מתרחש כאשר לקוח B מחבר מאזין תמונת מצב למסד הנתונים:
- לקוח B פותח חיבור ל-Cloud Firestore ורושם מאזין על ידי ביצוע קריאה ל-
onSnapshot(collection("chatroom"))דרך ה-SDK של Firebase. המאזין הזה יכול להישאר פעיל במשך שעות. - ממשק ה-Cloud Firestore שואל את מערכת האחסון הבסיסית כדי לאתחל את מערך הנתונים. הוא טוען את כל סט התוצאות של מסמכים תואמים. אנו מתייחסים לזה כאל שאילתת סקר . לאחר מכן המערכת מעריכה את כללי האבטחה של מסד הנתונים של Firebase כדי לוודא שהמשתמש יכול לגשת לנתונים אלה. אם המשתמש מורשה, מסד הנתונים מחזיר את הנתונים למשתמש.
- השאילתה של לקוח ב' עוברת למצב האזנה . המאזין נרשם אצל מטפל מנויים וממתין לעדכונים לנתונים.
- לקוח א' שולח כעת פעולת כתיבה לשינוי מסמך.
- מסד הנתונים מחייב את שינוי המסמך למערכת האחסון שלו.
- מבחינה עסקית, המערכת מתחייבת את אותו עדכון ליומן שינויים פנימי. יומן השינויים קובע סדר קפדני של שינויים בזמן שהם קורים.
- יומן השינויים בתורו מפיץ את הנתונים המעודכנים למאגר של מטפלי מנויים.
- תואם שאילתה הפוכה מופעל כדי לראות אם המסמך המעודכן תואם למאזיני תמונת מצב הרשומים כעת. בדוגמה זו, המסמך תואם למאזין תמונת המצב של לקוח ב'. כפי שהשם מרמז, אתה יכול לחשוב על תואם השאילתה ההפוכה כעל שאילתת מסד נתונים רגילה אך נעשה הפוך. במקום לחפש במסמכים כדי למצוא את אלה התואמים לשאילתה, הוא מחפש ביעילות בשאילתות כדי למצוא את אלה שתואמות למסמך נכנס. עם מציאת התאמה, המערכת מעבירה את המסמך המדובר למאזיני תמונת המצב. לאחר מכן המערכת מעריכה את כללי האבטחה של מסד הנתונים של Firebase כדי להבטיח שרק משתמשים מורשים מקבלים את הנתונים.
- המערכת מעבירה את עדכון המסמך ל-SDK במכשיר של לקוח ב', וההתקשרות חוזרת
onSnapshotמופעלת. אם התמדה מקומית מופעלת, ה-SDK מחיל את העדכון גם על המטמון המקומי.
חלק מרכזי במידת המדרגיות של Cloud Firestore תלוי בהנפקה מיומן השינויים למטפלי המנויים ולשרתי החזית. המניפה מאפשרת לשנות נתונים בודדים כדי להתפשט ביעילות כדי לשרת מיליוני שאילתות בזמן אמת ומשתמשים מחוברים. על ידי הפעלת העתקים רבים של כל הרכיבים הללו על פני מספר אזורים (או אזורים מרובים במקרה של פריסה מרובת אזורים), Cloud Firestore משיגה זמינות גבוהה ומדרגיות.
ראוי לציין שכל פעולות הקריאה המונפקות מ-SDKs לנייד ולאינטרנט עוקבות אחר המודל שלמעלה. הם מבצעים שאילתת סקר ואחריה מצב האזנה כדי לשמור על הבטחות עקביות. זה חל גם על מאזינים בזמן אמת, שיחות לאחזור מסמך ושאילתות חד פעמיות . אתה יכול לחשוב על שליפות מסמכים בודדים ושאילתות חד פעמיות כעל מאזיני תמונת מצב קצרי מועד שמגיעים עם אילוצים דומים סביב ביצועים.
החל שיטות עבודה מומלצות להגדלת שאילתות בזמן אמת
יישם את השיטות המומלצות הבאות לעיצוב שאילתות בזמן אמת ניתנות להרחבה.
הבן תעבורת כתיבה גבוהה במערכת
סעיף זה עוזר לך להבין כיצד המערכת מגיבה למספר הולך וגדל של בקשות כתיבה.
יומני השינויים של Cloud Firestore שמניעים את השאילתות בזמן אמת מותאמים אוטומטית לרוחב ככל שתעבורת הכתיבה עולה. ככל שקצב הכתיבה של מסד נתונים עולה מעבר למה ששרת בודד יכול להתמודד, יומן השינויים מפוצל על פני מספר שרתים, ועיבוד השאילתות מתחיל לצרוך נתונים ממספר מטפלי מנויים במקום אחד. מנקודת המבט של הלקוח ושל SDK, כל זה שקוף ולא נדרשת פעולה מהאפליקציה כאשר מתרחשים פיצולים. התרשים הבא מדגים כיצד מתרחבים שאילתות בזמן אמת:
קנה מידה אוטומטי מאפשר לך להגדיל את תעבורת הכתיבה שלך ללא הגבלה, אך ככל שהתנועה מתגברת, ייתכן שלמערכת ייקח זמן מה להגיב. פעל לפי ההמלצות של כלל 5-5-5 כדי להימנע מיצירת נקודה חמה לכתיבה. Key Visualizer הוא כלי שימושי לניתוח נקודות כתיבה חמות.
לאפליקציות רבות יש צמיחה אורגנית צפויה, אשר Cloud Firestore יכולה להכיל ללא אמצעי זהירות. עם זאת, עומסי עבודה אצווה כמו ייבוא מערך נתונים גדול יכולים להגביר את הכתיבה מהר מדי. בזמן שאתה מעצב את האפליקציה שלך, הישאר מודע מאיפה מגיעה תעבורת הכתיבה שלך.
להבין איך כותבים וקריאה מתקשרים
אתה יכול לחשוב על מערכת השאילתות בזמן אמת כעל צינור המחבר בין פעולות כתיבה לקוראים. בכל פעם שמסמך נוצר, מתעדכן או נמחק, השינוי מתפשט ממערכת האחסון אל המאזינים הרשומים כעת. מבנה יומן השינויים של Cloud Firestore מבטיח עקביות חזקה, מה שאומר שהאפליקציה שלך לעולם לא מקבלת התראות על עדכונים שאינם תקינים בהשוואה למועד שבו מסד הנתונים ביצע את השינויים בנתונים. זה מפשט את פיתוח האפליקציה על ידי הסרת מקרי קצה סביב עקביות נתונים.
צינור מחובר זה אומר שפעולת כתיבה הגורמת לנקודות חמות או מחלוקת נעילה יכולה להשפיע לרעה על פעולות הקריאה. כאשר פעולות הכתיבה נכשלות או חווית צער, קריאה עלולה להיתקע בהמתנה לנתונים עקביים מיומן השינויים. אם זה קורה באפליקציה שלך, ייתכן שתראה גם פעולות כתיבה איטיות וגם זמני תגובה איטיים בקורלציה לשאילתות. הימנעות מנקודות חמות היא המפתח להתרחקות מבעיה זו.
שמור מסמכים וכתוב פעולות קטנות
בעת בניית אפליקציות עם מאזינים לצילום מצב, אתה בדרך כלל רוצה שהמשתמשים יגלו על שינויים בנתונים במהירות. כדי להשיג זאת, נסה לשמור על דברים קטנים. המערכת יכולה לדחוף מסמכים קטנים עם עשרות שדות דרך המערכת במהירות רבה. עיבוד מסמכים גדולים יותר עם מאות שדות ונתונים גדולים לוקח זמן רב יותר.
כמו כן, העדיפו פעולות התחייבות וכתיבה קצרות ומהירות כדי לשמור על זמן אחזור נמוך. קבוצות גדולות עשויות להעניק לך תפוקה גבוהה יותר מנקודת המבט של הכותב, אך עשויות למעשה להגדיל את זמן ההתראה עבור מאזיני תמונת מצב. לעתים קרובות זה מנוגד לאינטואיציה בהשוואה לשימוש במערכות מסד נתונים אחרות שבהן אתה עשוי להשתמש באצווה כדי לשפר את הביצועים.
השתמש במאזינים יעילים
ככל שקצב הכתיבה של מסד הנתונים שלך עולה, Cloud Firestore מפצל את עיבוד הנתונים על פני שרתים רבים. אלגוריתם הריסוק של Cloud Firestore מנסה לאתר נתונים מאותו אוסף או קבוצת איסוף על אותו שרת Changelog. המערכת מנסה למקסם את תפוקת הכתיבה האפשרית תוך שמירה על מספר השרתים המעורבים בעיבוד שאילתה נמוך ככל האפשר.
עם זאת, דפוסים מסוימים עשויים עדיין להוביל להתנהגות לא אופטימלית עבור מאזיני תמונת מצב. לדוגמה, אם האפליקציה שלך מאחסנת את רוב הנתונים שלה באוסף גדול אחד, ייתכן שהמאזין יצטרך להתחבר לשרתים רבים כדי לקבל את כל הנתונים שהוא צריך. זה נשאר נכון גם אם תחיל מסנן שאילתות. חיבור לשרתים רבים מגביר את הסיכון לתגובות איטיות יותר.
כדי להימנע מתגובות איטיות יותר אלו, עצב את הסכימה והאפליקציה שלך כך שהמערכת תוכל לשרת את המאזינים מבלי לעבור לשרתים רבים ושונים. זה עשוי לעבוד הכי טוב לחלק את הנתונים שלך לאוספים קטנים יותר עם קצבי כתיבה קטנים יותר.
זה דומה לחשיבה על שאילתות הביצועים במסד נתונים יחסי הדורשים סריקות טבלה מלאות. במסד נתונים רלציוני, שאילתה הדורשת סריקת טבלה מלאה היא המקבילה למאזין תמונת מצב שצופה באוסף בעל נטייה גבוהה. הוא עשוי להופיע באיטיות בהשוואה לשאילתה שמסד הנתונים יכול לשרת באמצעות אינדקס ספציפי יותר. שאילתה עם אינדקס ספציפי יותר היא כמו מאזין תמונת מצב שצופה במסמך בודד או באוסף שמשתנה בתדירות נמוכה יותר. עליך לטעון את האפליקציה שלך כדי להבין בצורה הטובה ביותר את ההתנהגות והצורך של מקרה השימוש שלך.
שמור על שאילתות סקר במהירות
חלק מרכזי נוסף בשאילתות רספונסיביות בזמן אמת כולל לוודא ששאילתת הסקרים לאתחול הנתונים היא מהירה ויעילה. בפעם הראשונה שמאזין תמונת מצב חדש מתחבר, על המאזין לטעון את כל ערכת התוצאות ולשלוח אותה למכשיר של המשתמש. שאילתות איטיות הופכות את האפליקציה שלך לפחות מגיבה. זה כולל, למשל, שאילתות המנסות לקרוא מסמכים רבים או שאילתות שאינן משתמשות באינדקסים המתאימים.
מאזין עשוי גם לעבור חזרה ממצב האזנה למצב סקרים בנסיבות מסוימות. זה קורה באופן אוטומטי ושקוף ל-SDKs ולאפליקציה שלך. התנאים הבאים עשויים להפעיל מצב סקרים:
- המערכת מאזנת מחדש יומן שינויים עקב שינויים בעומס.
- נקודות חמות גורמות לכתיבה כושלת או לעיכוב במסד הנתונים.
- הפעלה מחדש של שרת חולפת משפיעה באופן זמני על המאזינים.
אם שאילתות הסקרים שלך מהירות מספיק, מצב סקרים הופך שקוף למשתמשי האפליקציה שלך.
העדיפו מאזינים ארוכים
פתיחה והשארת מאזינים בחיים זמן רב ככל האפשר היא לרוב הדרך המשתלמת ביותר לבנות אפליקציה המשתמשת ב-Cloud Firestore. בעת שימוש ב-Cloud Firestore, אתה מחויב עבור המסמכים המוחזרים לאפליקציה שלך ולא עבור שמירה על חיבור פתוח. מאזין תמונת מצב ארוכת חיים קורא רק את הנתונים הדרושים לו כדי לשרת את השאילתה לאורך כל חייו. זה כולל פעולת סקר ראשונית ולאחריה הודעות כאשר הנתונים משתנים בפועל. מצד שני, שאילתות חד-פעמיות קוראים מחדש נתונים שאולי לא השתנו מאז שהאפליקציה ביצעה את השאילתה האחרונה.
במקרים שבהם האפליקציה שלך חייבת לצרוך קצב נתונים גבוה, ייתכן שמאזיני תמונת מצב אינם מתאימים. לדוגמה, אם מקרה השימוש שלך דוחף מסמכים רבים בשנייה דרך חיבור לפרק זמן ממושך, אולי עדיף לבחור בשאילתות חד פעמיות הפועלות בתדירות נמוכה יותר.
מה הלאה
- למד כיצד להשתמש במאזינים של תמונת מצב .
- קרא על שיטות עבודה מומלצות נוספות.