הסבר על חיוב במסד נתונים בזמן אמת

ב-Firebase, החיוב הוא על הנתונים שאתם מאחסנים במסד הנתונים ועל כל התנועה היוצאת ברשת בשכבת הסשן (שכבה 5) של מודל OSI. החיוב על האחסון הוא 5$ לכל GB לחודש, והוא מתעדכן מדי יום. המיקום של מסד הנתונים לא משפיע על החיוב. תנועה יוצאת כוללת תקורה של חיבור והצפנה מכל פעולות מסד הנתונים ונתונים שהורדו באמצעות קריאות מסד נתונים. קריאות וכתיבות במסד הנתונים עלולות להוביל לעלויות חיבור בחשבון שלכם. כל התנועה אל מסד הנתונים וממנו, כולל פעולות שנחסמו על ידי כללי האבטחה, מובילה לעלויות שניתנות לחיוב.

דוגמאות נפוצות לתנועה שמחויבת:

• נתונים שהורדו: כשלקוחות מקבלים נתונים ממסד הנתונים שלכם, Firebase מחייב על הנתונים שהורדו. בדרך כלל, העלויות האלה מהוות את החלק העיקרי של עלויות רוחב הפס, אבל הן לא הגורם היחיד שמשפיע על החשבון.
• תקורה של פרוטוקול: נדרשת תעבורה נוספת בין השרת לבין הלקוחות כדי ליצור ולתחזק סשן. בהתאם לפרוטוקול הבסיסי, התנועה הזו עשויה לכלול: תקורה של פרוטוקול בזמן אמת של Firebase Realtime Database, תקורה של WebSocket ותקורה של כותרת HTTP. בכל פעם שנוצר חיבור, התקורה הזו, בשילוב עם תקורה של הצפנת SSL, תורמת לעלויות החיבור. אמנם לא מדובר ברוחב פס גדול לבקשה אחת, אבל אם המטען הייעודי קטן או שאתם יוצרים חיבורים קצרים בתדירות גבוהה, זה יכול להיות חלק משמעותי מהחשבון.
• תקורה של הצפנת SSL: יש עלות שמשויכת לתקורה של הצפנת SSL שנדרשת לחיבורים מאובטחים. בממוצע, העלות הזו היא כ-3.5KB ללחיצת היד הראשונית, וכעשרות בייטים לכותרות של רשומות TLS בכל הודעה יוצאת. ברוב האפליקציות, מדובר באחוז קטן מהחשבון. עם זאת, אם המקרה הספציפי שלכם דורש הרבה לחיצות ידיים של SSL, יכול להיות שהערך הזה יהיה אחוז גבוה. לדוגמה, מכשירים שלא תומכים בכרטיסי סשן של TLS עשויים לדרוש מספר גדול של לחיצות ידיים לחיבור SSL.
• Firebase נתונים מהמסוף: בדרך כלל זה לא חלק משמעותי מהעלויות ב-Realtime Database, אבל Firebase מחייב על נתונים שאתם קוראים וכותבים במסוף Firebase.

אומדן של השימוש המחויב

כדי לראות את מספר החיבורים הנוכחיים ל-Realtime Database ואת השימוש בנתונים, אפשר לעיין בכרטיסייה Usage במסוף Firebase. אתם יכולים לבדוק את השימוש בתקופת החיוב הנוכחית, ב-30 הימים האחרונים או ב-24 השעות האחרונות.

ב-Firebase מוצגים נתוני שימוש של המדדים הבאים:

• חיבורים: מספר החיבורים בו-זמנית, שפתוחים כרגע בזמן אמת למסד הנתונים שלכם. החיבורים בזמן אמת כוללים את החיבורים הבאים: WebSocket,‏ long polling ואירועים שנשלחים מהשרת ב-HTML. הוא לא כולל בקשות RESTful.
• אחסון: כמות הנתונים שמאוחסנים במסד הנתונים. ההגדרה הזו לא כוללת את Firebase hosting או נתונים שאוחסנו באמצעות מוצרים אחרים של Firebase.
• הורדות: כל הבייטים שהורדו ממסד הנתונים, כולל תקורה של פרוטוקול והצפנה.
• עומס: בתרשים הזה מוצג כמה מהמסד הנתונים נמצא בשימוש, ומעבד בקשות, במרווח של דקה אחת. יכול להיות שתיתקלו בבעיות בביצועים כשהמסד נתונים יתקרב ל-100%.

