מלכודת ה-JOIN ב-Firestore
אתם נתקלים בבעיה נפוצה ב-Firestore. פונקציית ה-Firebase שלכם זורקת שגיאת גודל אצווה (batch size) מקסימלי. אתם צריכים לבצע JOIN בין הזמנות (orders) ללקוחות (customers) עבור לוח בקרה (dashboard). בדרך כלל משכפלים נתונים כדי לפתור זאת. אבל עכשיו הנתונים שלכם מיושנים ואינם עקביים.
גוגל הכריזה על ה-Pipelines API כדי לפתור זאת. הוא מאפשר פעולות JOIN בין אוספים (collections) ללא שכפול נתונים. חלק מהמפתחים מדווחים על זמני שאילתה מהירים בבדיקות קטנות.
ביליתי שבוע בבדיקת ה-API הזה תחת עומס כבד. הנה מה שהתיעוד לא אומר לכם.
עלויות גבוהות כל הרצה של pipeline קוראת מכל האוספים המעורבים. JOIN בין שני אוספים מחייב אתכם על קריאות בשניהם. אם אתם מבצעים JOIN בין שני אוספים של 50,000 מסמכים, העלויות שלכם גדלות בצורה לא יעילה. זו לא עלות ליניארית פשוטה.
מגבלות ביצועים בבדיקות שלי, pipeline מול 10,000 מסמכים לקח 380ms. כשבדקתי 100,000 מסמכים, השאילתה עברה timeout ב-30 שניות. אתם לא פותרים את הבעיה. אתם רק הופכים שגיאת batch לשגיאת timeout.
בעיות Cold Start Pipelines יוצרים הקשר הרצה (execution context) נפרד. בסביבות serverless כמו Cloud Functions, זה מוסיף עיכוב של 2 עד 4 שניות. המשתמשים שלכם יחשבו שהאפליקציה שלכם איטית.
ה-Pipelines API הוא כלי לאבות-טיפוס (prototyping) או לאוספים קטנים של פחות מ-5,000 מסמכים. הוא אינו תחליף למסד נתונים רלציוני. גוגל מספקת זאת כדי לעזור לכם להישאר באקו-סיסטם של Firebase במקום לעבור ל-PostgreSQL או Spanner.
אם אתם משתמשים ב-Pipelines, עקבו אחר הכללים הבאים:
• בדקו את גודל האוסף שלכם. אם אוסף עולה על 20,000 מסמכים, חשבו תחילה את עלות ה-JOIN. • הגבילו מורכבות. JOIN בין שלושה או יותר אוספים הוא סימן רע. • עקבו אחר עלויות קריאה מדי שבוע. קריאות Pipeline מופיעות בצורה שונה בחשבונית שלכם. • שמרו על הנתונים ה-denormalized שלכם. השתמשו ב-Pipelines כתוספת, לא כתחליף מלא. • בדקו עם תעבורה אמיתית. מבחני ביצועים (benchmarks) על אוספים שקטים אינם משקפים את המציאות בסביבת הייצור (production).
אל תשתמשו בפלסטר כדי להימנע מהחלטה ארכיטקטונית אמיתית.
איך אתם מטפלים בקשרים ב-Firestore? האם אתם משתמשים ב-denormalization או ב-client-side joins? ספרו לי בתגובות.