Firebase Realtime DB — यह क्या है, आर्किटेक्चर और JSON के साथ काम करना

Firebase Realtime Database क्या है?

Firebase Realtime Database एक क्लाउड NoSQL डेटाबेस है जो सभी कनेक्टेड क्लाइंट के बीच रीयल-टाइम में डेटा संग्रहीत और सिंक्रनाइज़ करता है। 2012 में Firebase के रूप में लॉन्च किया गया (Google द्वारा अधिग्रहण से पहले), यह मोबाइल डेवलपर्स के लिए पहला क्लाउड रीयल-टाइम डेटाबेस बन गया। डेटा JSON प्रारूप में प्रस्तुत किया जाता है और एक पदानुक्रमित ट्री में व्यवस्थित होता है, जहाँ प्रत्येक नोड का एक अद्वितीय पथ होता है।

Realtime Database का मुख्य मूल्य अंतर्निहित सिंक्रनाइज़ेशन है। जब कोई एप्लिकेशन किसी डिवाइस पर डेटा बदलता है, तो अन्य सभी कनेक्टेड क्लाइंट को स्थायी कनेक्शन के माध्यम से तुरंत अपडेट प्राप्त होता है। यह डेवलपर को क्लाइंट के बीच डेटा स्थानांतरण के लिए अपना स्वयं का सिंक्रनाइज़ेशन तंत्र, WebSocket सर्वर या REST API लागू करने की आवश्यकता को समाप्त करता है।

डेटाबेस सभी प्रमुख प्लेटफ़ॉर्म के लिए SDK प्रदान करता है: Android (Java, Kotlin), iOS (Swift, Objective-C), Web (JavaScript), और Admin SDK के माध्यम से सर्वर वातावरण। Google के अनुसार, Realtime Database दुनिया भर में 1.5 मिलियन से अधिक सक्रिय Firebase प्रोजेक्ट में उपयोग किया जाता है। अधिक आधुनिक Firestore के आगमन के बावजूद, Realtime Database सरल डेटा संरचना वाले प्रोजेक्ट के लिए एक लोकप्रिय विकल्प बना हुआ है।

डेटा संरचना: JSON ट्री

रिलेशनल डेटाबेस के विपरीत, Realtime Database तालिकाओं और पंक्तियों का उपयोग नहीं करता है। सभी डेटा एक एकल JSON ट्री है जो नेस्टेड JavaScript ऑब्जेक्ट जैसा दिखता है। उदाहरण के लिए, उपयोगकर्ताओं और उनके संदेशों को संग्रहीत करने के लिए एक पदानुक्रम बनाया जाता है: users/userId/name और messages/messageId/text। ट्री में प्रत्येक पथ एक स्ट्रिंग है, और इस पथ द्वारा सीधे डेटा तक पहुँचा जा सकता है।

{
  "users": {
    "user1": {
      "name": "इवान पेट्रोव",
      "email": "ivan@example.com"
    },
    "user2": {
      "name": "मारिया सोकोलोवा",
      "email": "maria@example.com"
    }
  },
  "messages": {
    "-Nabc123": {
      "text": "नमस्ते!",
      "userId": "user1"
    }
  }
}

एक महत्वपूर्ण विशेषता — गहरी नेस्टिंग प्रदर्शन को प्रभावित करती है। जब एप्लिकेशन किसी निश्चित पथ पर डेटा पढ़ता है, तो वह उस पथ के सभी चाइल्ड नोड लोड करता है। इसलिए, डेटा संरचना को यथासंभव सपाट डिज़ाइन करने की अनुशंसा की जाती है, 3-4 स्तरों से अधिक गहरी नेस्टिंग से बचें। इस समस्या से निपटने के लिए, डेटा डीनॉर्मलाइज़ेशन का उपयोग किया जाता है — विभिन्न ट्री नोड में जानकारी की नकल करना।

Realtime Database vs Firestore: कब चुनें

Realtime Database और Firestore की तुलना अक्सर Google के दो क्लाउड रीयल-टाइम डेटाबेस के रूप में की जाती है। उनके बीच चुनाव प्रोजेक्ट की विशिष्ट आवश्यकताओं पर निर्भर करता है: क्वेरी जटिलता, आवश्यक स्थिरता, और अपेक्षित लोड। प्रत्येक डेटाबेस की ताकत को समझना सही आर्किटेक्चरल निर्णय लेने में मदद करता है।

