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-এর তুলনায় significantly সস্তা করে। তৃতীয় পরিস্থিতি — ব্যবহারকারীর অনলাইন/অফলাইন উপস্থিতি, যেখানে 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% ডেটা লিক অনুচিতভাবে কনফিগার করা নিরাপত্তা নিয়মের কারণে ঘটে।