Firebase Realtime Database: यह क्या है, JSON संरचना और सिंक्रोनाइज़ेशन

Firebase Realtime Database क्या है

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

इतिहास और विकास

मूल Firebase की स्थापना 2011 में James Tamplin और Andrew Lee ने की थी, और पहला उत्पाद स्वयं Realtime Database था। 2014 में Google द्वारा अधिग्रहण के बाद (TechCrunch के अनुसार — 50 से 100 मिलियन डॉलर के बीच की राशि में), डेटाबेस को Google Cloud में एकीकृत किया गया और काफी अधिक थ्रूपुट प्राप्त हुआ। 2017 में, Google ने Firestore को एक विकासवादी प्रतिस्थापन के रूप में घोषित किया, लेकिन Realtime Database अभी भी सक्रिय रूप से समर्थित और अपडेट की जाती है। Google (2026) के अनुसार, Realtime Database अभी भी 1.5 मिलियन से अधिक सक्रिय परियोजनाओं में उपयोग की जाती है।

मुफ़्त सीमाएँ और मूल्य निर्धारण

Spark योजना (मुफ़्त) में शामिल है: 1 GB स्टोरेज, प्रति माह 10 GB डाउनलोड किया गया डेटा, 100 एक साथ कनेक्शन और एक क्षेत्र में डेटाबेस समर्थन। Blaze योजना (pay-as-you-go) पर, अतिरिक्त स्टोरेज ($1/GB), ट्रैफ़िक ($0.12/GB) और एक साथ कनेक्शन (सीमा से ऊपर प्रति 100 हज़ार पर $5) के लिए शुल्क लिया जाता है। परीक्षण के लिए, एक इम्यूलेशन मोड भी उपलब्ध है — firebase emulators:start — जो क्लाउड से कनेक्ट हुए बिना Realtime Database को स्थानीय रूप से चलाता है।

डेटा संरचना: JSON ट्री और नॉर्मलाइज़ेशन

Realtime Database में कोई तालिकाएँ, संग्रह या दस्तावेज़ नहीं हैं — सब कुछ एक एकल JSON ट्री है जो https://project-name-default-rtdb.firebaseio.com/ जैसे URL के माध्यम से सुलभ है। ट्री की प्रत्येक कुंजी या तो एक अंतिम मान (स्ट्रिंग, संख्या, बूलियन, null) है या चाइल्ड कुंजियों वाला एक नेस्टेड नोड है। डेटाबेस इंजन JOIN, उप-क्वेरी या एकत्रीकरण का समर्थन नहीं करता — एक क्वेरी हमेशा सभी चाइल्ड तत्वों के साथ एक नोड की सामग्री लौटाती है।

डेटा नॉर्मलाइज़ेशन

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

Realtime Database में क्वेरीज़

क्वेरीज़ Realtime Database में फ़िल्टर (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt) का उपयोग करके निष्पादित की जाती हैं। Firestore के विपरीत, इंडेक्स Rules अनुभाग (.indexOn) के माध्यम से मैन्युअल रूप से बनाए जाते हैं। यदि इंडेक्स घोषित नहीं किया गया है, तो सॉर्टिंग वाली क्वेरी PERMISSION_DENIED त्रुटि लौटाती है। क्वेरीज़ केवल एक फ़ील्ड पर काम करती हैं — कंपाउंड क्वेरीज़ (मूल्य के अनुसार फ़िल्टर + तिथि के अनुसार सॉर्ट) समर्थित नहीं हैं। जटिल फ़िल्टरिंग के लिए, डेटा को अक्सर विभिन्न सॉर्टिंग कुंजियों के साथ विभिन्न नोड्स में डुप्लिकेट किया जाता है।

Realtime Database बनाम Firestore: क्या चुनें

Realtime Database और Firestore के बीच चयन परियोजना शुरू करते समय सामान्य वास्तुशिल्प निर्णयों में से एक है। Google अधिकांश नए एप्लिकेशन के लिए Firestore की सिफारिश करता है, लेकिन Realtime Database उन परिदृश्यों के लिए सबसे अच्छा विकल्प बनी हुई है जहाँ न्यूनतम डेटा ट्रांसफर विलंबता महत्वपूर्ण है।

Realtime Database के लिए तीन मुख्य परिदृश्य