Realtime Database का मुख्य लाभ कम सिंक लेटेंसी है। चूँकि सभी डेटा बिना किसी अतिरिक्त एब्स्ट्रक्शन लेयर के एक JSON ट्री में संग्रहीत होता है, सिंक्रनाइज़ेशन Firestore की तुलना में तेज़ होता है। उन एप्लिकेशन के लिए जहाँ अपडेट डिलीवरी की गति महत्वपूर्ण है (चैट, ऑनलाइन गेम, सहयोगी संपादन सिस्टम), Realtime Database अधिक उपयुक्त विकल्प हो सकता है।

Realtime Database का उपयोग कब करें

Realtime Database सरल डेटा संरचना और उच्च अपडेट आवृत्ति वाले परिदृश्यों के लिए बेहतर उपयुक्त है। विशिष्ट उदाहरण: चैट, रीयल-टाइम लाइक, टाइपिंग इंडिकेटर, उपयोगकर्ता उपस्थिति स्थिति। यह प्रोटोटाइप और सीमित बजट वाले प्रोजेक्ट के लिए भी एक अच्छा विकल्प है, क्योंकि मूल्य निर्धारण संचालन की संख्या के बजाय डेटा वॉल्यूम पर आधारित होता है।

दूसरी ओर, जटिल क्वेरी (कई फ़ील्ड द्वारा फ़िल्टरिंग, सॉर्टिंग, एग्रीगेशन) वाले एप्लिकेशन के लिए, Firestore अधिक शक्तिशाली क्षमताएँ प्रदान करता है। Realtime Database केवल एक पैरामीटर द्वारा फ़िल्टरिंग का समर्थन करता है और एक साथ कई फ़ील्ड द्वारा परिणामों को सॉर्ट नहीं कर सकता है। यदि कोई प्रोजेक्ट क्लाइंट-साइड पर जटिल डेटा एनालिटिक्स की योजना बनाता है, तो Firestore अधिक व्यावहारिक विकल्प होगा।

Realtime Database में सिंक्रनाइज़ेशन कैसे काम करता है

Realtime Database द्विदिश डेटा सिंक्रनाइज़ेशन के लिए स्थायी WebSocket कनेक्शन का उपयोग करता है। जब कोई क्लाइंट किसी विशिष्ट पथ पर setValue या updateChildren को कॉल करता है, तो डेटा खुले चैनल के माध्यम से Firebase सर्वर पर भेजा जाता है। सर्वर परिवर्तनों को लागू करता है और मिलीसेकंड के भीतर सभी सब्सक्राइब्ड क्लाइंट को अपडेट वितरित करता है। प्रत्येक कनेक्शन एक अद्वितीय सत्र कुंजी द्वारा पहचाना जाता है।

सब्सक्रिप्शन तंत्र listeners के माध्यम से काम करता है। डेवलपर किसी विशिष्ट नोड पर परिवर्तनों की सदस्यता ले सकता है (addListenerForSingleValueEvent) या निरंतर अपडेट प्राप्त कर सकता है (addValueEventListener)। हर बार जब डेटा बदलता है, तो निर्दिष्ट पथ पर पूर्ण डेटा स्नैपशॉट के साथ onDataChange callback ट्रिगर होता है। यह Firestore से भिन्न है, जहाँ केवल बदले गए दस्तावेज़ प्राप्त होते हैं — Realtime Database में हमेशा नोड का सारा डेटा लोड होता है।

ऑफ़लाइन मोड और संघर्ष प्रबंधन

Realtime Database डिस्क कैशिंग के माध्यम से Android और iOS पर ऑफ़लाइन मोड का समर्थन करता है। SDK डेटा की स्थानीय प्रतिलिपि रखता है और नेटवर्क न होने पर लेखन संचालन को संसाधित करना जारी रखता है। जब कनेक्शन बहाल होता है, तो सभी संचित परिवर्तन सर्वर पर भेजे जाते हैं। संघर्ष समाधान के लिए लास्ट-राइट-विन्स रणनीति का उपयोग किया जाता है, लेकिन डेवलपर टकराव समाधान के लिए ServerValue.TIMESTAMP के माध्यम से कस्टम लॉजिक लागू कर सकता है।

