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