Firebase Firestore — यह क्या है, NoSQL दस्तावेज़ और संग्रह

Firebase Firestore क्या है

Firebase Firestore एक क्लाउड NoSQL डेटाबेस है जिसे Google ने 2019 में Realtime Database के उत्तराधिकारी के रूप में लॉन्च किया। Firestore Google Cloud Spanner और Google Cloud Datastore इंफ्रास्ट्रक्चर पर बनाया गया है, जो एकल ट्रांज़ेक्शन के भीतर मजबूत डेटा संगति और स्वचालित बहु-क्षेत्रीय प्रतिकृति प्रदान करता है। SDK Android, iOS, Web (JavaScript), Flutter, Kotlin Multiplatform और Unity का समर्थन करता है।

Realtime Database से विकास

Firestore की घोषणा Google I/O 2017 में “Cloud Firestore” के रूप में की गई थी — यह Realtime Database की प्रमुख सीमाओं को संबोधित करने वाला समाधान: जटिल क्वेरी समर्थन की कमी, कई नोड्स पर डेटा स्केल करने में असमर्थता और कमजोर संगति। Google (2026) के अनुसार, Firestore प्रति दिन 1 ट्रिलियन से अधिक अनुरोधों को संसाधित करता है और 80% नए Firebase प्रोजेक्ट्स के लिए डिफ़ॉल्ट डेटाबेस है। हालांकि, Realtime Database अपनी सीधी JSON संरचना के कारण अल्ट्रा-लो लेटेंसी परिदृश्यों (गेमिंग, सहयोगात्मक संपादन) के लिए प्रासंगिक बनी हुई है।

Firestore की मुफ्त सीमाएँ

Firestore Spark योजना पर उदार मुफ्त सीमा के साथ पे-एज़-यू-गो मॉडल पर पेश किया जाता है: 1 GB स्टोरेज, प्रति माह 10 GB नेटवर्क ट्रैफ़िक, प्रति दिन 50 हजार रीड ऑपरेशन, 20 हजार राइट ऑपरेशन और 20 हजार डिलीट ऑपरेशन। Blaze योजना पर, उपरोक्त सभी मुफ्त हैं, और अतिरिक्त उपयोग पर शुल्क लगता है: $0.06 प्रति 100 हजार रीड ऑपरेशन, $0.18 प्रति 100 हजार राइट ऑपरेशन। Google (2026) के अनुसार, 90% प्रोजेक्ट मुफ्त सीमा के भीतर रहते हैं।

डेटा मॉडल: संग्रह, दस्तावेज़ और फ़ील्ड

डेटा मॉडल Firestore का पदानुक्रमिक रूप से संगठित है: रूट में संग्रह होते हैं, प्रत्येक संग्रह में दस्तावेज़ होते हैं, प्रत्येक दस्तावेज़ में फ़ील्ड (प्रिमिटिव टाइप, ऐरे, Map) और नेस्टेड संग्रह (उप-संग्रह) होते हैं। संग्रहों की नेस्टिंग गहराई असीमित है, लेकिन एक दस्तावेज़ सीधे दूसरे दस्तावेज़ को शामिल नहीं कर सकता — केवल संदर्भ (Reference प्रकार) के माध्यम से।

संग्रह और दस्तावेज़

संग्रह स्वचालित रूप से उत्पन्न या उपयोगकर्ता-परिभाषित पहचानकर्ताओं वाले दस्तावेज़ों का एक कंटेनर है। प्रत्येक दस्तावेज़ 1 MiB आकार तक का JSON-जैसा ऑब्जेक्ट है। दस्तावेज़ फ़ील्ड स्ट्रिंग, संख्या, बूलियन मान, ऐरे, Map, टाइमस्टैम्प (Timestamp), जियोपॉइंट (GeoPoint) और अन्य दस्तावेज़ों के संदर्भ (Reference) हो सकते हैं। दस्तावेज़ का आकार सभी फ़ील्ड नामों सहित 1 MiB तक सीमित है।

बैच राइट और ट्रांज़ेक्शन

Firestore डेटाबेस स्तर पर एटॉमिक ट्रांज़ेक्शन का समर्थन करता है। एक ट्रांज़ेक्शन कई दस्तावेज़ पढ़ और लिख सकता है — Commit सभी परिवर्तनों को एटॉमिक रूप से लागू करता है या कुछ भी नहीं। प्रति ट्रांज़ेक्शन अधिकतम 500 ऑपरेशन, 60 सेकंड का टाइमआउट। बैच राइट बिना रीड चरण के एक गैर-ट्रांज़ेक्शनल एटॉमिक राइट ऑपरेशन है। वित्तीय लेन-देन, सीट बुकिंग और इन्वेंट्री प्रबंधन के लिए ट्रांज़ेक्शन महत्वपूर्ण हैं।

Firestore और Realtime Database की तुलना

