नेटिव मोड में Firestore के बारे में खास जानकारी

नेटिव मोड में Firestore में, दो तरह के ऑपरेशन होते हैं - Firestore के मुख्य ऑपरेशन और Firestore के पाइपलाइन ऑपरेशन.

Firestore के मुख्य ऑपरेशन, दस्तावेज़ बनाने, पढ़ने, अपडेट करने, और मिटाने (सीआरयूडी) की स्टैंडर्ड सुविधा देते हैं. इसके अलावा, इनमें रीयल-टाइम में क्वेरी सुनने और ऑफ़लाइन मोड में डेटा सेव करने की सुविधा भी होती है. इस वर्शन में, एक अहम अंतर यह है कि इंडेक्स बनाना ज़रूरी नहीं है. साथ ही, सिंगल फ़ील्ड के लिए इंडेक्स अपने-आप नहीं बनते. इससे, इंडेक्स को पहले से कॉन्फ़िगर किए बिना क्वेरी को चलाया जा सकता है. हालांकि, इंडेक्स न की गई क्वेरी, डिफ़ॉल्ट रूप से पूरे कलेक्शन को स्कैन करेंगी. डेटासेट बढ़ने पर, इससे इंतज़ार का समय और लागत बढ़ सकती है.

Firestore के पाइपलाइन ऑपरेशन, Firestore Enterprise वर्शन की एक मुख्य सुविधा है. इसे क्वेरी इंजन के ऐडवांस वर्शन पर बनाया गया है, ताकि क्वेरी की रेंज को बढ़ाया जा सके. पाइपलाइन ऑपरेशन में, क्वेरी के लिए फ़्लेक्सिबल सिंटैक्स और इंडेक्सिंग का अलग तरीका इस्तेमाल किया जाता है. इसमें इंडेक्स बनाना ज़रूरी नहीं है. साथ ही, इंडेक्स अपने-आप नहीं बनते. इससे, ऐप्लिकेशन के लिए डेटा वापस पाने के ऐडवांस ऑपरेशन किए जा सकते हैं.

Firestore के मुख्य ऑपरेशन की सुविधाएं

मुख्य ऑपरेशन की मदद से, सीआरयूडी के स्टैंडर्ड ऑपरेशन और रीयल-टाइम में क्वेरी सुनने की सुविधा मिलती है. हालांकि, Enterprise वर्शन पर इन ऑपरेशन का इस्तेमाल करने पर, इंडेक्सिंग और बिलिंग से जुड़े व्यवहार में, स्टैंडर्ड वर्शन के मुकाबले काफ़ी अंतर होता है.

फ़ंक्शन और जारी रखने की सुविधा

मुख्य ऑपरेशन में, स्टैंडर्ड वर्शन में इस्तेमाल किया जाने वाला, मेथड-चेनिंग सिंटैक्स (उदाहरण के लिए, .where(), .orderBy()) बरकरार रहता है. इन ऑपरेशन में, मोबाइल और वेब क्लाइंट के लिए रीयल-टाइम में क्वेरी सुनने और ऑफ़लाइन मोड में डेटा सेव करने की सुविधा मिलती है. हमारा सुझाव है कि इन ऑपरेशन का इस्तेमाल, स्टैंडर्ड ट्रांज़ैक्शनल वर्कलोड, सामान्य लुकअप, और मौजूदा ऐप्लिकेशन कोड माइग्रेशन के लिए किया जाए.

कस्टम इंडेक्सिंग

Enterprise वर्शन में, मुख्य ऑपरेशन के तहत सिंगल-फ़ील्ड इंडेक्स अपने-आप नहीं बनते. जबकि, स्टैंडर्ड वर्शन में ऐसा होता है. इंडेक्स बनाना ज़रूरी नहीं है. क्वेरी चलाने के लिए इंडेक्स की ज़रूरत नहीं होती. अगर कोई खास इंडेक्स मौजूद नहीं है, तो क्वेरी पूरे कलेक्शन को स्कैन करती है. इंडेक्स न की गई क्वेरी से, रैपिड प्रोटोटाइपिंग की जा सकती है. हालांकि, डेटासेट बढ़ने पर, इनकी परफ़ॉर्मेंस धीमी हो सकती है और लागत बढ़ सकती है. डेवलपर को क्वेरी की परफ़ॉर्मेंस ऑप्टिमाइज़ करने और रीड यूनिट की खपत कम करने के लिए, इंडेक्स मैन्युअल तरीके से बनाने होंगे.

बिलिंग मॉडल (यूनिट के हिसाब से)

रीड यूनिट का शुल्क, हर दस्तावेज़ की संख्या के हिसाब से नहीं, बल्कि 4 केबी के हिसाब से लिया जाता है. इंडेक्स न की गई क्वेरी से, बड़े कलेक्शन को स्कैन करने पर, सभी दस्तावेज़ों में स्कैन किए गए कुल बाइट के हिसाब से रीड यूनिट की खपत होगी. राइट यूनिट का शुल्क, 1 केबी के हिसाब से लिया जाता है. किसी दस्तावेज़ को लिखने पर, डेटा के लिए यूनिट के साथ-साथ, अपडेट की गई हर इंडेक्स एंट्री के लिए अतिरिक्त यूनिट की खपत होती है. स्टैंडर्ड वर्शन में, सिंगल-फ़ील्ड इंडेक्सिंग अपने-आप होती है. हालांकि, अब Enterprise वर्शन में, राइट की लागत और परफ़ॉर्मेंस ऑप्टिमाइज़ करने के लिए, इंडेक्स करने के लिए खास फ़ील्ड चुने जा सकते हैं.