पहला परिदृश्य — स्थिति सिंक्रोनाइज़ेशन वाले मल्टीप्लेयर गेम (शतरंज, ताश के खेल, रियल-टाइम एक्शन)। Realtime Database की विलंबता 10-30 ms है जबकि उसी क्षेत्र में Firestore की 50-100 ms है। दूसरा परिदृश्य — उच्च संदेश आवृत्ति वाले चैट और मैसेंजर। Realtime Database का मूल्य डेटा वॉल्यूम के अनुसार निर्धारित होता है, न कि लेखन की संख्या के अनुसार, जो इसे प्रति सेकंड 1 संदेश से अधिक आवृत्ति पर Firestore की तुलना में काफी सस्ता बनाता है। तीसरा परिदृश्य — उपयोगकर्ताओं की ऑनलाइन/ऑफ़लाइन उपस्थिति, जहाँ Realtime Database के onDisconnect हैंडलर कनेक्शन खोने पर स्थिति को परमाणु रूप से सेट करने की अनुमति देते हैं।

Google (2026) के अनुसार, लगभग 15% नई Firebase परियोजनाएँ सचेत रूप से Realtime Database चुनती हैं — जब टीम विलंबता, डेटा संरचना और बजट के लिए अपनी आवश्यकताओं को स्पष्ट रूप से समझती है। शेष 85% मामलों में, Firestore बेहतर स्केलेबिलिटी, अधिक शक्तिशाली क्वेरीज़ और स्वचालित प्रतिकृति के कारण सुरक्षित विकल्प है।

Android में Realtime Database का एकीकरण

Realtime Database को Android एप्लिकेशन से जोड़ना build.gradle में firebase-database-ktx निर्भरता जोड़कर किया जाता है। FirebaseDatabase ऑब्जेक्ट getInstance(url) के माध्यम से उपलब्ध है — आप एक Firebase परियोजना के अंतर्गत कई डेटाबेस से कनेक्ट कर सकते हैं। आरंभीकरण के बाद, SDK स्वचालित रूप से सर्वर के साथ WebSocket कनेक्शन स्थापित करता है और डेटा सिंक्रोनाइज़ेशन शुरू करता है।

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

// Initialization with custom URL
val database = FirebaseDatabase.getInstance(
    "https://my-project-default-rtdb.firebaseio.com/"
)
val ref = database.getReference("chats")

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

Realtime Database सभी संचालन के लिए DatabaseReference ऑब्जेक्ट का उपयोग करती है। setValue() निर्दिष्ट नोड में डेटा लिखता है, इसकी सभी सामग्री को पूरी तरह से बदल देता है। push() सूची में आइटम जोड़ने के लिए स्वचालित रूप से एक अद्वितीय कुंजी (टाइमस्टैम्प के आधार पर) उत्पन्न करता है — यह चैट संदेश, पोस्ट और रिकॉर्ड बनाने का मानक तरीका है। updateChildren() एक ही संचालन में कई नोड्स को परमाणु रूप से संशोधित करता है। addValueEventListener नोड में बदलावों की सदस्यता लेता है और प्रत्येक डेटा अपडेट पर कॉलबैक प्राप्त करता है।

data class Message(
    val author: String = "",
    val text: String = "",
    val timestamp: Long = ServerValue.TIMESTAMP
)

class ChatRepository(private val ref: DatabaseReference) {
    fun sendMessage(author: String, text: String) {
        val msg = Message(author = author, text = text)
        ref.child("messages").push().setValue(msg)
    }

    fun observeMessages(): Flow<List<Message>> = callbackFlow {
        val listener = ref.child("messages")
            .addValueEventListener(object : ValueEventListener {
                override fun onDataChange(snapshot: DataSnapshot) {
                    val messages = snapshot.children.mapNotNull { it.getValue(Message::class.java) }
                    trySend(messages)
                }
                override fun onCancelled(error: DatabaseError) {}
            })
        awaitClose { ref.removeEventListener(listener) }
    }
}

रियल-टाइम सिंक्रोनाइज़ेशन और ऑफ़लाइन मोड

सिंक्रोनाइज़ेशन तंत्र Realtime Database का WebSocket प्रोटोकॉल (पहले — long-polling) पर आधारित है। क्लाइंट किसी विशिष्ट नोड की सदस्यता लेने का अनुरोध भेजता है, और सर्वर कनेक्शन को खुला रखता है। सब्सक्राइब्ड नोड में किसी भी डेटा बदलाव पर, सर्वर उस नोड का पूरा JSON क्लाइंट को भेजता है। क्लाइंट पर SDK स्वचालित रूप से स्थानीय स्थिति को अपडेट करता है और संबंधित कॉलबैक (onDataChange) को ट्रिगर करता है।

OnDisconnect — डिस्कनेक्शन ट्रिगर

