Firestore मधील JOIN चा सापळा
तुम्हाला Firestore मधील एका सामान्य समस्येचा सामना करावा लागतो. तुमची Firebase function 'maximum batch size error' देते. डॅशबोर्डसाठी तुम्हाला orders आणि customers एकत्र (join) करावे लागतात. हे सोडवण्यासाठी तुम्ही सहसा डेटा डुप्लिकेट करता. पण आता तुमचा डेटा जुना (stale) आणि विसंगत (inconsistent) झाला आहे.
हे सोडवण्यासाठी Google ने Pipelines API जाहीर केले आहे. हे डेटा डुप्लिकेट न करता विविध collections मध्ये JOIN ऑपरेशन्स करण्याची परवानगी देते. काही डेव्हलपर्सनी लहान चाचण्यांमध्ये जलद क्वेरी वेळेचा (query times) अहवाल दिला आहे.
मी एका आठवड्यासाठी मोठ्या लोडखाली (heavy load) या API चे परीक्षण केले. डॉक्युमेंटेशनमध्ये जी माहिती दिली नाही, ती खालीलप्रमाणे आहे.
1. उच्च खर्च (High Costs)
प्रत्येक pipeline execution मध्ये संबंधित सर्व collections मधून डेटा वाचला (read) जातो. दोन collections मधील JOIN साठी तुम्हाला दोन्ही collections मधील reads साठी शुल्क द्यावे लागते. जर तुम्ही ५०,००० डॉक्युमेंट्स असलेल्या दोन collections एकत्र केल्या, तर तुमचा खर्च खूप वेगाने वाढतो. हा खर्च साधा रेषीय (linear) नसतो.
2. कामगिरीच्या मर्यादा (Performance Limits)
माझ्या चाचण्यांमध्ये, १०,००० डॉक्युमेंट्ससाठी pipeline ला ३८०ms लागले. जेव्हा मी १,००,००० डॉक्युमेंट्सची चाचणी घेतली, तेव्हा क्वेरी ३० सेकंदात 'timeout' झाली. तुम्ही समस्या सोडवत नाही आहात, तर तुम्ही फक्त 'batch error' चे रूपांतर 'timeout error' मध्ये करत आहात.
3. कोल्ड स्टार्टच्या समस्या (Cold Start Issues)
Pipelines एक वेगळा execution context तयार करतात. Cloud Functions सारख्या serverless वातावरणात, यामुळे २ ते ४ सेकंदांचा विलंब होतो. तुमच्या वापरकर्त्यांना वाटेल की तुमचे ॲप संथ (slow) आहे.
Pipelines API हे प्रोटोटाइपिंगसाठी किंवा ५,००० पेक्षा कमी डॉक्युमेंट्स असलेल्या लहान collections साठी एक साधन आहे. हे relational database ला पर्याय नाही. PostgreSQL किंवा Spanner कडे जाण्याऐवजी तुम्ही Firebase ecosystem मध्येच राहावे यासाठी Google हे साधन उपलब्ध करून देत आहे.
जर तुम्ही Pipelines वापरत असाल, तर या नियमांचे पालन करा:
• तुमच्या collection च्या आकाराचे ऑडिट करा. जर एखादे collection २०,००० डॉक्युमेंट्सपेक्षा जास्त असेल, तर प्रथम JOIN चा खर्च मोजा. • गुंतागुंत मर्यादित ठेवा. तीन किंवा अधिक collections मधील JOIN करणे हे वाईट लक्षण आहे. • दर आठवड्याला read खर्च ट्रॅक करा. तुमच्या बिलावर Pipeline reads वेगळ्या पद्धतीने दिसतात. • तुमचा denormalized डेटा तसाच ठेवा. Pipelines चा वापर पूरक म्हणून करा, पूर्ण पर्यायासारखा नाही. • वास्तविक ट्रॅफिकसह चाचणी करा. शांत (quiet) collections वरील बेंचमार्क प्रत्यक्ष उत्पादनातील (production) वास्तव दर्शवत नाहीत.
वास्तविक आर्किटेक्चरल निर्णय टाळण्यासाठी तात्पुरता उपाय (band-aid) वापरू नका.
तुम्ही Firestore मध्ये रिलेशनशिप्स कसे हाताळता? तुम्ही denormalization वापरता की client-side joins? मला कमेंट्समध्ये सांगा.