इस पेज पर, नेटिव मोड डेटाबेस में डेटा ऐक्सेस करने के लिए उपलब्ध अलग-अलग इंटरफ़ेस के बारे में बताया गया है.
ऑपरेशन इंटरफ़ेस
नेटिव मोड में, डेटा ऐक्सेस करने के लिए दो इंटरफ़ेस उपलब्ध होते हैं:
पाइपलाइन की कार्रवाइयां
Cloud Firestore के लिए नया क्वेरी इंटरफ़ेस. पाइपलाइन ऑपरेशन, स्टेज के हिसाब से कंपोज़ किए जा सकने वाले सिंटैक्स के साथ काम करते हैं. किसी ऑपरेशन को बनाने के लिए, क्रम से चरणों को तय किया जाता है. इन चरणों को क्रम से लागू किया जाता है. इससे मुश्किल कार्रवाइयां की जा सकती हैं. जैसे, एग्रीगेशन के नतीजे के आधार पर फ़िल्टर करना. पहले, मूल इंटरफ़ेस (कोर ऑपरेशंस) में ऐसा नहीं किया जा सकता था.
पाइपलाइन ऑपरेशन सिर्फ़ Firestore Enterprise वर्शन में उपलब्ध हैं. साथ ही, ये प्रीव्यू लॉन्च स्टेज में हैं.
मुख्य कार्रवाइयां
मुख्य कार्रवाइयां, Cloud Firestore के लिए ओरिजनल इंटरफ़ेस हैं.
दस्तावेज़ों को वापस पाने के लिए, कोर ऑपरेशंस, दस्तावेज़ या कलेक्शन रेफ़रंस पर मेथड-चेनिंग सिंटैक्स (.where(), .orderBy(), .get()) का इस्तेमाल करता है.
क्वेरी के चरणों का क्रम तय होता है और एग्रीगेशन की सुविधा सीमित होती है.
कोर ऑपरेशन, Enterprise और Standard, दोनों वर्शन में उपलब्ध हैं. हालांकि, इंडेक्स के डिफ़ॉल्ट, दोनों वर्शन में बहुत अलग-अलग होते हैं. ज़्यादा जानकारी के लिए, अगला सेक्शन देखें.
अलग-अलग वर्शन के इंटरफ़ेस में अंतर
Enterprise वर्शन में नेटिव मोड की सुविधा उपलब्ध होने के बाद, Firestore Core और Pipeline, दोनों का इस्तेमाल किया जा सकता है. Enterprise वर्शन में कोर ऑपरेशंस का इस्तेमाल करने पर, इंडेक्स के नए तरीके और कीमत तय करने के मॉडल से Standard वर्शन की कई पाबंदियां हट जाती हैं.
| सुविधा | स्टैंडर्ड एडिशन | Enterprise वर्शन |
| इन कार्रवाइयों के लिए यह सुविधा उपलब्ध है | यह Firestore के मुख्य ऑपरेशनों तक सीमित है. | Firestore Core और Pipeline के साथ-साथ Firestore MongoDB के साथ काम करने वाले ऑपरेशन के साथ काम करता है. |
| इंडेक्स करने से जुड़ी ज़रूरी शर्तें | सभी क्वेरी के लिए इंडेक्स ज़रूरी होते हैं. | क्वेरी के लिए इंडेक्स की ज़रूरत नहीं होती. |
| इंडेक्स बनाना | अपने-आप बनने वाले इंडेक्स, सिंगल फ़ील्ड के लिए बनाए जाते हैं. कंपोज़िट इंडेक्स को मैन्युअल तरीके से बनाया जा सकता है. | कोई अपने-आप बनने वाला इंडेक्स नहीं बनाया जाता. इंडेक्स को मैन्युअल तरीके से मैनेज करना होता है. |
| इंडेक्स किए गए फ़ील्ड | अगर इंडेक्स किए गए फ़ील्ड में __name__ फ़ील्ड मौजूद नहीं है, तो इसे अपने-आप जोड़ दिया जाता है. | __name__ को इंडेक्स किए गए फ़ील्ड में अपने-आप नहीं जोड़ा जाता. अगर आपके ऐप्लिकेशन के लिए इंडेक्स किए गए फ़ील्ड में __name__ को साफ़ तौर पर बताना ज़रूरी है, तो आपको ऐसा करना होगा. |
| क्रम से लगाने की सुविधा को सामान्य बनाना | क्वेरी के order by क्लॉज़ को सामान्य किया जाता है. इसके लिए, आखिर में असमानता वाले फ़ील्ड और __name__ फ़ील्ड जोड़ा जाता है. हालांकि, ऐसा तब किया जाता है, जब ये फ़ील्ड पहले से मौजूद न हों. इससे यह पक्का होता है कि नतीजों को एक खास क्रम में लगाया गया है. भले ही, क्रम से लगाने की शर्त में कोई और फ़ील्ड शामिल हो. | सॉर्ट करने के क्रम को सामान्य नहीं किया गया है. sort a ASC जैसे क्रम से लगाने के तरीके से सिर्फ़ यह गारंटी मिलती है कि नतीजों को फ़ील्ड a के हिसाब से क्रम से लगाया गया है. Cloud Firestore आपके मौजूदा इंडेक्स का इस्तेमाल करके, नतीजों को सबसे सही क्रम में दिखाएगा. इसलिए, अगर a, नतीजों के सेट में यूनीक नहीं है, तो इंडेक्स कॉन्फ़िगरेशन, एक्ज़ीक्यूशन की रणनीतियों वगैरह के आधार पर, क्वेरी के हिसाब से नतीजों का क्रम अलग-अलग हो सकता है. नतीजों के क्रम को यूनीक और तय करने योग्य बनाने के लिए, आपको क्रम में एक यूनीक फ़ील्ड जोड़ना होगा. जैसे, __name__. |
| क्वेरी की परफ़ॉर्मेंस और लागत | आम तौर पर, इंडेक्स की ज़रूरी शर्तों की वजह से क्वेरी तेज़ी से काम करती हैं. | इंडेक्स बनाकर, क्वेरी की परफ़ॉर्मेंस और लागत को ऑप्टिमाइज़ करें. क्वेरी की व्याख्या करने और क्वेरी की अहम जानकारी देने वाली सुविधाओं का इस्तेमाल करके, यह पता लगाया जा सकता है कि कौनसे इंडेक्स मौजूद नहीं हैं.
डेटासेट के बढ़ने पर, इंडेक्स के बिना क्वेरी करने से परफ़ॉर्मेंस खराब हो सकती है और लागत बढ़ सकती है. इसलिए, इनकी निगरानी करना और इन्हें ट्यून करना ज़रूरी है. |
| इंडेक्सिंग की अतिरिक्त लागत | इंडेक्स लिखने के लिए कोई शुल्क नहीं लिया जाता, क्योंकि इंडेक्स अपने-आप बनते हैं. | किसी दस्तावेज़ को लिखते समय, इंडेक्स एंट्री लिखने के लिए राइट यूनिट का इस्तेमाल किया जाता है. इंडेक्स एंट्री के हर 1 केआईबी के लिए, एक राइट यूनिट का इस्तेमाल किया जाता है. हर फ़ील्ड के लिए इंडेक्स एंट्री न बनाने पर, आपको स्टोरेज के लिए कम शुल्क देना पड़ता है. |
| बिलिंग मॉडल (पढ़ता है/लिखता है/मिटाता है) | दस्तावेज़ पढ़ने, लिखने, और मिटाने के हिसाब से शुल्क लिया जाता है. | हर पढ़ने और लिखने (ट्रेंच) के लिए शुल्क लिया जाता है. पढ़ने के लिए, रीड यूनिट (4 केआईबी के ट्रेंच) के हिसाब से शुल्क लिया जाता है. लिखने और मिटाने के अनुरोधों को राइट यूनिट (1 KiB ट्रेंच) में मर्ज कर दिया जाता है. |
| बुनियादी कीमत (हर दस लाख के लिए)
दिखाए गए किराये, us-central1 क्षेत्र के लिए हैं |
पढ़ने का शुल्क: 1,00,000 दस्तावेज़ों के लिए 3 रुपये या 10 लाख दस्तावेज़ों के लिए 30 रुपये.
लिखने के लिए: 1,00,000 दस्तावेज़ों के लिए 0.09 डॉलर (या 10 लाख के लिए 0.90 डॉलर). मिटाने के लिए: हर 1,00,000 दस्तावेज़ों के लिए 0.01 डॉलर (या हर 10 लाख के लिए 0.10 डॉलर) |
यूनिट पढ़ना: 10 लाख यूनिट पढ़ने के लिए 5 रुपये.
राइट यूनिट: 10 लाख के लिए 26 रुपये राइट यूनिट. आम तौर पर, अगर दस्तावेज़ 4 केआईबी से कम हैं, तो उनकी कीमत स्टैंडर्ड रीड की लागत से कम होती है. |
| रीयल-टाइम अपडेट
दिखाए गए किराये, us-central1 क्षेत्र के लिए हैं |
रीयलटाइम अपडेट शामिल हैं और इसके लिए, हर 1,00,000 दस्तावेज़ों पर 0.03 डॉलर के हिसाब से बिल किया जाता है. | रीयलटाइम अपडेट के लिए, नया अलग एसकेयू (रीयलटाइम अपडेट यूनिट) उपलब्ध है. इसके लिए, हर 4 केआईबी ट्रेंच के हिसाब से शुल्क लिया जाता है. रीयलटाइम अपडेट के लिए, हर दस लाख रीड यूनिट पर 0.30 डॉलर का शुल्क लगता है. |