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