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

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

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

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

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

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

सुविधा और उपलब्धता

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

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

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

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

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

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

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

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

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

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

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(...)) के साथ-साथ, ग्रुपिंग के लिए अपनी पसंद के मुताबिक फ़ील्ड इस्तेमाल किए जा सकते हैं.
• रिलेशनल जॉइन: कोरिलेटेड सबक्वेरी का इस्तेमाल करके, कलेक्शन और सबकलेक्शन में सर्वर-साइड जॉइन किए जा सकते हैं.
• जटिल फ़िल्टरिंग: इसमें, regex_match(...), add(...) और str_contains(...) जैसी सैकड़ों अतिरिक्त फ़ंक्शन का इस्तेमाल करके, where(...) स्टेटमेंट को अपनी पसंद के मुताबिक बनाया जा सकता है. इसके लिए, इंडेक्स की ज़रूरत नहीं होती.
• आंशिक रीड / प्रोजेक्शन: select(...), remove_fields(...), और दस्तावेज़ में बदलाव करने के कई अन्य चरणों का इस्तेमाल करके, दस्तावेज़ों के डाइनैमिक सबसेट वापस पाए जा सकते हैं.

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

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

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

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

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

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

Firestore Standard edition और Firestore Enterprise edition के बीच अंतर

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