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