אם הפרויקט שלכם מוגדר בתוכנית התמחור Spark ללא עלות, לא תחויבו על השימוש ב-Realtime Database. השימוש ללא עלות כולל אחסון נתונים בנפח של 1GB והורדות נתונים בנפח של 10GB בחודש.
אם תשדרגו לתוכנית התמחור Blaze בתשלום לפי שימוש, תוכלו להמשיך ליהנות מהשימוש ללא עלות (1GB של אחסון נתונים ו-10GB של הורדות נתונים בחודש), ותחויבו על כל שימוש מעבר לכמות הזו. אם הפרויקט שלכם מוגדר לתוכנית התמחור Blaze, מומלץ להגדיר התראות לגבי התקציב בפרויקט.
בהמשך הדף מוסבר על החיוב בצורה מפורטת יותר.
איך Realtime Database מחשב את החיוב
ב-Firebase, החיוב מתבצע על הנתונים שאתם מאחסנים במסד הנתונים ועל כל התעבורה היוצאת ברשת בשכבת הסשן (שכבה 5) של מודל OSI. החיוב על האחסון הוא 5$ לכל GB לחודש, והוא מוערך מדי יום. החיוב לא מושפע מהמיקום של מסד הנתונים. תנועה יוצאת כוללת תקורה של חיבור והצפנה מכל פעולות מסד הנתונים ונתונים שהורדו באמצעות קריאות מסד הנתונים. קריאות וכתיבות במסד הנתונים עלולות להוביל לעלויות חיבור בחשבון. כל התנועה אל מסד הנתונים וממנו, כולל פעולות שנחסמו על ידי כללי האבטחה, מובילה לעלויות שניתנות לחיוב.
דוגמאות נפוצות לחיוב על תנועת גולשים:
- נתונים שהורדו: כשלקוחות מקבלים נתונים ממסד הנתונים שלכם, Firebase מחייב על הנתונים שהורדו. בדרך כלל, זהו החלק העיקרי בעלויות רוחב הפס, אבל הוא לא הגורם היחיד בחשבון.
- תקורה של פרוטוקול: נדרשת תנועה נוספת בין השרת ללקוחות כדי ליצור ולתחזק סשן. בהתאם לפרוטוקול הבסיסי, התנועה הזו עשויה לכלול: תקורה של פרוטוקול בזמן אמת של Firebase Realtime Database, תקורה של WebSocket ותקורה של כותרת HTTP. בכל פעם שנוצר חיבור, התקורה הזו, בשילוב עם תקורה של הצפנת SSL, תורמת לעלויות החיבור. אמנם לא מדובר ברוחב פס גדול לבקשה אחת, אבל אם המטען הייעודי (payload) קטן או שאתם יוצרים חיבורים קצרים בתדירות גבוהה, יכול להיות שזה יהיה חלק משמעותי מהחשבון.
- תקורה של הצפנת SSL: יש עלות שמשויכת לתקורה של הצפנת SSL שנדרשת לחיבורים מאובטחים. בממוצע, העלות הזו היא כ-3.5KB ללחיצת היד הראשונית, וכעשרות בייטים לכותרות של רשומות TLS בכל הודעה יוצאת. ברוב האפליקציות, מדובר באחוז קטן מהחיוב. עם זאת, אם המקרה הספציפי שלכם דורש הרבה לחיצות ידיים של SSL, יכול להיות שהמספר הזה יהיה אחוז גדול יותר. לדוגמה, מכשירים שלא תומכים בכרטיסי סשן של TLS עשויים לדרוש מספר גדול של לחיצות ידיים לחיבור SSL.
- Firebase נתונים ממסוף 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 שמורידים רק עדכונים של נתונים – לדוגמה,
on()במקוםonce(). בנוסף, כדאי למקם את רכיבי ה-listener כמה שיותר רחוק בהמשך הנתיב כדי להגביל את כמות הנתונים שהם מסנכרנים. - הפחתת עלויות האחסון: מריצים משימות ניקוי תקופתיות ומצמצמים את הנתונים הכפולים במסד הנתונים.
- שימוש בכללים: מונעים פעולות לא מורשות במסד הנתונים שעלולות לגרום לעלויות גבוהות. לדוגמה, שימוש ב-Firebase Realtime Database Security Rules יכול למנוע תרחיש שבו משתמש זדוני מוריד שוב ושוב את כל מסד הנתונים שלכם. מידע נוסף על שימוש בכללים ב-Firebase Realtime Database
תוכנית האופטימיזציה הטובה ביותר לאפליקציה שלכם תלויה בתרחיש השימוש הספציפי שלכם. הרשימה הזו לא כוללת את כל השיטות המומלצות, אבל תוכלו למצוא עוד עצות וטיפים ממומחי Firebase בערוץ Slack שלנו או ב-Stack Overflow.