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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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