אופטימיזציה של השימוש

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

• שימוש בערכות SDK מקוריות: מומלץ להשתמש בערכות ה-SDK שתואמות לפלטפורמה של האפליקציה, במקום ב-REST API. ערכות ה-SDK שומרות על חיבורים פתוחים, וכך מצמצמות את עלויות ההצפנה ב-SSL שמצטברות בדרך כלל בשימוש בממשקי API ל-REST.
• בודקים אם יש באגים: אם עלויות רוחב הפס גבוהות באופן לא צפוי, צריך לוודא שהאפליקציה לא מסנכרנת יותר נתונים או מסנכרנת בתדירות גבוהה יותר ממה שהתכוונתם במקור. כדי לאתר בעיות, אפשר להשתמש בכלי ליצירת פרופילים כדי למדוד את פעולות הקריאה ולהפעיל רישום של ניפוי באגים בערכות ה-SDK של Android,‏ Objective-C ו-Web. כדאי לבדוק את התהליכים של הרקע והסנכרון באפליקציה כדי לוודא שהכול פועל כמו שרציתם.
• צמצום החיבורים: אם אפשר, כדאי לנסות לבצע אופטימיזציה של רוחב הפס של החיבור. בקשות REST קטנות ותכופות עלולות להיות יקרות יותר מחיבור רציף יחיד באמצעות ה-SDK המקורי. אם אתם משתמשים ב-REST API, כדאי להשתמש ב-HTTP keep-alive או באירועים שנשלחים מהשרת, כדי לצמצם את העלויות של תהליכי לחיצת היד של SSL.
• שימוש בכרטיסי סשן של TLS: כדי להקטין את עלויות התקורה של הצפנת SSL בחיבורים שהופעלו מחדש, אפשר להנפיק כרטיסי סשן של TLS. האפשרות הזו שימושית במיוחד אם אתם צריכים ליצור חיבורים מאובטחים למסד הנתונים בתדירות גבוהה.
• שאילתות אינדקס: יצירת אינדקס לנתונים מצמצמת את רוחב הפס הכולל שמשמש לשאילתות, מה שמניב שני יתרונות: הפחתת העלויות ושיפור הביצועים של מסד הנתונים. אפשר להשתמש בכלי ליצירת פרופיל כדי למצוא שאילתות שלא נוספו לאינדקס במסד הנתונים.
• אופטימיזציה של רכיבי ה-listener: מוסיפים שאילתות כדי להגביל את הנתונים שמוחזרים על ידי פעולות ה-listener, ומשתמשים ברכיבי listener שמורידים רק עדכונים של נתונים – לדוגמה, on() במקום once(). בנוסף, כדאי למקם את רכיבי ה-listener כמה שיותר רחוקים בנתיב כדי להגביל את כמות הנתונים שהם מסנכרנים.
• הפחתת עלויות האחסון: כדאי להריץ מדי פעם משימות ניקוי ולצמצם את כמות הנתונים הכפולים במסד הנתונים.
• שימוש בכללים: מונעים פעולות לא מורשות במסד הנתונים שעלולות להיות יקרות. לדוגמה, שימוש ב-Firebase Realtime Database Security Rules יכול למנוע מצב שבו משתמש זדוני מוריד שוב ושוב את כל מסד הנתונים שלכם. מידע נוסף על שימוש בכללים ב-Firebase Realtime Database

תוכנית האופטימיזציה הטובה ביותר לאפליקציה שלכם תלויה בתרחיש השימוש הספציפי שלכם. זו לא רשימה מלאה של שיטות מומלצות, אבל תוכלו לקבל עוד עצות וטיפים מהמומחים של Firebase בערוץ Slack שלנו או ב-Stack Overflow.