val database = FirebaseDatabase.getInstance()
val myRef = database.getReference("messages")

// डेटा लिखना
myRef.push().setValue(
    hashMapOf(
        "text" to "नया संदेश",
        "timestamp" to ServerValue.TIMESTAMP
    )
)

// निरंतर अपडेट के साथ पढ़ना
myRef.addValueEventListener(object : ValueEventListener {
    override fun onDataChange(snapshot: DataSnapshot) {
        val data = snapshot.getValue()
        Log.d("TAG", "डेटा: $data")
    }

    override fun onCancelled(error: DatabaseError) {
        Log.w("TAG", "त्रुटि: ${error.message}")
    }
})

ट्रैफ़िक और प्रदर्शन को अनुकूलित करने के लिए, विशिष्ट चाइल्ड नोड में परिवर्तनों को ट्रैक करते समय value listeners के बजाय child listeners का उपयोग करने की अनुशंसा की जाती है। ChildEventListener चाइल्ड एलिमेंट को जोड़ने, संशोधित करने, हटाने और स्थानांतरित करने के लिए अलग-अलग callback प्रदान करता है, जो UI अपडेट के अधिक सटीक नियंत्रण की अनुमति देता है और प्रत्येक डेटा परिवर्तन पर सभी सूची आइटम को फिर से रेंडर करने से बचाता है।

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

Realtime Database डेटा एक्सेस नियंत्रण के लिए घोषणात्मक नियम भाषा का उपयोग करता है। नियम बताते हैं कि JSON ट्री के प्रत्येक पथ पर कौन डेटा पढ़ और लिख सकता है। प्रत्येक अनुरोध से पहले Firebase सर्वर पर उनकी जाँच की जाती है और प्राधिकरण के लिए सर्वर-साइड लॉजिक की आवश्यकता नहीं होती है। नियम लचीली एक्सेस कॉन्फ़िगरेशन के लिए चर, अंतर्निहित ऑब्जेक्ट और फ़ंक्शन का समर्थन करते हैं।

डिफ़ॉल्ट रूप से, सभी उपयोगकर्ताओं के लिए डेटाबेस एक्सेस अस्वीकृत है। डेवलपर ट्री के विभिन्न स्तरों पर ".read" और ".write" नियमों का उपयोग करके धीरे-धीरे एक्सेस खोलता है। शर्तें auth चर के माध्यम से प्रमाणीकरण, अनुरोध प्रकार (पढ़ना/लिखना), और data ऑब्जेक्ट के माध्यम से मौजूदा डेटा की जाँच कर सकती हैं। इसके अतिरिक्त, नियम newData ऑब्जेक्ट के माध्यम से लिखे गए डेटा के मान्यकरण का समर्थन करते हैं।

