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

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

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

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

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

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

फ़ंक्शन और डेटा की उपलब्धता

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

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

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

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

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

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

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

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

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

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

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

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

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

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