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

Firestore in Native mode में, दो तरह के ऑपरेशन होते हैं - Firestore Core operations और Firestore Pipeline operations.

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

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

Firestore Core operations की सुविधाएं

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

सुविधाएं और डेटा की उपलब्धता

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

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

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

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

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

Firestore Pipeline operations की सुविधाएं

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

स्टेज के हिसाब से कंपोज़ किया जा सकने वाला सिंटैक्स

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

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

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 Core operations का इस्तेमाल कर सकते हैं.

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

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

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

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

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