אם הפרויקט שלכם נמצא בתוכנית התמחור החינמית Spark, לא תחויבו על השימוש ב-Realtime Database. אתם מקבלים שימוש ללא עלות שכולל אחסון נתונים בנפח 1GB והורדות נתונים בנפח 10GB בחודש.
אם תשדרגו לתוכנית התמחור Blaze בתשלום לפי שימוש, תוכלו להמשיך להשתמש בחינם (אחסון נתונים בנפח 1GB והורדות נתונים בנפח 10GB בחודש), ותחויבו רק על שימוש מעבר לכמות הזו. אם הפרויקט שלכם נמצא במינוי Blaze בתשלום לפי שימוש, מומלץ להגדיר התראות תקציב לפרויקט.
בהמשך הדף מוסבר בהרחבה על החיוב.
איך Realtime Database מחשב את החיוב
ב-Firebase, החיוב מתבצע על הנתונים שמאוחסנים במסד הנתונים ועל כל התנועה היוצאת ברשת בשכבת השיחה (שכבה 5) של מודל OSI. החיוב על האחסון הוא 5$ לכל GB בחודש, והוא מחושב מדי יום. החיוב לא מושפע ממיקום מסד הנתונים. תנועה יוצאת כוללת תקורה של חיבור והצפנה מכל פעולות מסד הנתונים ונתונים שהורדו באמצעות קריאות של מסד הנתונים. גם קריאות וגם כתיבות במסד הנתונים יכולות להוביל לעלויות חיבור בחשבון שלכם. כל התנועה אל מסד הנתונים וממנו, כולל פעולות שנדחו על ידי כללי האבטחה, מובילה לעלויות שניתן לחייב.
דוגמאות נפוצות לתנועה שמחויבת:
- נתונים שהורדו: כשלקוחות מקבלים נתונים ממסד הנתונים שלכם, Firebase מחייבת על הנתונים שהורדו. בדרך כלל, זהו החלק העיקרי בעלויות רוחב הפס, אבל זה לא הגורם היחיד בחשבון.
- תקורה של פרוטוקול: כדי ליצור סשן ולתחזק אותו, נדרשת תנועה נוספת בין השרת ללקוחות. בהתאם לפרוטוקול הבסיסי, התנועה הזו עשויה לכלול: תקורה של פרוטוקול בזמן אמת של מסד נתונים בזמן אמת ב-Firebase, תקורה של 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 או נתונים שמאוחסנים דרך מוצרים אחרים של Firebase.
- הורדות: כל הבייטים שהורדו ממסד הנתונים, כולל תקורה של פרוטוקול והצפנה.
- עומס: בתרשים הזה מוצג איזה חלק ממסד הנתונים נמצא בשימוש ומעבד בקשות, במרווח זמן נתון של דקה אחת. יכול להיות שתבחינו בבעיות בביצועים כשהמסד נתונים יתקרב ל-100%.
אופטימיזציה של השימוש
יש כמה שיטות מומלצות שאפשר להשתמש בהן כדי לבצע אופטימיזציה של השימוש במסד הנתונים ושל עלויות רוחב הפס.
- שימוש בערכות ה-SDK המקוריות: כשאפשר, השתמשו בערכות ה-SDK שמתאימות לפלטפורמה של האפליקציה, במקום ב-API בארכיטקטורת REST. ערכות ה-SDK שומרות על חיבורים פתוחים, וכך מפחיתות את עלויות ההצפנה ב-SSL שבדרך כלל מצטברות ב-API בארכיטקטורת REST.
- בדיקת באגים: אם עלויות רוחב הפס גבוהות באופן בלתי צפוי, ודאו שהאפליקציה לא מסנכרנת יותר נתונים או מסנכרנת בתדירות גבוהה יותר ממה שהתכוונתם במקור. כדי לאתר בעיות, השתמשו בכלי הפרופיילינג כדי למדוד את פעולות הקריאה ולהפעיל את רישום ניפוי הבאגים בערכות ה-SDK של Android, Objective-C ואינטרנט. בודקים את תהליכי הרקע והסנכרון באפליקציה כדי לוודא שהכול פועל כמו שצריך.
- צמצום החיבורים: אם אפשר, נסו לבצע אופטימיזציה של רוחב הפס של החיבור. בקשות REST קטנות ותכופות יכולות לעלות יותר מחיבור יחיד ורציף באמצעות ה-SDK המקורי. אם אתם משתמשים ב-API בארכיטקטורת REST, כדאי להשתמש ב-HTTP keep-alive או באירועים שנשלחים מהשרת, שיכולים להפחית את העלויות של לחיצות ידיים (handshakes) ב-SSL.
- שימוש בכרטיסי סשן TLS: כדי להפחית את עלויות התקורה של הצפנת SSL בחיבורים שחודשו, אפשר להנפיק כרטיסי סשן TLS. האפשרות הזו שימושית במיוחד אם אתם צריכים להתחבר למסד הנתונים באופן תכוף ומאובטח.
- שאילתות לאינדקס: הוספת הנתונים לאינדקס מפחיתה את רוחב הפס הכולל שמשמש לשאילתות, וכך גם מוזילה את העלויות וגם משפרת את הביצועים של מסד הנתונים. משתמשים בכלי הפרופיילינג כדי למצוא שאילתות ללא אינדקס במסד הנתונים.
- אופטימיזציה של המאזינים: הוסיפו שאילתות כדי להגביל את הנתונים שפעולות ההאזנה מחזירות, והשתמשו במאזינים שמורידים רק עדכונים לנתונים – לדוגמה,
on()במקוםonce(). בנוסף, כדאי למקם את המאזינים כמה שיותר רחוק בנתיב כדי להגביל את כמות הנתונים שהם מסנכרנים. - הפחתת עלויות האחסון: הפעילו משימות ניקוי תקופתיות וצמצמו את הנתונים הכפולים במסד הנתונים.
- שימוש בכללים: מניעת פעולות לא מורשות במסד הנתונים שעלולות להיות יקרות. לדוגמה, שימוש ב-Firebase Realtime Database Security Rules יכול למנוע תרחיש שבו משתמש זדוני מוריד שוב ושוב את מסד הנתונים כולו. מידע נוסף על שימוש בכללים של מסד נתונים בזמן אמת ב-Firebase
תוכנית האופטימיזציה הטובה ביותר לאפליקציה תלויה בתרחיש לדוגמה הספציפי שלכם. זו לא רשימה ממצה של שיטות מומלצות, אבל אתם יכולים למצוא עוד עצות וטיפים מהמומחים של Firebase בערוץ Slack או ב-Stack Overflow.