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

Firestore के नेटिव मोड में दो तरह के ऑपरेशन होते हैं - Firestore Core और Firestore Pipeline ऑपरेशन.

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

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

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

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

फ़ंक्शन और Continuity

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

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

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

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

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

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

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

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

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

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

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 और Firestore Enterprise के बीच अंतर

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