ביצוע אופטימיזציה לביצועים של מסד הנתונים

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

מעקב אחר הביצועים של Realtime Database

אתם יכולים לאסוף נתונים על הביצועים של Realtime Database באמצעות כמה כלים שונים, בהתאם לרמת הפירוט שאתם צריכים:

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

שיפור הביצועים לפי מדד

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

אופטימיזציה של חיבורים

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

כשהדבר אפשרי, מומלץ להשתמש ב-SDKs הנתמכים בפלטפורמה של האפליקציה במקום ב-API ל-REST. ערכות ה-SDK שומרות על חיבורים פתוחים, וכך מפחיתות את עלויות ההצפנה של SSL ואת העומס על מסדי הנתונים שיכולים להצטבר עם ממשק ה-API ל-REST.

אם אתם משתמשים ב-API ל-REST, כדאי להשתמש ב-HTTP keep-alive כדי לשמור על חיבור פתוח, או להשתמש באירועים שנשלחים מהשרת, שיכולים לצמצם את העלויות של לחיצות היד של SSL.

חלוקת נתונים למקטעים בכמה מסדי נתונים

חלוקת הנתונים בין כמה מכונות Realtime Database, שנקראת גם חלוקה של מסדי נתונים, מציעה שלושה יתרונות:

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

אם אתם משתמשים בתוכנית התמחור Blaze, תוכלו ליצור כמה מכונות של מסדי נתונים באותו פרויקט Firebase, ולהשתמש בשיטת אימות משתמשים משותפת במכונות של מסדי הנתונים.

מידע נוסף על חלוקת נתונים למקטעים

בניית מבני נתונים יעילים

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

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

בנוסף, כל פעולת כתיבה יכולה להשתמש ב-0.1% מתוך השימוש הכולל במסד הנתונים. כדאי לבנות את הנתונים כך שתוכלו לקבץ את הכתיבה לפעולה אחת, כעדכונים במספר נתיבים, באמצעות השיטות update() ב-SDK או באמצעות בקשות PATCH מסוג REST.

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

מניעת גישה לא מורשית

מניעת פעולות לא מורשות במסד הנתונים באמצעות 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 צריכות לכלול קוד שניתן להתאמה ולעדכון בקלות. חשוב לבדוק היטב את התרחישים לדוגמה, להביא בחשבון תרחישים שבהם בסיס המשתמשים עשוי לגדול באופן אקספוננציאלי, ולהטמיע את היכולת לפרוס עדכונים לקוד. חשוב לשקול היטב שינויים משמעותיים שעשויים להידרש בהמשך, למשל אם תחליטו לפצל את הנתונים.