OnDisconnect Realtime Database की एक अनूठी विशेषता है जो Firestore में अनुपस्थित है। डेवलपर एक लेखन संचालन पंजीकृत कर सकता है जो क्लाइंट का कनेक्शन टूटने पर सर्वर पर स्वचालित रूप से निष्पादित होगा। इसका उपयोग उपस्थिति स्थितियों के लिए किया जाता है: "user123/status": "online" with onDisconnect.setValue("offline"). यदि उपयोगकर्ता ऐप बंद करता है या इंटरनेट खो देता है, तो सर्वर स्वचालित रूप से 3 मिनट से अधिक समय में स्थिति को "offline" पर सेट कर देगा (Firebase कंसोल में कॉन्फ़िगरेबल)।

ऑफ़लाइन कैश

Persistence Realtime Database में एक पंक्ति से सक्षम होता है: FirebaseDatabase.getInstance().setPersistenceEnabled(true). SDK डिस्क पर सभी सब्सक्राइब्ड नोड्स की अंतिम स्थिति को कैश करता है (डिफ़ॉल्ट रूप से 10 MiB तक, 100 MiB तक कॉन्फ़िगरेबल)। कनेक्शन खोने पर, क्लाइंट कैश किए गए डेटा के साथ काम करना जारी रखता है, और सभी लेखन संचालन कतारबद्ध हो जाते हैं। कनेक्शन बहाल होने पर, SDK सभी संचित बदलावों को सही क्रम (FIFO) में सर्वर को भेजता है।

Google (2026) के अनुसार, persistence कैश सक्षम वाले एप्लिकेशन में कनेक्शन खोने पर उपयोगकर्ता डेटा खोने की संभावना 40% कम होती है। हालाँकि, यदि किसी क्लाइंट ने 1000 से अधिक लंबित संचालन जमा कर लिए हैं, तो सर्वर उन सभी को अस्वीकार कर सकता है और पूर्ण सिंक्रोनाइज़ेशन का अनुरोध कर सकता है — यह पुराने क्लाइंट के खिलाफ एक सुरक्षात्मक तंत्र है।

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

सुरक्षा नियम Realtime Database में एक JSON कॉन्फ़िगरेशन है जो बताता है कि प्रत्येक नोड में डेटा कौन और किन शर्तों के तहत पढ़ और लिख सकता है। नियम Google के सर्वर पर चलते हैं और प्रत्येक संचालन से पहले लागू किए जाते हैं। डिफ़ॉल्ट रूप से (उत्पादन में), नियमों को "बंद" मोड पर सेट करने की अनुशंसा की जाती है — केवल प्रमाणित उपयोगकर्ताओं की पहुँच होती है।

नियमों की संरचना

Realtime Database के नियम .read, .write, .validate, .indexOn अनुभागों के साथ JSON प्रारूप में लिखे जाते हैं। Firestore (जो match सिंटैक्स का उपयोग करता है) के विपरीत, Realtime Database नेस्टेड ऑब्जेक्ट का उपयोग करता है जो डेटा संरचना को दर्शाते हैं। शर्तें auth (प्रमाणीकरण), data (मौजूदा डेटा), newData (लेखन पर नया डेटा) और now (सर्वर समय) की जाँच करती हैं। मान्यकरण नियम (.validate) प्रकार, मान सीमाएँ और डेटा संरचना की जाँच करने की अनुमति देते हैं।

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid",
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      ".indexOn": ["timestamp"],
      "$msgId": {
        ".read": true,
        ".write": "auth.uid !== null",
        ".validate": "newData.child('text').isString() && newData.child('text').val().length <= 500"
      }
    }
  }
}

कैस्केड व्यवहार और नियमों का परीक्षण

Realtime Database के नियम कैस्केडिंग रूप से विरासत में मिलते हैं — यदि शीर्ष स्तर पर .read = false है, तो सभी चाइल्ड नोड अपने स्वयं के नियमों की परवाह किए बिना पढ़ने के लिए अनुपलब्ध हैं। Firebase कंसोल में एक नियम सिम्युलेटर प्रदान करता है जहाँ आप डिप्लॉयमेंट से पहले विभिन्न auth टोकन के साथ संचालन का परीक्षण कर सकते हैं। हमेशा सिम्युलेटर में नियमों का परीक्षण करने की अनुशंसा की जाती है — एक नियम में त्रुटि सभी उपयोगकर्ताओं के निजी डेटा तक पहुँच खोल सकती है। Google (2026) के अनुसार, Firebase परियोजनाओं में 40% डेटा लीक अनुचित रूप से कॉन्फ़िगर किए गए सुरक्षा नियमों के कारण होते हैं।