Firestore और Realtime Database के बीच चयन प्रोजेक्ट की आवश्यकताओं पर निर्भर करता है। दोनों डेटाबेस Firebase इकोसिस्टम का हिस्सा हैं, रीयल-टाइम सिंक्रोनाइज़ेशन प्रदान करते हैं, और सभी प्लेटफ़ॉर्म पर उपलब्ध हैं, लेकिन डेटा मॉडल, स्केलिंग और मूल्य निर्धारण में मौलिक रूप से भिन्न हैं।

प्रमुख अंतर

Realtime Database डेटा को एक एकल JSON ट्री में संग्रहीत करता है, जो सरल संरचनाओं के लिए सुविधाजनक है लेकिन 3 स्तरों से अधिक गहरी नेस्टिंग के साथ स्केलिंग को कठिन बनाता है। Firestore स्वचालित शार्डिंग के साथ संग्रह-दस्तावेज़ मॉडल का उपयोग करता है, जो प्रदर्शन में गिरावट के बिना लाखों दस्तावेज़ों तक स्केल करने की अनुमति देता है। Google (2026) के अनुसार, Firestore बिना गति हानि के एक संग्रह में 10 हजार समवर्ती कनेक्शन का समर्थन करता है, जबकि Realtime Database एक इंस्टेंस में 200 हजार कनेक्शन का समर्थन करता है।

मूल्य निर्धारण

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

Google की अनुशंसा (2026): नए प्रोजेक्ट के लिए Firestore को डिफ़ॉल्ट डेटाबेस के रूप में उपयोग करें, और Realtime Database को गेम और एप्लिकेशन के लिए जहां न्यूनतम विलंबता (50 ms से कम) और फ्लैट डेटा संरचना महत्वपूर्ण है। दोनों डेटाबेस एक ही प्रोजेक्ट में एक साथ काम कर सकते हैं।

Firestore में क्वेरी, इंडेक्स और पेजिनेशन

Firestore क्वेरी फ़िल्टरिंग, सॉर्टिंग और सीमा के साथ संग्रह या संग्रह समूहों के विरुद्ध निष्पादित की जाती हैं। Realtime Database के विपरीत, जहां प्रत्येक क्वेरी क्लाइंट-साइड फ़िल्टरिंग के साथ पूरे JSON ट्री को ट्रैवर्स करती है, Firestore पूर्व-निर्मित इंडेक्स का उपयोग करके सर्वर पर सभी क्वेरी निष्पादित करता है। यह गारंटी देता है कि क्वेरी जटिलता केवल परिणाम आकार पर निर्भर करती है, संग्रह आकार पर नहीं।

क्वेरी प्रकार

Firestore समर्थन करता है एक या अनेक फ़ील्ड द्वारा फ़िल्टरिंग (समानता, रेंज, in, array-contains, array-contains-any), आरोही और अवरोही सॉर्टिंग, सीमाएँ और पेजिनेशन के लिए कर्सर। सीमाएँ: विभिन्न फ़ील्ड पर फ़िल्टरिंग वाली कंपाउंड क्वेरी (where price > 10 AND where category == “books”) के लिए कंपाउंड इंडेक्स आवश्यक है; OR क्वेरी निषिद्ध हैं (इसके बजाय in और array-contains-any का उपयोग करें), और विभिन्न फ़ील्ड पर असमानता क्वेरी की अनुमति नहीं है।

data class Product(
    val name: String = "",
    val category: String = "",
    val price: Double = 0.0,
    val inStock: Boolean = false
)

suspend fun FirestoreRepository.queryProducts(): List<Product> {
    return firestore
        .collection("products")
        .whereEqualTo("category", "electronics")
        .whereGreaterThanOrEqualTo("price", 100.0)
        .whereLessThan("price", 500.0)
        .orderBy("price")
        .limit(20)
        .get()
        .await()
        .toObjects(Product::class.java)
}

स्वचालित और कंपाउंड इंडेक्स

Firestore स्वचालित रूप से एकल फ़ील्ड के लिए इंडेक्स बनाता है — एकल-फ़ील्ड क्वेरी बिना किसी कॉन्फ़िगरेशन के काम करती हैं। दो या अधिक फ़ील्ड वाली क्वेरी (फ़िल्टरिंग + सॉर्टिंग) के लिए, कंपाउंड इंडेक्स आवश्यक हैं। जब कोई क्वेरी पहली बार भेजी जाती है, तो Firestore कंसोल के लिंक के साथ एक त्रुटि लौटाता है जहाँ एक क्लिक से इंडेक्स बनाया जा सकता है। प्रति डेटाबेस अधिकतम 200 कंपाउंड इंडेक्स। इंडेक्स को Firebase CLI के माध्यम से निर्यात और आयात किया जा सकता है।

Android में Firestore का एकीकरण

