להבין שאילתות בזמן אמת בקנה מידה נרחב

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

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

בקטעים הבאים מפורטות המלצות להתאמת האפליקציה לעומס.

בחירת מיקום מסד נתונים שקרוב למשתמשים

בתרשים הבא מוצגת הארכיטקטורה של אפליקציה בזמן אמת:

דוגמה לארכיטקטורה של אפליקציות בזמן אמת

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

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

תכנון תוך שמירה על אמינות

הנושאים הבאים משפרים את האמינות של האפליקציה או משפיעים עליה:

הפעלת מצב אופליין

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

הסבר על ניסיונות חוזרים אוטומטיים

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

בחירה בין מיקומים אזוריים לבין מיקומים מרובים

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

הסבר על מערכת השאילתות בזמן אמת

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

נניח ששני משתמשים מתחברים אל Cloud Firestore באמצעות הודעה שפותח באמצעות אחת מערכות ה-SDK לנייד.

לקוח א' כותב למסד הנתונים כדי להוסיף ולעדכן מסמכים באוסף שנקרא chatroom:

collection chatroom:
    document message1:
      from: 'Sparky'
      message: 'Welcome to Cloud Firestore!'

    document message2:
      from: 'Santa'
      message: 'Presents are coming'

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

הארכיטקטורה של קישור ל-snapshot של Listener

רצף האירועים הבא מתרחש כשלקוח ב' מחבר תמונת מצב למסד הנתונים:

  1. לקוח ב' פותח חיבור אל Cloud Firestore ורושם מאזינים על ידי ביצוע קריאה ל-onSnapshot(collection("chatroom")) באמצעות Firebase SDK. המאזינים האלה יכולים להישאר פעילים למשך שעות.
  2. החזית של Cloud Firestore שולחת שאילתה למערכת האחסון הבסיסית כדי לאתחל את מערך הנתונים. הוא טוען את כל קבוצת התוצאות של מסמכים. אנחנו מכנים זאת שאילתה לבדיקה. לאחר מכן המערכת מעריכה את מסד הנתונים כללי אבטחה של Firebase: מוודאים שלמשתמש יש גישה לנתונים האלה. אם המשתמש מורשה, מסד הנתונים מחזיר את הנתונים למשתמש.
  3. לאחר מכן, השאילתה של לקוח ב' עוברת למצב הקשבה. המאזין מתעדכן אצל מנהל המינוי וממתין לעדכונים בנתונים.
  4. לקוח א' שולח עכשיו פעולת כתיבה כדי לשנות מסמך.
  5. מסד הנתונים מבצע את השינויים במסמך במערכת האחסון שלו.
  6. מבחינה טרנזקטיבית, המערכת מבצעת את אותו עדכון לעדכון פנימי יומן שינויים. יומן השינויים קובע סדר קפדני של שינויים זה קורה.
  7. יומן השינויים משלים את הנתונים המעודכנים למאגר מינויים של ה-handlers שלו.
  8. מתבצע התאמה לשאילתה הפוכה כדי לבדוק אם המסמך המעודכן תואם כל אוזן ה-snapshot שרשומה כרגע. בדוגמה הזו, המסמך תואם למאזין של קובץ ה-snapshot של לקוח ב'. כפי שמרמז השם, אפשר לחשוב על התאמה של שאילתה הפוכה כשאילתה רגילה של מסד נתונים, אבל נעשה בהפוכה. במקום לחפש במסמכים כדי למצוא מסמכים שתואמים לשאילתה, הוא מחפש ביעילות כדי למצוא את השאילתות שתואמות למסמך נכנס. כשמצאנו התאמה, המערכת מעבירה את המסמך הרלוונטי לרכיבי ה-snapshot. לאחר מכן המערכת בודקת את כללי האבטחה של Firebase במסד הנתונים. כדי לוודא שרק משתמשים מורשים יקבלו את הנתונים.
  9. המערכת מעבירה את עדכון המסמך ל-SDK במכשיר של לקוח ב', ולאחר מכן הקריאה החוזרת של onSnapshot מופעלת. אם תכונת העקביות המקומית מופעלת, ה-SDK מחילה את העדכון גם על המטמון המקומי.

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

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

יישום שיטות מומלצות לשיפור שאילתות בזמן אמת

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

להבין את תנועת הכתיבה הגבוהה במערכת

הקטע הזה עוזר להבין איך המערכת מגיבה לעלייה מספר בקשות הכתיבה.

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

ארכיטקטורה של מאוורר-יומן שינויים

התאמה לעומס (auto-scaling) מאפשרת לכם להגדיל את תעבורת נתוני הכתיבה שלכם ללא הגבלה, אבל כשנפח התנועה גדל, יכול להיות שייקח למערכת זמן מה להגיב. פועלים לפי ההמלצות של כלל 5-5-5 כדי להימנע מיצירה של נקודת אינטרנט לכתיבה. Key Visualizer הוא כלי שימושי לניתוח נקודות חמות לכתיבה.

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

הסבר על האינטראקציה בין פעולות הכתיבה לפעולות הקריאה

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

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

שמירה על מסמכים ופעולות כתיבה קטנות

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

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

שימוש ברכיבי listener יעילים

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

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

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

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

שימוש מהיר בשאילתות סקרים

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

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

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

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

העדפה למאזינים לטווח ארוך

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

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

המאמרים הבאים