Firestore के पाइपलाइन ऑपरेशन की सुविधाएं

पाइपलाइन ऑपरेशन के साथ Firestore Enterprise वर्शन, क्वेरी इंजन के ऐडवांस वर्शन का इस्तेमाल करता है. इससे, Firestore Standard वर्शन की कई मौजूदा सीमाएं खत्म हो जाती हैं. पाइपलाइन ऑपरेशन में, क्वेरी की सैकड़ों अतिरिक्त सुविधाएं मिलती हैं. पाइपलाइन ऑपरेशन में ये सुविधाएं मिलती हैं:

स्टेज-आधारित कंपोज़ेबल सिंटैक्स

पाइपलाइन क्वेरी, क्रम से चलने वाले स्टेज की सीरीज़ तय करके बनाई जाती हैं. ये स्टेज क्रम से चलते हैं. इससे, जटिल ऑपरेशन किए जा सकते हैं. जैसे, एग्रीगेशन के नतीजे के आधार पर फ़िल्टर करना. पहले यह सुविधा उपलब्ध नहीं थी.

यहां एक पाइपलाइन क्वेरी का उदाहरण दिया गया है. इससे, पिछले महीने में देखे गए यूनीक प्रॉडक्ट आईडी की संख्या का पता चलता है:

guard let cutoffDate = Calendar.current.date(byAdding: .month, value: -1, to: Date()) else {
  return
}
let snapshot = try await db.pipeline()
  .collection("productViews")
  .where(Field("viewedAt").greaterThan(cutoffDate.timeIntervalSince1970))
  .aggregate([Field("productId").countDistinct().as("uniqueProductViews")])
  .execute()

बढ़ी हुई सुविधाएं

पाइपलाइन क्वेरी में, कई नई सुविधाएं मिलती हैं. इनमें ये शामिल हैं:

• एग्रीगेशन: आर्बिट्ररी ग्रुपिंग फ़ील्ड के साथ, एग्रीगेशन के नए फ़ंक्शन (जैसे, sum(...), min(...), और count_distinct(...)) के लिए सहायता.
• रिलेशनल जॉइन: कोरिलेटेड सबक्वेरी का इस्तेमाल करके, कलेक्शन और सबकलेक्शन में सर्वर-साइड जॉइन करना.
• जटिल फ़िल्टरिंग: where(...) स्टेटमेंट को आर्बिट्ररी तरीके से जटिल बनाने के लिए, सैकड़ों अतिरिक्त फ़ंक्शन के लिए सहायता. इनमें regex_match(...), add(...), और str_contains(...) शामिल हैं. इन सभी के लिए, इंडेक्स की ज़रूरी शर्तें लागू नहीं होती हैं.
• आंशिक तौर पर पढ़ना / प्रोजेक्शन: select(...), remove_fields(...), और दस्तावेज़ में बदलाव करने के कई अन्य स्टेज का इस्तेमाल करके, दस्तावेज़ों के डाइनैमिक सबसेट वापस पाना.

इन सुविधाओं के बारे में ज़्यादा जानने के लिए, पाइपलाइन ऑपरेशन की मदद से क्वेरी करना लेख पढ़ें.

रीयल-टाइम और ऑफ़लाइन सहायता

रीयल-टाइम और ऑफ़लाइन सहायता का इस्तेमाल करने के लिए, डेवलपर Firestore Enterprise वर्शन में Firestore के मुख्य ऑपरेशन का इस्तेमाल कर सकते हैं.

क्लाइंट और टूलिंग इंटिग्रेशन

Enterprise वर्शन में, पाइपलाइन क्वेरी के साथ इंटरैक्ट करने और उन्हें मैनेज करने के लिए, खास सुविधाएं शामिल हैं:

• क्वेरी की जानकारी और प्रोफ़ाइलिंग: क्वेरी की जानकारी के नतीजों का इस्तेमाल करके, यह समझा जा सकता है कि कोई क्वेरी, कितनी रीड या राइट यूनिट की खपत करती है. साथ ही, इसके एक्ज़ीक्यूशन का विश्लेषण किया जा सकता है.
• क्वेरी की अहम जानकारी: Enterprise वर्शन में, क्वेरी की अहम जानकारी की सुविधा मिलती है. इससे यह तय करने में मदद मिलती है कि परफ़ॉर्मेंस और लागत को बेहतर बनाने के लिए, इंडेक्स कहां बनाए जा सकते हैं. इसके लिए, डेटाबेस पर चलने वाली सबसे अहम क्वेरी और उनकी परफ़ॉर्मेंस की जानकारी मिलती है
• इंडेक्स के नए टाइप: Enterprise वर्शन के लिए, खास इंडेक्स बनाए जा सकते हैं. इनमें स्पार्स, नॉन-स्पार्स, और यूनीक इंडेक्स जैसे इंडेक्स टाइप शामिल हैं. इसमें, Enterprise डेटाबेस के लिए वेक्टर सर्च इंडेक्स बनाने और उनमें बदलाव करने की सुविधा भी मिलती है.

Firestore Standard वर्शन और Firestore Enterprise वर्शन के बीच अंतर

मुख्य ऑपरेशन और पाइपलाइन ऑपरेशन के बीच, ऑपरेशन से जुड़ा मुख्य अंतर इंडेक्सिंग को मैनेज करने में है. इससे परफ़ॉर्मेंस और लागत पर सीधे असर पड़ता है.