אם הפרויקט שלכם נמצא בתוכנית התמחור החינמית Spark, לא תחויבו על השימוש ב-Realtime Database. אתם מקבלים שימוש ללא עלות שכולל אחסון נתונים בנפח 1GB והורדות נתונים בנפח 10GB בחודש.
אם תשדרגו לתוכנית התמחור Blaze בתשלום לפי שימוש, תוכלו להמשיך להשתמש בחינם (אחסון נתונים בנפח 1GB והורדות נתונים בנפח 10GB בחודש), ותחויבו רק על שימוש מעבר לכמות הזו. אם הפרויקט שלכם נמצא במינוי Blaze בתשלום לפי שימוש, מומלץ להגדיר התראות תקציב לפרויקט.
בהמשך הדף מוסבר בהרחבה על החיוב.
איך החיוב מחושב ב-Realtime Database
ב-Firebase החיוב הוא על הנתונים שמאוחסנים במסד הנתונים ועל כל תנועת הרשת היוצאת בשכבת השיחה (שכבה 5) של מודל OSI. החיוב על האחסון הוא 5$ לכל GB בחודש, והוא מחושב מדי יום. החיוב לא מושפע ממיקום מסד הנתונים. תנועה יוצאת כוללת תקורה של חיבור והצפנה מכל פעולות מסד הנתונים ונתונים שהורדו באמצעות קריאות של מסד הנתונים. גם קריאות וגם כתיבות במסד הנתונים יכולות להוביל לעלויות חיבור בחשבון שלכם. כל תנועה אל מסד הנתונים וממנו, כולל פעולות שנדחו על ידי כללי האבטחה, מובילה לעלויות שניתנות לחיוב.
דוגמאות נפוצות לתנועה שמחויבת:
- נתונים שהורדו: כשלקוחות מקבלים נתונים ממסד הנתונים שלכם, Firebase מחייבת על הנתונים שהורדו. בדרך כלל, זהו החלק העיקרי בעלויות רוחב הפס, אבל זה לא הגורם היחיד בחשבון.
- תקורה של פרוטוקול: כדי ליצור סשן ולתחזק אותו, נדרשת תנועה נוספת בין השרת ללקוחות. בהתאם לפרוטוקול הבסיסי, התנועה הזו עשויה לכלול: תקורה של פרוטוקול בזמן אמת של מסד נתונים בזמן אמת ב-Firebase, תקורה של WebSocket ותקורה של כותרת HTTP. בכל פעם שנוצר חיבור, התקורה הזו, בשילוב עם תקורה של הצפנת SSL, תורמת לעלויות החיבור. אמנם לא מדובר ברוחב פס גדול לבקשה אחת, אבל אם המטענים הייעודיים קטנים או אם אתם מבצעים חיבורים קצרים לעיתים קרובות, זה יכול להיות חלק משמעותי מהחשבון.
- תקורה של הצפנת SSL: יש עלות שקשורה לתקורה של הצפנת SSL שנדרשת לחיבורים מאובטחים. בממוצע, העלות הזו היא בערך 3.5KB ללחיצת היד הראשונית, ובערך עשרות בייטים לכותרות של רשומות TLS בכל הודעה יוצאת. ברוב האפליקציות, מדובר באחוז קטן מהחשבון. עם זאת, האחוז הזה יכול להיות גדול יותר אם במקרה הספציפי שלכם נדרשים הרבה לחיצות ידיים של SSL. לדוגמה, מכשירים שלא תומכים בכרטיסי סשן של TLS עשויים לדרוש מספר גדול של לחיצות ידיים בחיבור SSL.
- נתונים במסוף Firebase: בדרך כלל זה לא חלק משמעותי מהעלויות של Realtime Database, אבל ב-Firebase יש חיוב על נתונים שאתם קוראים וכותבים ממסוף Firebase.
הערכת השימוש לחיוב
כדי לראות את החיבורים הנוכחיים של Realtime Database ואת השימוש בנתונים, בודקים את הכרטיסייה Usage במסוף Firebase. אתם יכולים לבדוק את השימוש בתקופת החיוב הנוכחית, ב-30 הימים האחרונים או ב-24 השעות האחרונות.
ב-Firebase מוצגים נתוני שימוש של המדדים הבאים:
- חיבורים: מספר החיבורים בו-זמנית, הפתוחים כרגע, בזמן אמת למסד הנתונים. החיבורים האלה כוללים את החיבורים הבאים בזמן אמת: WebSocket, דגימה ארוכה ואירועים שנשלחו משרת HTML. הוא לא כולל בקשות RESTful.
- אחסון: כמות הנתונים שמאוחסנים במסד הנתונים. הנתונים האלה לא כוללים את האירוח ב-Firebase או נתונים שמאוחסנים דרך מוצרים אחרים של Firebase.
- הורדות: כל הבייטים שהורדו ממסד הנתונים, כולל תקורה של פרוטוקול והצפנה.
- עומס: בתרשים הזה מוצג החלק של מסד הנתונים שנמצא בשימוש ומעבד בקשות, במרווח זמן נתון של דקה אחת. יכול להיות שתבחינו בבעיות בביצועים כשהמסד נתונים יתקרב ל-100%.
אופטימיזציה של השימוש
יש כמה שיטות מומלצות שתוכלו להשתמש בהן כדי לבצע אופטימיזציה של השימוש במסד הנתונים ושל עלויות רוחב הפס.
- שימוש בערכות ה-SDK המקוריות: כשאפשר, השתמשו בערכות ה-SDK שתואמות לפלטפורמה של האפליקציה, במקום ב-API בארכיטקטורת REST. ערכות ה-SDK שומרות על חיבורים פתוחים, וכך מפחיתות את עלויות ההצפנה ב-SSL שבדרך כלל מצטברות ב-API בארכיטקטורת REST.
- בדיקת באגים: אם עלויות רוחב הפס גבוהות באופן בלתי צפוי, ודאו שהאפליקציה לא מסנכרנת יותר נתונים או מסנכרנת בתדירות גבוהה יותר ממה שהתכוונתם במקור. כדי לאתר בעיות, השתמשו בכלי הפרופיילר כדי למדוד את פעולות הקריאה ולהפעיל יומן ניפוי באגים בערכות ה-SDK של Android, Objective-C ואינטרנט. בודקים את תהליכי הרקע והסנכרון באפליקציה כדי לוודא שהכול פועל כמו שצריך.
- צמצום החיבורים: אם אפשר, נסו לבצע אופטימיזציה של רוחב הפס של החיבור. בקשות REST קטנות ותכופות יכולות להיות יקרות יותר מחיבור יחיד ורציף באמצעות ה-SDK המקורי. אם אתם משתמשים ב-API בארכיטקטורת REST, כדאי להשתמש ב-HTTP keep-alive או באירועים שנשלחים מהשרת, שיכולים להפחית את העלויות של לחיצות ידיים (handshakes) של SSL.
- שימוש בכרטיסי סשן של TLS: כדי להפחית את עלויות התקורה של הצפנת SSL בחיבורים שחודשו, אפשר להנפיק כרטיסי סשן של TLS. האפשרות הזו שימושית במיוחד אם אתם צריכים חיבורים מאובטחים ותכופים למסד הנתונים.
- שאילתות לאינדקס: הוספת הנתונים לאינדקס מפחיתה את רוחב הפס הכולל שמשמש לשאילתות, וכך גם מוזילה את העלויות וגם משפרת את הביצועים של מסד הנתונים. משתמשים בכלי הפרופיילינג כדי למצוא שאילתות שלא נוספו לאינדקס במסד הנתונים.
- אופטימיזציה של המאזינים: הוסיפו שאילתות כדי להגביל את הנתונים שפעולות ההאזנה מחזירות, והשתמשו במאזינים שמורידים רק עדכונים לנתונים – לדוגמה,
on()במקוםonce(). בנוסף, כדאי למקם את המאזינים כמה שיותר רחוק בנתיב כדי להגביל את כמות הנתונים שהם מסנכרנים. - הפחתת עלויות האחסון: הפעילו משימות ניקוי תקופתיות וצמצמו את הנתונים הכפולים במסד הנתונים.
- שימוש בכללים: מניעת פעולות לא מורשות במסד הנתונים שעלולות לעלות ביוקר. לדוגמה, שימוש ב-Firebase Realtime Database Security Rules יכול למנוע תרחיש שבו משתמש זדוני מוריד שוב ושוב את כל מסד הנתונים שלכם. מידע נוסף על שימוש בכללים של מסד נתונים בזמן אמת ב-Firebase
תוכנית האופטימיזציה הטובה ביותר לאפליקציה תלויה בתרחיש לדוגמה הספציפי שלכם. זו לא רשימה ממצה של שיטות מומלצות, אבל אתם יכולים למצוא עוד עצות וטיפים מהמומחים של Firebase בערוץ Slack או ב-Stack Overflow.