The Firestore JOIN का जाल
आप एक आम Firestore समस्या का सामना करते हैं। आपका Firebase function 'maximum batch size error' देता है। आपको डैशबोर्ड के लिए orders और customers को join करने की आवश्यकता है। इसे ठीक करने के लिए आप आमतौर पर डेटा को duplicate कर देते हैं। लेकिन अब आपका डेटा पुराना और असंगत हो गया है।
Google ने इसे हल करने के लिए Pipelines API की घोषणा की। यह डेटा को duplicate किए बिना collections के बीच JOIN operations की अनुमति देता है। कुछ डेवलपर्स ने छोटे परीक्षणों में तेज़ query समय की रिपोर्ट दी है।
मैंने भारी लोड के तहत इस API का परीक्षण करने में एक सप्ताह बिताया। यहाँ वह जानकारी है जो डॉक्यूमेंटेशन आपको नहीं बताता है।
उच्च लागत (High Costs) हर pipeline execution शामिल सभी collections से डेटा पढ़ता है। दो collections के बीच एक JOIN आपको दोनों में होने वाले reads के लिए बिल करता है। यदि आप 50,000 documents वाले दो collections को join करते हैं, तो आपकी लागत बहुत तेज़ी से बढ़ेगी। यह कोई साधारण रैखिक (linear) लागत नहीं है।
प्रदर्शन की सीमाएँ (Performance Limits) मेरे परीक्षणों में, 10,000 documents के विरुद्ध एक pipeline में 380ms लगे। जब मैंने 100,000 documents का परीक्षण किया, तो query 30 सेकंड में timeout हो गई। आप समस्या को हल नहीं कर रहे हैं। आप बस एक batch error को timeout error में बदल रहे हैं।
कोल्ड स्टार्ट की समस्याएँ (Cold Start Issues) Pipelines एक अलग execution context बनाते हैं। Cloud Functions जैसे serverless environments में, यह 2 से 4 सेकंड का विलंब (delay) जोड़ देता है। आपके उपयोगकर्ताओं को लगेगा कि आपका ऐप धीमा है।
Pipelines API प्रोटोटाइपिंग या 5,000 documents से कम वाले छोटे collections के लिए एक टूल है। यह relational database का विकल्प नहीं है। Google इसे इसलिए प्रदान करता है ताकि आप PostgreSQL या Spanner पर जाने के बजाय Firebase ecosystem में ही बने रहें।
यदि आप Pipelines का उपयोग करते हैं, तो इन नियमों का पालन करें:
• अपने collection के आकार का ऑडिट करें। यदि कोई collection 20,000 documents से अधिक हो जाता है, तो पहले JOIN लागत की गणना करें। • जटिलता को सीमित करें। तीन या अधिक collections के बीच JOIN एक बुरा संकेत है। • साप्ताहिक रूप से read लागत को ट्रैक करें। Pipeline reads आपके बिल में अलग तरह से दिखाई देते हैं। • अपने denormalized डेटा को बनाए रखें। Pipelines का उपयोग एक पूरक (supplement) के रूप में करें, पूर्ण विकल्प के रूप में नहीं। • वास्तविक ट्रैफिक के साथ परीक्षण करें। कम ट्रैफिक वाले collections पर किए गए बेंचमार्क प्रोडक्शन की वास्तविकता को नहीं दर्शाते हैं।
वास्तविक आर्किटेक्चरल निर्णय से बचने के लिए किसी अस्थायी समाधान का उपयोग न करें।
आप Firestore में relationships को कैसे संभालते हैं? क्या आप denormalization या client-side joins का उपयोग करते हैं? मुझे कमेंट्स में बताएं।