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