פתרון בעיות

בדף הזה מוסבר איך לפתור בעיות ב-Firestore במצב Datastore.

זמן אחזור

בטבלה הבאה מתוארות סיבות אפשריות לעלייה בזמן האחזור:

הסיבה לזמן האחזור סוגי הפעולות שהושפעו רזולוציה
תנועה מתמשכת שחורגת מכלל 500-50-5. קריאה, כתיבה

כדי להתמודד עם עלייה מהירה בנפח התנועה, מצב Datastore מנסה לבצע התאמה לעומס (auto-scaling) באופן אוטומטי כדי לעמוד בביקוש המוגבר. כשמצב Datastore מתרחב, זמן האחזור מתחיל להתקצר.

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

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

צריך להקטין את קצב הכתיבה ליישויות בודדות.

בודקים את הבידוד והעקביות של העסקאות ואת אופן השימוש בעסקאות.

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

קודי שגיאה

בקטע הזה מפורטות בעיות שאתם עשויים להיתקל בהן, ומוצעות הצעות לפתרון כל אחת מהן.

DEADLINE_EXCEEDED

DEADLINE_EXCEEDED

A deadline was exceeded on the server.

כדי לפתור את הבעיה, אפשר לעיין במדריך לפתרון בעיות שקשורות לזמן האחזור.

הופסקה

המצבים הבאים עלולים להגדיל את מספר השגיאות מסוג ABORTED:

  • ישויות שמקבלות יותר מדי עדכונים בשנייה.
  • התנגשות מעסקאות חופפות.
  • גידולים בתנועת הגולשים שחורגים מכלל 500-50-5 או שנתקלים בנקודות חמות.
ABORTED

Too much contention on these datastore entities. Please try again.

או

ABORTED

Aborted due to cross-transaction contention. This occurs when multiple
transactions attempt to access the same data, requiring Datastore mode
to abort at least one in order to enforce serializability.

כדי לפתור את הבעיה:

  • במקרים של עלייה מהירה בתנועה, מצב Datastore מנסה לבצע התאמה לעומס (autoscaling) באופן אוטומטי כדי לעמוד בביקוש המוגבר. כשהמערכת במצב Datastore מתרחבת, זמן האחזור מתחיל להתקצר.
  • האזורים הפעילים מגבילים את היכולת של מצב Datastore להתרחב. כדי לזהות אזורים פעילים, מומלץ לעיין במאמר בנושא תכנון לצורך הרחבה.
  • בודקים את התחרות על נתונים בעסקאות ואת השימוש שלכם בעסקאות.
  • צריך להקטין את קצב הכתיבה ליישויות בודדות.

RESOURCE_EXHAUSTED

המצבים הבאים עלולים לגרום לשגיאות RESOURCE_EXHAUSTED:

חרגתם מהמכסה של רמת השירות בחינם והחיוב לא מופעל בפרויקט שלכם.

RESOURCE_EXHAUSTED

Some resource has been exhausted, perhaps a per-user quota, or perhaps the entire file system is out of space.

כדי לפתור את הבעיה:

INVALID_ARGUMENT

השגיאות של INVALID_ARGUMENT יכולות להיגרם מהמצבים הבאים:

  • ניסיון לבצע קומיט של ישות עם ערך מאפיין מאונדקס שגדול מ-1,500 בייט. המגבלה הזו חלה על קידוד UTF-8 של ערך המאפיין.
  • ניסיון לבצע קומיט של ישות עם ערכי מאפיינים לא מפונדקסים שגדולים מ-1,048,487 בייט (1 מיביבייט – 89 בייט). המגבלה הזו חלה על סכום ערכי המאפיינים בישות. לדוגמה, ארבעה נכסים של 256KiB כל אחד חורגים מהמגבלה.

‫1,500 בייט (מאונדקס) ו-1,048,487 בייט (לא מאונדקס) הם המגבלות של ערכי המאפיינים. אי אפשר לחרוג מהמגבלות האלה, והן לא מכסות שאפשר לשנות.

INVALID_ARGUMENT: The value of property property-name is longer than 1500 bytes

או

INVALID_ARGUMENT: The value of property property_name is longer than 1048487 bytes

כדי לפתור את הבעיה:

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