שאלות נפוצות ופתרון בעיות בנושא מסד נתונים בזמן אמת

בדף הזה מופיעות תשובות לשאלות נפוצות ועזרה בפתרון בעיות שקשורות לשימוש ב-Firebase Realtime Database. אם לא מצאתם את מה שחיפשתם או שאתם צריכים עזרה נוספת, פנו לתמיכה של Firebase.

מה זה "חיבור בו-זמני למסד נתונים"?

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

בתוכנית התמחור Spark המגבלה היא 100 ואי אפשר להגדיל אותה. במינוי Blaze בתשלום לפי שימוש יש מגבלה של 200,000 חיבורים בו-זמניים לכל מסד נתונים.

המגבלה הזו לא זהה למספר הכולל של המשתמשים באפליקציה, כי המשתמשים לא מתחברים כולם בבת אחת. אם אתם צריכים יותר מ-200,000 חיבורים בו-זמנית, עיינו באפשרויות שבמאמר הרחבה באמצעות כמה מסדי נתונים.

מהן מגבלות ההתאמה לעומס (scaling) של Realtime Database?

לכל מכונה של Realtime Database יש מגבלות על מספר פעולות הכתיבה לשנייה. בכתיבה של נתונים קטנים, המגבלה היא בערך 1,000 פעולות כתיבה לשנייה. אם אתם מתקרבים למגבלה הזו, הפעלת פעולות באצווה באמצעות עדכונים בכמה נתיבים יכולה לעזור לכם להשיג תפוקה גבוהה יותר.

בנוסף, לכל מופע של מסד נתונים יש מגבלה על מספר החיבורים בו-זמנית למסד הנתונים. המגבלות שמוגדרות כברירת מחדל מספיקות לרוב האפליקציות. אם אתם מפתחים אפליקציה שדורשת קנה מידה נוסף, יכול להיות שתצטרכו לבצע פיצול אופקי (sharding) של האפליקציה בכמה מופעים של מסדי נתונים כדי להגדיל את קנה המידה. אפשר גם להשתמש ב-Cloud Firestore כמסד נתונים חלופי.

מה אפשר לעשות אם חורגים ממגבלות השימוש ב-Realtime Database?

אם קיבלתם התראה באימייל או הודעה במסוף Firebase על חריגה ממגבלות השימוש ב-Realtime Database, אתם יכולים לטפל בבעיה בהתאם למגבלת השימוש שחרגתם ממנה. כדי לראות את השימוש ב-Realtime Database, נכנסים למרכז הבקרה Realtime Database Usage במסוף Firebase.

אם חרגתם ממגבלת ההורדות, אתם יכולים לשדרג את תוכנית התמחור של Firebase או להמתין עד שמגבלת ההורדות תתאפס בתחילת מחזור החיובים הבא. כדי להקטין את נפח ההורדות, נסו את הפעולות הבאות:

• הוסיפו שאילתות כדי להגביל את הנתונים שפעולות ההאזנה מחזירות.
• בודקים אם יש שאילתות שלא נוספו לאינדקס.
• השתמשו במאזינים שמורידים רק עדכונים לנתונים – לדוגמה, on במקום once.
• להשתמש בכללי אבטחה כדי לחסום הורדות לא מורשות.

אם חרגתם ממגבלת האחסון, שדרגו את תוכנית התמחור כדי למנוע שיבושים בשירות. כדי לצמצם את כמות הנתונים במסד הנתונים, נסו את השלבים הבאים:

• להריץ משימות ניקוי תקופתיות.
• צמצמו את הנתונים הכפולים במסד הנתונים.

יכול להיות שיעבור קצת זמן עד שהמחיקה של הנתונים תתעדכן במכסת האחסון.

אם חרגתם ממגבלת החיבורים בו-זמנית למסד הנתונים, שדרגו את התוכנית כדי למנוע שיבושים בשירות. כדי לנהל חיבורים בו-זמניים למסד הנתונים, נסו לחבר משתמשים באמצעות ה-API בארכיטקטורת REST אם הם לא צריכים חיבור בזמן אמת.

מה קורה אם חורגים ממגבלות האחסון או ההורדה של מינוי Spark בתשלום קבוע ב-Realtime Database?

כדי לספק לכם מחיר צפוי, המשאבים שזמינים לכם מוגבלים כשהפרויקט שלכם נמצא במינוי Spark בתשלום קבוע. כלומר, אם תחרוג ממגבלת התוכנית בחודש מסוים, האפליקציה תושבת כדי למנוע שימוש נוסף במשאבים וחיובים נוספים.

מה קורה אם חורגים ממגבלות החיבורים בו-זמנית של Realtime Database במינוי Spark בתשלום קבוע?

כשהאפליקציה מגיעה למגבלת החיבורים בו-זמנית במינוי Spark בתשלום קבוע, כל החיבורים הבאים יידחו עד שחלק מהחיבורים הקיימים ייסגרו. האפליקציה תמשיך לפעול אצל משתמשים שמחוברים.

מהם גיבויים אוטומטיים? האם אתם מציעים גיבויים שעתיים ל-Realtime Database?

גיבויים אוטומטיים הם תכונה מתקדמת לפרויקטים במינוי Blaze בתשלום לפי שימוש. התכונה הזו מגבה את נתוני Firebase Realtime Database פעם ביום ומעלה אותם אל Google Cloud Storage.

אנחנו לא מציעים גיבויים שעתיים.

למה רוחב הפס המדווח של Realtime Database היה נמוך מהממוצע בין ספטמבר 2016 למרץ 2017?

בחישובי רוחב הפס, בדרך כלל אנחנו כוללים את התקורה של הצפנת SSL (על סמך שכבה 5 של מודל OSI). עם זאת, בספטמבר 2016, הוספנו באג שגרם לכך שהדיווח על רוחב הפס התעלם מהתקורה של ההצפנה. יכול להיות שבגלל זה, במשך כמה חודשים רוחב הפס והחיובים שדווחו בחשבון היו נמוכים באופן מלאכותי.

בסוף מרץ 2017 פרסמנו תיקון לבאג, והדיווח על רוחב הפס והחיוב חזרו לרמות הרגילות.