יש כמה דרכים שונות לשפר את הביצועים של Firebase Realtime Database באפליקציה. כדי לגלות מה אפשר לעשות כדי לשפר את הביצועים של Realtime Database, צריך לאסוף נתונים באמצעות כלי המעקב השונים של Realtime Database, ואז לבצע שינויים באפליקציה או בשימוש ב-Realtime Database בהתאם.
מעקב אחרי הביצועים של Realtime Database
אתם יכולים לאסוף נתונים על הביצועים של Realtime Database באמצעות כמה כלים שונים, בהתאם לרמת הפירוט שאתם צריכים:
- סקירה כללית ברמה גבוהה: השתמשו בכלי הפרופיילינג כדי לקבל רשימה של שאילתות שלא נוספו לאינדקס וסקירה כללית בזמן אמת של פעולות קריאה/כתיבה.
- הערכת השימוש לחיוב: אתם יכולים להשתמש במדדי השימוש שזמינים במסוף Firebase כדי לראות את השימוש לחיוב ואת מדדי הביצועים ברמה גבוהה.
- פירוט מעמיק: השתמשו ב-Cloud Monitoring כדי לבחון לעומק את הביצועים של מסד הנתונים לאורך זמן.
שיפור הביצועים לפי מדד
אחרי שאוספים את הנתונים, כדאי לעיין בשיטות המומלצות ובאסטרטגיות הבאות, בהתאם לתחום הביצועים שרוצים לשפר.
| שיטות לשיפור הביצועים בקצרה | ||
|---|---|---|
| מדד | תיאור | שיטות מומלצות |
| עומס/ניצול | לייעל את השימוש בקיבולת של מסד הנתונים לעיבוד בקשות בכל זמן נתון (הדבר משתקף במדדים **Load** או **io/database_load**). |
אופטימיזציה של מבנה הנתונים פיצול נתונים בין מסדי נתונים שיפור היעילות של המאזינים הגבלת ההורדות באמצעות כללים שמבוססים על שאילתות אופטימיזציה של החיבורים |
| חיבורים פעילים | כדי לא לחרוג ממגבלת 200, 000 החיבורים,צריך לאזן את מספר החיבורים הפעילים בו-זמנית למסד הנתונים. |
פיצול נתונים בין מסדי נתונים הפחתת מספר החיבורים החדשים |
| רוחב הפס לנתונים יוצאים | אם נראה שההורדות ממסד הנתונים גבוהות מהרצוי, אפשר לשפר את היעילות של פעולות הקריאה ולהפחית את התקורה של ההצפנה. |
אופטימיזציה של החיבורים אופטימיזציה של מבנה הנתונים הגבלת ההורדות באמצעות כללים שמבוססים על שאילתות שימוש חוזר בסשנים של SSL שיפור היעילות של המאזינים הגבלת הגישה לנתונים |
| אחסון | כדי לא לחרוג מהמכסה, חשוב לוודא שלא מאחסנים נתונים שלא בשימוש, או לאזן את הנתונים המאוחסנים בין מסדי נתונים אחרים או מוצרי Firebase. |
ניקוי נתונים שלא בשימוש אופטימיזציה של מבנה הנתונים פיצול נתונים בין מסדי נתונים שימוש ב-Cloud Storage for Firebase |
אופטימיזציה של החיבורים
בקשות RESTful כמו GET ו-PUT עדיין דורשות חיבור, למרות שהחיבור הזה קצר. החיבורים התכופים וקצרי-המועד האלה יכולים להצטבר לעלויות חיבור, עומס על מסד הנתונים ורוחב פס לנתונים יוצאים, שהם גבוהים משמעותית מאלה של חיבורים פעילים בזמן אמת למסד הנתונים.
בכל פעם שאפשר, השתמשו בערכות ה-SDK המקוריות של פלטפורמת האפליקציה, במקום ב-API בארכיטקטורת REST. ערכות ה-SDK שומרות על חיבורים פתוחים, וכך מפחיתות את עלויות ההצפנה של SSL ואת העומס על מסד הנתונים, שיכולות להצטבר כשמשתמשים ב-API בארכיטקטורת REST.
אם אתם משתמשים ב-API בארכיטקטורת REST, כדאי להשתמש ב-HTTP keep-alive כדי לשמור על חיבור פתוח או להשתמש באירועים שנשלחים מהשרת, שיכולים להפחית את העלויות של לחיצות ידיים (handshakes) ב-SSL.
פיצול נתונים בין כמה מסדי נתונים
פיצול הנתונים בין כמה מכונות של Realtime Database, שנקרא גם פיצול מסד נתונים, מציע שלושה יתרונות:
- כדי להגדיל את המספר הכולל של החיבורים הפעילים בו-זמנית שמותרים באפליקציה, אפשר לפצל אותם בין מכונות של מסדי נתונים.
- לאזן את העומס בין מכונות של מסדי נתונים.
- אם יש לכם קבוצות משתמשים נפרדות שצריכות גישה רק לקבוצות נתונים נפרדות, השתמשו במכונות שונות של מסדי נתונים כדי להגדיל את קצב הנתונים ולהקטין את זמן האחזור.
אם אתם משתמשים במינוי Blaze בתשלום לפי שימוש, אתם יכולים ליצור כמה מופעים של מסדי נתונים באותו פרויקט Firebase, ולהשתמש בשיטת אימות משתמשים משותפת לכל המופעים של מסדי הנתונים.
מידע נוסף על חלוקת נתונים לחלקים (sharding)
יצירת מבני נתונים יעילים
מכיוון שהפונקציה Realtime Database מאחזרת את הנתונים מצומתי הצאצא של הנתיב וגם מהנתיב, כדאי לשמור על מבנה נתונים שטוח ככל האפשר. כך תוכלו לאחזר באופן סלקטיבי את הנתונים שאתם צריכים, בלי להוריד נתונים מיותרים ללקוחות.
כשאתם בונים את מבנה הנתונים, חשוב במיוחד להביא בחשבון את פעולות הכתיבה והמחיקה. לדוגמה, מחיקה של נתיבים עם אלפי עלים עלולה להיות יקרה. כדי לזרז את המחיקות, אפשר לפצל אותם לנתיבים עם כמה עצי משנה ופחות עלים לכל צומת.
בנוסף, כל כתיבה יכולה לנצל עד 0.1% מנפח האחסון הכולל של מסד הנתונים.
מבנה הנתונים צריך לאפשר לכם לאסוף כתיבות לפעולה אחת כעדכונים בכמה נתיבים, באמצעות השיטות update() בערכות ה-SDK או בקשות PATCH ב-RESTful.
כדי לשפר את מבנה הנתונים והביצועים, כדאי לפעול לפי השיטות המומלצות למבני נתונים.
מניעת גישה לא מורשית
מניעת פעולות לא מורשות במסד הנתונים באמצעות Realtime Database Security Rules. לדוגמה, שימוש בכללים יכול למנוע תרחיש שבו משתמש זדוני מוריד שוב ושוב את מסד הנתונים כולו.
מידע נוסף על שימוש בכללים של מסד נתונים בזמן אמת ב-Firebase
שימוש בכללים שמבוססים על שאילתות כדי להגביל הורדות
Realtime Database Security Rules מגבילים את הגישה לנתונים במסד הנתונים, אבל הם יכולים גם לשמש כמגבלות על הנתונים שמוחזרים באמצעות פעולות קריאה. כשמשתמשים בכללים שמבוססים על שאילתות, כמו ביטויים של query. כמו query.limitToFirst, השאילתות מאחזרות רק את הנתונים שמוגבלים על ידי הכלל.
לדוגמה, הכלל הבא מגביל את גישת הקריאה רק ל-1,000 התוצאות הראשונות של שאילתה, לפי סדר העדיפות:
messages: {
".read": "query.orderByKey &&
query.limitToFirst <= 1000"
}
// Example query:
db.ref("messages").limitToFirst(1000)
.orderByKey("value")
מידע נוסף על Realtime Database Security Rules
שאילתות אינדקס
הוספת הנתונים לאינדקס מפחיתה את רוחב הפס הכולל שבו האפליקציה משתמשת לכל שאילתה שהיא מריצה.
שימוש חוזר בסשנים של SSL
כדי להפחית את העלויות העקיפות של הצפנת SSL בחיבורים שחודשו, אפשר להנפיק כרטיסי סשן TLS. האפשרות הזו שימושית במיוחד אם אתם צריכים חיבורים מאובטחים למסד הנתונים בתדירות גבוהה.
שיפור היעילות של המאזינים
כדאי למקם את המאזינים כמה שיותר נמוך בנתיב כדי להגביל את כמות הנתונים שהם מסנכרנים. המאזינים צריכים להיות קרובים לנתונים שאתם רוצים שהם יקבלו. אל תאזינו ברמה הבסיסית (root) של מסד הנתונים, כי זה יגרום להורדה של כל מסד הנתונים.
הוסיפו שאילתות כדי להגביל את הנתונים שפעולות ההאזנה מחזירות, והשתמשו במאזינים שמורידים רק עדכונים לנתונים – לדוגמה, on() במקום once(). שמרו את .once() לפעולות שבאמת לא דורשות עדכוני נתונים.
בנוסף, כדי לשפר את הביצועים, כדאי למיין את השאילתות באמצעות orderByKey() כשאפשר. מיון באמצעות orderByChild() יכול להיות איטי פי 6 עד 8, ומיון באמצעות orderByValue() יכול להיות איטי מאוד בקבוצות נתונים גדולות, כי הוא דורש קריאה של כל המיקום משכבת ההתמדה.
חשוב גם להוסיף מאזינים באופן דינמי ולהסיר אותם כשאין בהם יותר צורך.
ניקוי נתונים שלא בשימוש
מומלץ להסיר מדי פעם נתונים כפולים או נתונים שלא בשימוש ממסד הנתונים. אתם יכולים להריץ גיבויים כדי לבדוק את הנתונים באופן ידני, או לגבות אותם מדי פעם לקטגוריה ב-Google Cloud Storage. כדאי גם לשקול לארח נתונים מאוחסנים באמצעות Cloud Storage for Firebase.
הפצת קוד שניתן לעדכן ולהתאים לעומס
אפליקציות שמובנות במכשירי IoT צריכות לכלול קוד שניתן להתאמה ושאפשר לעדכן בקלות. חשוב לבדוק היטב את תרחישי השימוש, להביא בחשבון תרחישים שבהם בסיס המשתמשים שלכם עשוי לגדול באופן משמעותי, ולבנות את היכולת לפרוס עדכונים בקוד. חשוב לשקול היטב שינויים משמעותיים שאולי תצטרכו לבצע בהמשך, למשל אם תחליטו לבצע חלוקה אופקית של הנתונים.