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