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

bookmark_border קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שיפור היעילות של המאזינים

כדאי למקם את רכיבי ה-Listener כמה שיותר נמוך בנתיב כדי להגביל את כמות הנתונים שהם מסנכרנים. המאזינים צריכים להיות קרובים לנתונים שאתם רוצים שהם יקבלו. לא מומלץ להאזין בבסיס מסד הנתונים, כי זה יוביל להורדה של כל מסד הנתונים.

מוסיפים שאילתות כדי להגביל את הנתונים שמוחזרים מפעולות ההאזנה, ומשתמשים במאזינים שמורידים רק עדכונים לנתונים – לדוגמה, on() במקום once(). מומלץ להשתמש ב-.once() רק לפעולות שלא דורשות עדכוני נתונים. בנוסף, מומלץ למיין את השאילתות באמצעות orderByKey(), כשאפשר, כדי להשיג את הביצועים הטובים ביותר. מיון באמצעות orderByChild() יכול להיות איטי פי 6 עד 8, ומיון באמצעות orderByValue() יכול להיות איטי מאוד במערכי נתונים גדולים, כי הוא דורש קריאה של כל המיקום משכבת ההתמדה.

חשוב גם להוסיף מאזינים באופן דינמי ולהסיר אותם כשאין בהם יותר צורך.

ניקוי נתונים שלא בשימוש

חשוב להסיר מדי פעם נתונים כפולים או נתונים שלא נמצאים בשימוש במסד הנתונים. אתם יכולים להריץ גיבויים כדי לבדוק את הנתונים באופן ידני או לגבות אותם מעת לעת לדלי Google Cloud Storage. כדאי לשקול גם לארח נתונים מאוחסנים באמצעות Cloud Storage for Firebase.

שליחת קוד שניתן לעדכן ומתאים לשימוש נרחב

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