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

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

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

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

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

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

फ़ंक्शन और Continuity

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

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

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

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

रीड यूनिट का शुल्क, दस्तावेज़ की संख्या के हिसाब से नहीं, बल्कि 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 वर्शन में Firestore की मुख्य कार्रवाइयों का इस्तेमाल कर सकते हैं.

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

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

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

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

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

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

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

इंडेक्स की ज़रूरत नहीं होती. इसलिए, क्वेरी के लिए इंडेक्स का इस्तेमाल करना ज़रूरी नहीं है.

ज़रूरत के हिसाब से इंडेक्स तय किए जाते हैं. Enterprise वर्शन में, इंडेक्स के ज़्यादा टाइप इस्तेमाल किए जा सकते हैं. जैसे, नॉन-स्पार्स/स्पार्स और यूनीक इंडेक्स.

इंडेक्स किए गए फ़ील्ड अगर इंडेक्स किए गए फ़ील्ड में __name__ फ़ील्ड मौजूद नहीं है, तो इसे अपने-आप जोड़ दिया जाता है. __name__ को इंडेक्स किए गए फ़ील्ड में अपने-आप नहीं जोड़ा जाता. अगर आपके ऐप्लिकेशन के लिए इंडेक्स किए गए फ़ील्ड में __name__ को साफ़ तौर पर बताना ज़रूरी है, तो आपको ऐसा करना होगा.
क्रम से लगाने की सुविधा को सामान्य बनाना क्वेरी के order by क्लॉज़ को सामान्य किया जाता है. इसके लिए, आखिर में असमानता वाले फ़ील्ड और __name__ फ़ील्ड जोड़ा जाता है. हालांकि, ऐसा तब किया जाता है, जब ये फ़ील्ड पहले से मौजूद न हों. इससे यह पक्का होता है कि नतीजों को एक खास क्रम में लगाया गया है. भले ही, क्रम के हिसाब से लगाने वाली क्लॉज़ में कोई अन्य फ़ील्ड मौजूद हो. सॉर्ट करने के क्रम को सामान्य नहीं किया गया है. sort a ASC जैसे क्रम से लगाने के तरीके से सिर्फ़ यह गारंटी मिलती है कि नतीजों को फ़ील्ड a के हिसाब से क्रम से लगाया गया है. Cloud Firestore आपके मौजूदा इंडेक्स का इस्तेमाल करके, नतीजों को सबसे सही क्रम में दिखाएगा. इसलिए, अगर a, नतीजों के सेट में यूनीक नहीं है, तो इंडेक्स कॉन्फ़िगरेशन, एक्ज़ीक्यूशन की रणनीतियों वगैरह के आधार पर, नतीजों का क्रम अलग-अलग क्वेरी के लिए अलग-अलग हो सकता है. नतीजों के क्रम को यूनीक और तय करने योग्य बनाने के लिए, आपको क्रम में एक यूनीक फ़ील्ड जोड़ना होगा. जैसे, __name__.
परफ़ॉर्मेंस इंडेक्स की गई क्वेरी: परफ़ॉर्मेंस और लागत, आपके नतीजों के सेट के साइज़ के हिसाब से बढ़ती है.

अनइंडेक्स्ड क्वेरी: परफ़ॉर्मेंस और लागत, आपके डेटासेट के साइज़ के हिसाब से तय होती है.

इंडेक्स की गई क्वेरी: परफ़ॉर्मेंस और लागत, आपके नतीजों के सेट के साइज़ के हिसाब से बढ़ती है.

हमारा सुझाव है कि इंडेक्स बनाने के लिए, क्वेरी की व्याख्या करने और क्वेरी की अहम जानकारी देने वाले टूल का इस्तेमाल करें. इससे आपकी क्वेरी की परफ़ॉर्मेंस बेहतर होगी और लागत कम होगी.

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

उदाहरणों की मदद से, नई कीमत के बारे में जानें.

सुरक्षा के नियम सुरक्षा के नियम, पढ़ने/लिखने की अनुमतियों की पुष्टि करके कलेक्शन को सुरक्षित रखते हैं. सुरक्षा के नियम, पढ़ने/लिखने की अनुमतियों की पुष्टि करके कलेक्शन को सुरक्षित रखते हैं. डेटा मॉडल गाइड में, पाइपलाइन की क्वेरी के लिए अपने डेटा को मॉडल करने का तरीका जानें.