{
  "rules": {
    "users": {
      "$uid": {
        // केवल स्वामी अपना डेटा पढ़ सकता है
        ".read": "$uid === auth.uid",
        // केवल स्वामी लिख सकता है
        ".write": "$uid === auth.uid",
        // लिखते समय क्षेत्रों का मान्यकरण
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      // कोई भी प्रमाणित उपयोगकर्ता पढ़ सकता है
      ".read": "auth !== null",
      // केवल प्रमाणित उपयोगकर्ता लिख सकता है
      ".write": "auth !== null",
      ".indexOn": ["timestamp"]
    }
  }
}

नियम ".indexOn" निर्देश के माध्यम से डेटा इंडेक्सिंग का भी समर्थन करते हैं। इसके बिना, सॉर्टिंग (orderByChild) वाली क्वेरी को अस्वीकार कर दिया जाएगा या अकुशल रूप से निष्पादित किया जाएगा। इंडेक्स प्रत्येक पथ के लिए निर्दिष्ट किए जाते हैं जहाँ किसी विशिष्ट फ़ील्ड द्वारा सॉर्टिंग की जाती है। नियम कैस्केडिंग होते हैं: गहरे नियम मूल नियमों को ओवरराइड करते हैं, और यदि किसी स्तर पर एक्सेस परिभाषित नहीं है, तो इसे मूल नियम के आधार पर अनुमत या अस्वीकृत माना जाता है।

डेटा प्रकार और सीमाएँ

Realtime Database पाँच डेटा प्रकार का समर्थन करता है: String, Number, Boolean, Map (ऑब्जेक्ट), और List (ऐरे)। नेस्टिंग गहराई 32 स्तरों तक सीमित है, और एकल नोड का अधिकतम आकार 256 MB से अधिक नहीं होना चाहिए। कुशल डेटाबेस कार्य के लिए, सपाट डेटा संरचना डिज़ाइन करने और बड़ी मात्रा में डेटा लोड करने वाली गहरी क्वेरी से बचने के लिए डीनॉर्मलाइज़ेशन का उपयोग करने की अनुशंसा की जाती है।

Android में Realtime Database उपयोग का उदाहरण

आइए उपयोगकर्ता स्थिति (ऑनलाइन/ऑफ़लाइन) के लिए Android एप्लिकेशन में Realtime Database को एकीकृत करने का एक व्यावहारिक उदाहरण देखें। एप्लिकेशन उपयोगकर्ताओं की उनकी वर्तमान स्थिति के साथ एक सूची प्रदर्शित करेगा, जो रीयल-टाइम में अपडेट होती है। प्रदर्शन के लिए उपयोगकर्ता पहचान के लिए Firebase Authentication और एसिंक्रोनस संचालन के लिए कोरूटीन का उपयोग किया जाता है।

निर्भरताएँ सेट करना और आरंभीकरण

आरंभ करने के लिए, ऐप मॉड्यूल build.gradle फ़ाइल में firebase-database-ktx निर्भरता जोड़ें। सभी घटकों की संगतता सुनिश्चित करने के लिए लाइब्रेरी संस्करण Firebase BoM के माध्यम से प्रबंधित किया जाता है। निर्भरता जोड़ने के बाद, Firebase को Application क्लास में या ViewModel में लेज़ी आरंभीकरण के माध्यम से आरंभ किया जाना चाहिए।

dependencies {
    implementation platform("com.google.firebase:firebase-bom:33.0.0")
    implementation "com.google.firebase:firebase-database-ktx"
    implementation "com.google.firebase:firebase-auth-ktx"
}

कॉन्फ़िगरेशन के बाद, उपयोगकर्ताओं के साथ काम करने के लिए एक रिपॉजिटरी बनाई जाती है। प्रत्येक उपयोगकर्ता name, email और status फ़ील्ड के साथ /users/{uid} ट्री में एक नोड द्वारा दर्शाया जाता है। स्थिति ट्रैकिंग के लिए onDisconnect का उपयोग किया जाता है — एक विशेष Firebase तंत्र जो क्लाइंट कनेक्शन बाधित होने पर स्वचालित रूप से लेखन संचालन निष्पादित करता है। यह सुनिश्चित करता है कि क्लाइंट पर अतिरिक्त कोड के बिना ऐप बंद होने या नेटवर्क खोने पर उपयोगकर्ता की स्थिति "offline" में बदल जाती है।

class PresenceRepository {
    private val database = FirebaseDatabase.getInstance()
    private val auth = FirebaseAuth.getInstance()
    private val presenceRef = database
        .getReference("presence")

    fun trackPresence() {
        val uid = auth.currentUser?.uid ?: return
        val userRef = presenceRef.child(uid)

        userRef.onDisconnect().setValue("offline")
        userRef.setValue("online")
    }

    fun getPresenceStream(): Flow<Map<String, String>> =
        presenceRef.snapshotFlow()
            .map { snapshot ->
                (snapshot.value as? Map<*, *>)
                    ?.mapKeys { it.key.toString() }
                    ?.mapValues { it.value.toString() }
                    ?: emptyMap()
            }
}

उदाहरण का मुख्य तत्व onDisconnect है। यह तंत्र एक लेखन संचालन सेट करने की अनुमति देता है जो क्लाइंट कनेक्शन बाधित होने पर सर्वर पर निष्पादित किया जाएगा। इस मामले में, जब उपयोगकर्ता डिस्कनेक्ट होता है, तो एप्लिकेशन बंद होने की घटना को संभालने की आवश्यकता के बिना उनकी स्थिति स्वचालित रूप से "offline" पर सेट हो जाती है। यदि ऐप क्रैश होता है, तो Firebase स्वयं onDisconnect संचालन निष्पादित करेगा, और अन्य उपयोगकर्ता सही स्थिति देखेंगे।