הסבר על חיוב במסד נתונים בזמן אמת

ב-Firebase מחויב על הנתונים שאתם שומרים במסד הנתונים ועל כל תעבורת הנתונים היוצאת ברשת בשכבת הסשן (שכבה 5) של מודל OSI. החיוב על האחסון הוא 5$ לכל GB לחודש, והוא מחושב מדי יום. החיוב לא מושפע מהמיקום של מסד הנתונים שלכם. תעבורת הנתונים היוצאת כוללת את התקורה של החיבור וההצפנה מכל פעולות מסדי הנתונים, ונתונים שהורדתם באמצעות קריאות של מסדי נתונים. גם קריאות וגם כתיבות במסדי נתונים יכולות להוביל לעלויות חיבור בחשבונית. כל תעבורת הנתונים אל מסד הנתונים וממנו, כולל פעולות שנדחו באמצעות כללי אבטחה, מובילה לעלויות לחיוב.

דוגמאות נפוצות לתנועה שעבורה מתבצעת חיוב:

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

תוכנית האופטימיזציה הטובה ביותר לאפליקציה שלכם תלויה בתרחיש לדוגמה הספציפי שלכם. זוהי רשימה חלקית של שיטות מומלצות, אבל תוכלו למצוא עוד טיפים והמלצות ממומחים של Firebase בערוץ Slack שלנו או ב-Stack Overflow.