יש כמה דרכים לשפר את הביצועים של Firebase Realtime Database באפליקציה. כדי לברר מה אפשר לעשות כדי לבצע אופטימיזציה של הביצועים של Realtime Database, צריך לאסוף נתונים באמצעות הכלים השונים למעקב אחרי Realtime Database, ואז לבצע שינויים באפליקציה או בשימוש ב-Realtime Database בהתאם.
מעקב אחר הביצועים של Realtime Database
אתם יכולים לאסוף נתונים על הביצועים של Realtime Database באמצעות כמה כלים שונים, בהתאם לרמת הפירוט שאתם צריכים:
- סקירה כללית ברמה גבוהה: אפשר להשתמש בכלי Profiler כדי לקבל רשימה של שאילתות שלא נוספו לאינדקס, וגם סקירה כללית בזמן אמת של פעולות הקריאה/כתיבה.
- אומדן השימוש לחיוב: אתם יכולים להשתמש במדדי השימוש שזמינים במסוף Firebase כדי לראות את השימוש לחיוב ואת מדדי הביצועים ברמה גבוהה.
- פירוט מפורט: אפשר להשתמש באפשרות Cloud Monitoring כדי לקבל תמונה מפורטת יותר של הביצועים של מסד הנתונים לאורך זמן.
שיפור הביצועים לפי מדד
אחרי שאתם אוספים את הנתונים, כדאי לקרוא את השיטות והשיטות המומלצות הבאות בהתאם לתחום הביצועים שאתם רוצים לשפר.
| שיטות לשיפור הביצועים במבט מהיר | ||
|---|---|---|
| מדד | תיאור | שיטות מומלצות |
| עומס/שימוש | לבצע אופטימיזציה של הקיבולת של מסד הנתונים שנמצאת בשימוש בבקשות עיבוד בכל זמן נתון (המידע הזה משתקף במדדים **Load** או **io/database_load**). |
אופטימיזציה של מבנה הנתונים חלוקה של נתונים למקטעים במספר מסדי נתונים שיפור היעילות של המאזינים הגבלת ההורדות באמצעות כללים מבוססי שאילתה אופטימיזציה של החיבורים |
| חיבורים פעילים | כדאי לאזן את מספר החיבורים הפעילים בו-זמנית למסד הנתונים שלכם, כדי להישאר מתחת למגבלה של 200,000 חיבורים. |
נתונים מפוצלים במסדי נתונים צמצום חיבורים חדשים |
| רוחב הפס היוצא | אם נראה שכמות ההורדות ממסד הנתונים גבוהה יותר מהרצוי, אפשר לשפר את היעילות של פעולות הקריאה ולהפחית את תקורת ההצפנה. |
אופטימיזציה של החיבורים אופטימיזציה של מבנה הנתונים הגבלת ההורדות באמצעות כללים מבוססי שאילתה שימוש חוזר בסשנים של SSL שיפור היעילות של המאזינים הגבלת הגישה לנתונים |
| אחסון | חשוב לוודא שאתם לא מאחסנים נתונים שלא בשימוש, או לאזן את נפח הנתונים ששמורים במסדי נתונים אחרים ו/או במוצרי Firebase אחרים כדי לא לחרוג מהמכסה. |
ניקוי נתונים שלא נמצאים בשימוש אופטימיזציה של מבנה הנתונים נתונים בודדים ממסדי נתונים שונים שימוש ב-Cloud Storage for Firebase |
אופטימיזציה של חיבורים
לבקשות RESTful כמו GET ו-PUT עדיין נדרש חיבור, גם אם החיבור הזה קצר. החיבורים התכופים לטווח הקצר יכולים למעשה לפצות על עלויות חיבור, עומס על מסד הנתונים ורוחב הפס היוצא בהשוואה לחיבורים פעילים בזמן אמת למסד הנתונים שלכם.
כשהדבר אפשרי, מומלץ להשתמש בערכות ה-SDK הנתמכות בפלטפורמה של האפליקציה במקום ב-REST API. ערכות ה-SDK שומרות על חיבורים פתוחים, וכך מצמצמות את העלויות של הצפנת SSL ואת העומס על מסדי הנתונים שיכולים להוסיף ל-API ל-REST.
אם אתם משתמשים ב-API ל-REST, כדאי להשתמש ב-HTTP keep-alive כדי לשמור על חיבור פתוח, או להשתמש באירועים שנשלחים מהשרת, שיכולים לצמצם את העלויות של לחיצות היד של SSL.
חלוקת נתונים למקטעים במספר מסדי נתונים
לפיצול הנתונים בין כמה מכונות Realtime Database, שנקראות גם 'פיצול (database)', יש שלושה יתרונות:
- כדי להגדיל את מספר החיבורים הפעילים בו-זמנית שאפשר ליצור באפליקציה, אפשר לפצל אותם בין מכונות של מסד נתונים.
- לאזן את העומס בין המכונות של מסד הנתונים.
- אם יש לכם קבוצות עצמאיות של משתמשים שזקוקים לגישה רק למערכי נתונים נפרדים, כדאי להשתמש במופעים שונים של מסדי נתונים כדי לשפר את קצב העברת הנתונים ולהפחית את זמן האחזור.
אם אתם משתמשים בתוכנית התמחור Blaze, תוכלו ליצור כמה מכונות של מסדי נתונים באותו פרויקט Firebase, ולהשתמש בשיטה משותפת לאימות משתמשים במכונות של מסדי הנתונים.
מידע נוסף על חלוקת נתונים למקטעים
בניית מבני נתונים יעילים
מכיוון ש-Realtime Database מאחזר את הנתונים גם מהנתיב וגם מהצומתים הצאצאים שלו, מומלץ לשמור על מבנה נתונים שטוח ככל האפשר. כך תוכלו לאחזר באופן סלקטיבי את הנתונים שאתם צריכים, בלי להוריד נתונים מיותרים ללקוחות.
במיוחד כדאי להביא בחשבון פעולות כתיבה ומחיקה כשאתם מגדירים את המבנה של הנתונים. לדוגמה, המחיקה של נתיבים עם אלפי עלים עשויה להיות יקרה. חלוקה שלהם לנתיבים עם כמה עצים משניים ופחות עלים לכל צומת יכולה לזרז את המחיקה.
בנוסף, כל פעולת כתיבה יכולה להשתמש ב-0.1% מתוך השימוש הכולל במסד הנתונים.
כדאי לארגן את הנתונים כך שיהיה אפשר לכתוב באצווה פעולות כתיבה אחת כעדכונים מרובי-נתיבים, באמצעות ה-methods update() בערכות ה-SDK או בבקשות PATCH מסוג RESTful.
כדי לבצע אופטימיזציה של מבנה הנתונים ולשפר את הביצועים, כדאי לפעול לפי השיטות המומלצות למבני נתונים.
מניעת גישה לא מורשית
מניעת פעולות לא מורשות במסד הנתונים באמצעות Realtime Database Security Rules. לדוגמה, השימוש בכללים יכול למנוע תרחיש שבו משתמש זדוני מוריד שוב ושוב את כל מסד הנתונים.
מידע נוסף על שימוש בכללים של Firebase Realtime Database
שימוש בכללים שמבוססים על שאילתות כדי להגביל הורדות
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. האפשרות הזו שימושית במיוחד אם צריכים חיבורים מאובטחים תכופים למסד הנתונים.
שיפור היעילות של המאזינים
כדאי למקם את המאזינים כמה שיותר בחלק התחתון של הנתיב כדי להגביל את כמות הנתונים שהם מסנכרנים. המאזינים צריכים להיות קרובים לנתונים שאתם רוצים שהם יקבלו. אל תאזינו ברמה הבסיסית של מסד הנתונים, כי זה יוביל להורדות של כל מסד הנתונים.
מוסיפים שאילתות כדי להגביל את הנתונים שחוזרים מהפעולות של ההאזנה, ומשתמשים במאזינים שמורידים רק עדכונים לנתונים – לדוגמה, on() במקום once(). כדאי להשתמש ב-.once() רק לפעולות שבאמת לא מחייבות עדכון נתונים.
בנוסף, כדי לשפר את הביצועים, מומלץ למיין את השאילתות באמצעות orderByKey() כשהדבר אפשרי. מיון באמצעות orderByChild() יכול להיות איטי פי 6-8, ומיון באמצעות orderByValue() יכול להיות איטי מאוד במערכי נתונים גדולים, כי הוא מחייב קריאה של המיקום כולו משכבת העקביות.
חשוב גם להוסיף מאזינים באופן דינמי ולהסיר אותם כשאין בהם יותר צורך.
למחיקת נתונים שלא נמצאים בשימוש
כדאי להסיר מדי פעם נתונים כפולים או לא בשימוש ממסד הנתונים. אפשר להריץ גיבויים כדי לבדוק את הנתונים באופן ידני, או לגבות אותם באופן קבוע לקטגוריה Google Cloud Storage. כדאי גם לארח את הנתונים המאוחסנים באמצעות Cloud Storage for Firebase.
שולחים קוד שניתן להתאמה ולעדכון
אפליקציות שמוטמעות במכשירי IoT צריכות לכלול קוד שניתן להתאמה ולעדכון בקלות. הקפידו לבדוק תרחישים לדוגמה באופן יסודי, להביא בחשבון תרחישים שבהם אתם יכולים להגדיל את בסיס המשתמשים באופן אקספוננציאלי, ולפתח את היכולת לפרוס עדכונים לקוד. חשוב לשקול היטב שינויים משמעותיים שעשויים להידרש בהמשך, למשל אם תחליטו לפצל את הנתונים.