Firestore को Android ऐप से कनेक्ट करना Firebase BOM के माध्यम से मानक रूप से किया जाता है। firebase-firestore-ktx निर्भरता जोड़ने के बाद, FirebaseFirestore ऑब्जेक्ट getInstance() के माध्यम से उपलब्ध होता है — बिना अतिरिक्त कुंजी या टोकन के। Firestore अन्य सेवाओं की तरह ही Firebase प्रोजेक्ट का उपयोग करता है।

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-firestore-ktx")
}

// आरंभीकरण
val db = FirebaseFirestore.getInstance()

डेटा पढ़ना और लिखना

Firestore दो रीड मोड प्रदान करता है: एक बार (get) और रीयल-टाइम (addSnapshotListener)। एक बार रीड एक दस्तावेज़ को एक बार पुनर्प्राप्त करता है — सेटिंग्स और कॉन्फ़िगरेशन के लिए उपयोगी। एक लिसनर परिवर्तनों की सदस्यता लेता है — कोई भी दस्तावेज़ अपडेट स्वचालित रूप से सभी कनेक्टेड क्लाइंट को रीयल टाइम में अपडेटेड डेटा वितरित करता है। set() एक दस्तावेज़ बनाता या ओवरराइट करता है, update() पूरे दस्तावेज़ को ओवरराइट किए बिना केवल निर्दिष्ट फ़ील्ड को संशोधित करता है।

Google (2026) के अनुसार, रीयल-टाइम Firestore वाले मध्यम आकार के एप्लिकेशन (100 हजार DAU) प्रति माह लगभग 5-10 GB आउटगोइंग ट्रैफ़िक की खपत करते हैं। ऑफ़लाइन कैश (Persistence Cache) का उपयोग बार-बार डाउनलोड को 60-70% तक कम करता है, क्योंकि SDK कनेक्शन बहाल होने पर केवल बदले गए दस्तावेज़ लोड करता है।

ऑफ़लाइन मोड

Persistence Cache इंटरनेट एक्सेस के बिना काम करने के लिए एक अंतर्निहित Firestore तंत्र है। SDK स्वचालित रूप से सभी पढ़े गए दस्तावेज़ों को डिवाइस पर कैश करता है (Android पर 500 MiB तक)। जब कनेक्शन खो जाता है, तो रीड कैश से जारी रहती है, और राइट कतारबद्ध हो जाती हैं। जब कनेक्शन बहाल होता है, तो सभी लंबित ऑपरेशन सर्वर को भेजे जाते हैं, और कैश सर्वर के साथ सिंक्रोनाइज़ होता है। विरोध नियंत्रण के लिए, snapshot-metadata.hasPendingWrites और setOptions(ServerTimestampBehavior) का उपयोग करें।

सुरक्षा नियम और डेटा सत्यापन

Security Rules Firestore के लिए एक घोषणात्मक एक्सेस कंट्रोल भाषा है जो प्रत्येक रीड या राइट ऑपरेशन से पहले Google के सर्वर पर निष्पादित होती है। Rules को सर्वर-साइड कोड की आवश्यकता नहीं है — वे Firebase कंसोल या Firebase CLI के माध्यम से लिखे जाते हैं और Git के माध्यम से संस्करणित किए जाते हैं। प्रत्येक ऑपरेशन Rules के विरुद्ध जाँचा जाता है, और उल्लंघन पर PERMISSION_DENIED त्रुटि लौटाई जाती है।

Rules संरचना

Firestore Security Rules में match ब्लॉक और allow एक्सप्रेशन होते हैं। match किसी संग्रह या दस्तावेज़ के पथ को परिभाषित करता है, allow अनुमत ऑपरेशन (read, write, create, update, delete) और एक शर्त — boolean लौटाने वाला JavaScript-जैसा एक्सप्रेशन निर्दिष्ट करता है। Rules प्रमाणीकरण (request.auth), अनुरोध डेटा (request.resource.data), मौजूदा डेटा (resource.data), समय (request.time) और पथ (request.path) की जाँच कर सकते हैं।

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if request.auth != null;
      allow write: if request.auth.uid == userId;
    }

    match /products/{productId} {
      allow read: if true;
      allow create: if request.auth.token.role == "admin";
      allow update: if resource.data.authorId == request.auth.uid;
    }
  }
}

डेटा सत्यापन

Security Rules सर्वर साइड पर प्रकार और मान सत्यापन का समर्थन करती हैं। यदि मूल्य नकारात्मक है या नाम खाली है तो आप लेखन को प्रतिबंधित कर सकते हैं। सभी जाँचें Google के सर्वर पर लेखन से पहले की जाती हैं — यह क्लाइंट (Android, iOS, Web, Admin SDK) की परवाह किए बिना डेटा संगति की गारंटी देता है। Rules दुर्भावनापूर्ण Admin SDK से रक्षा नहीं करती — यह डिज़ाइन द्वारा Rules को बायपास करता है। पूर्ण सुरक्षा के लिए, Transaction Functions और Firebase Extensions का उपयोग करें।