Firebase Realtime Database: ano ito, JSON structure at pag-sync

Ano ang Firebase Realtime Database

Firebase Realtime Database ay isa sa mga unang cloud real-time database na inilunsad ng Google kasama ng Firebase noong 2012. Ito ay isang NoSQL database kung saan ang data ay iniimbak bilang isang JSON tree na naa-access sa pamamagitan ng isang URL. Ang client SDKs (Android, iOS, Web) ay nag-subscribe sa mga partikular na node ng tree sa pamamagitan ng WebSocket at tumatanggap ng mga update sa bawat pagbabago ng data — nang hindi pine-ping ang server at nang hindi nag-i-implement ng sariling Push mechanism.

Kasaysayan at pag-unlad

Ang orihinal na Firebase ay itinatag noong 2011 nina James Tamplin at Andrew Lee, at ang unang produkto ay ang Realtime Database. Matapos makuha ng Google noong 2014 (ayon sa TechCrunch — para sa halagang 50 hanggang 100 milyong dolyar), ang database ay isinama sa Google Cloud at nakakuha ng mas mataas na bandwidth. Noong 2017, inanunsyo ng Google ang Firestore bilang evolutionary replacement, ngunit ang Realtime Database ay patuloy na aktibong sinusuportahan at ina-update. Ayon sa datos ng Google (2026), ang Realtime Database ay ginagamit pa rin sa mahigit 1.5 milyong aktibong proyekto.

Mga libreng limit at taripa

Spark plan (libre) ay may kasamang: 1 GB storage, 10 GB na na-download na data bawat buwan, 100 sabay-sabay na koneksyon at suporta sa database sa isang rehiyon. Sa Blaze plan (pay-as-you-go), may bayad para sa dagdag na storage ($1/GB), traffic ($0.12/GB) at sabay-sabay na koneksyon ($5 para sa bawat 100 libo na lampas sa limit). Para sa pag-test, mayroon ding emulation mode — firebase emulators:start — na nagpapatakbo ng Realtime Database nang lokal nang walang koneksyon sa cloud.

Structure ng data: JSON tree at normalization

Realtime Database ay walang tables, collections o documents — lahat ay isang JSON tree na naa-access sa URL na https://project-name-default-rtdb.firebaseio.com/. Ang bawat key ng tree ay alinman sa isang end value (string, numero, boolean, null) o isang nested node na may mga child key. Ang database engine ay hindi sumusuporta ng JOIN, subquery o aggregations — ang isang query ay palaging nagbabalik ng nilalaman ng isang node kasama ang lahat ng child elements nito.

Normalization ng data

Dahil sa kawalan ng JOIN sa Realtime Database, ang normalization ng data ay mandatory. Sa halip na nested tree (user → listahan ng kanyang mga post), ang data ay hinahati sa flat lists na may mga reference sa pamamagitan ng keys. Ito ang standard approach: ang data ay dini-denormalize upang ang pagbasa ng isang node ay hindi humila ng buong konteksto. Halimbawa, ang listahan ng mga chat message ay iniimbak nang hiwalay sa mga user profile, at ang bawat post ay naglalaman lamang ng ID ng author, hindi ang buong profile nito.

Mga query sa Realtime Database

Mga query sa Realtime Database ay isinasagawa gamit ang filter (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt). Hindi tulad ng Firestore, ang mga index ay ginagawa nang manu-mano sa pamamagitan ng Rules section (.indexOn). Kung ang index ay hindi na-declare, ang query na may sorting ay nagbabalik ng error na PERMISSION_DENIED. Ang mga query ay gumagana lamang sa isang field — ang compound queries (filter ayon sa presyo + sorting ayon sa petsa) ay hindi suportado. Para sa kumplikadong filtering, ang data ay madalas na dina-duplicate sa iba't ibang node na may iba't ibang sorting keys.

Realtime Database vs Firestore: ano ang pipiliin

Ang pagpili sa pagitan ng Realtime Database at Firestore ay isa sa mga madalas na desisyon sa arkitektura kapag nagsisimula ng proyekto. Inirerekomenda ng Google ang Firestore para sa karamihan ng mga bagong application, ngunit ang Realtime Database ay nananatiling pinakamahusay na pagpipilian para sa mga senaryo kung saan ang minimal na latency ng paglilipat ng data ay kritikal.

Tatlong pangunahing senaryo para sa Realtime Database

Unang senaryo — mga multiplayer na laro na may state synchronization (chess, card games, real-time action). Ang latency ng Realtime Database ay 10-30 ms kumpara sa 50-100 ms para sa Firestore sa parehong rehiyon. Pangalawang senaryo — mga chat at messenger na may mataas na frequency ng mensahe. Ang Realtime Database ay sine-singil ayon sa volume ng data, hindi sa bilang ng mga pagsulat, na ginagawang mas mura kaysa sa Firestore sa frequency na higit sa 1 mensahe bawat segundo. Pangatlong senaryo — presensya (presence) ng mga user online/offline, kung saan ang onDisconnect handlers ng Realtime Database ay nagpapahintulot ng atomic na pag-set ng status kapag naputol ang koneksyon.

Ayon sa datos ng Google (2026), humigit-kumulang 15% ng mga bagong Firebase project ang sinasadyang pumili ng Realtime Database — kapag malinaw na nauunawaan ng team ang mga kinakailangan sa latency, structure ng data at budget. Sa natitirang 85% ng mga kaso, ang Firestore ay ang mas ligtas na pagpipilian dahil sa mas mahusay na scalability, mas malakas na query at automatic replication.

