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

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

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

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

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

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

फ़ंक्शन और कंटिन्यूटी

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

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

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

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

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

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 Edition में Firestore Core के ऑपरेशन का इस्तेमाल कर सकते हैं.

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

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

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

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

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