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

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

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

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

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

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

फ़ंक्शन और Continuity

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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