Integrasyon ng Realtime Database sa Android

Pagkonekta ng Realtime Database sa Android app ay ginagawa sa pamamagitan ng pagdagdag ng dependency na firebase-database-ktx sa build.gradle. Ang FirebaseDatabase object ay available sa pamamagitan ng getInstance(url) — maaaring kumonekta sa maraming database sa loob ng isang Firebase project. Pagkatapos ng initialization, awtomatikong nagtatatag ang SDK ng WebSocket connection sa server at nagsisimula ng data synchronization.

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

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

Pagsulat at pagbasa ng data

Realtime Database ay gumagamit ng DatabaseReference object para sa lahat ng operasyon. Ang setValue() ay nagsusulat ng data sa tinukoy na node, ganap na pinapalitan ang lahat ng nilalaman nito. Ang push() ay awtomatikong bumubuo ng unique key (batay sa timestamp) para magdagdag ng elemento sa listahan — ito ang standard na paraan ng paggawa ng chat messages, posts at records. Ang updateChildren() ay nagbabago ng maraming node nang atomic sa isang operasyon. Ang addValueEventListener ay nag-subscribe sa mga pagbabago ng node at tumatanggap ng callback sa bawat update ng data.

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) }
    }
}

Real-time na pag-sync at offline mode

Mekanismo ng pag-sync ng Realtime Database ay batay sa WebSocket protocol (dati — long-polling). Ang client ay nagpapadala ng request para mag-subscribe sa isang partikular na node, at ang server ay pinapanatiling bukas ang koneksyon. Sa bawat pagbabago ng data sa naka-subscribe na node, ang server ay nagpapadala ng kumpletong JSON ng node na iyon sa client. Ang SDK sa client side ay awtomatikong nag-a-update ng local state at tumatawag ng kaukulang callbacks (onDataChange).

OnDisconnect — mga trigger ng pagdiskonekta

OnDisconnect — isang natatanging kakayahan ng Realtime Database na wala sa Firestore. Ang developer ay maaaring magrehistro ng write operation na awtomatikong isasagawa sa server kapag naputol ang koneksyon ng client. Ito ay ginagamit para sa presence status: "user123/status": "online" na may onDisconnect.setValue("offline"). Kung ang user ay nagsara ng app o nawalan ng internet, awtomatikong itatakda ng server ang status na "offline" sa loob ng hindi hihigit sa 3 minuto (maaaring i-configure sa Firebase console).

Offline na cache

Persistence sa Realtime Database ay naa-activate sa isang linya: FirebaseDatabase.getInstance().setPersistenceEnabled(true). Ni-ca-cache ng SDK ang huling estado ng lahat ng naka-subscribe na node sa disk (default hanggang 10 MiB, maaaring i-configure hanggang 100 MiB). Kapag nawala ang koneksyon, ang client ay patuloy na gumagana sa naka-cache na data, at lahat ng write operations ay naka-queue. Kapag naibalik ang koneksyon, ipinapadala ng SDK ang lahat ng naipon na pagbabago sa server sa tamang pagkakasunod-sunod (FIFO).

Ayon sa datos ng Google (2026), ang mga app na may naka-enable na persistence cache ay 40% mas madalang mawalan ng data ng user kapag naputol ang koneksyon. Gayunpaman, kung ang client ay nakaipon ng higit sa 1000 deferred operations, maaaring tanggihan ng server ang lahat ng ito at humiling ng kumpletong synchronization — ito ay isang mekanismo ng proteksyon laban sa mga lumang client.

Mga panuntunan sa seguridad at validation

Security Rules sa Realtime Database ay isang JSON configuration na naglalarawan kung sino at sa ilalim ng anong mga kondisyon ang maaaring magbasa at magsulat ng data sa bawat node. Ang mga panuntunan ay gumagana sa Google server at isinasagawa bago ang bawat operasyon. Bilang default (sa produksyon), inirerekomenda na itakda ang mga panuntunan sa "closed" mode — tanging ang mga naka-authenticate na user ang may access.

Structure ng rules

Ang mga panuntunan ng Realtime Database ay isinusulat sa JSON format na may mga section na .read, .write, .validate, .indexOn. Hindi tulad ng Firestore (na gumagamit ng match syntax), ang Realtime Database ay gumagamit ng nested objects na sumasalamin sa structure ng data. Ang mga condition ay nagsusuri ng auth (authentication), data (umiiral na data), newData (bagong data kapag nagsusulat) at now (oras ng server). Ang validation rules (.validate) ay nagpapahintulot ng pagsusuri ng mga uri, range ng halaga at structure ng data.

{
  "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"
      }
    }
  }
}

Cascade behavior at pag-test ng rules

Ang mga panuntunan ng Realtime Database ay minamana nang cascade — kung sa itaas na antas .read = false, lahat ng child node ay hindi naa-access para sa pagbasa anuman ang kanilang sariling mga panuntunan. Ang Firebase ay nagbibigay ng rule simulator sa console kung saan maaaring subukan ang mga operasyon na may iba't ibang auth token bago i-deploy. Inirerekomenda na palaging subukan ang mga panuntunan sa simulator — ang isang error sa panuntunan ay maaaring magbukas ng access sa pribadong data ng lahat ng user. Ayon sa datos ng Google (2026), 40% ng data leaks sa Firebase projects ay sanhi ng hindi tamang pagkaka-configure na security rules.