Firebase Realtime Database: mi ez, JSON struktúra és szinkronizáció

Mi a Firebase Realtime Database

Firebase Realtime Database az egyik első valós idejű felhőadatbázis, amelyet a Google a Firebase-szel együtt indított el 2012-ben. Ez egy NoSQL adatbázis, ahol az adatok egyetlen JSON-faként tárolódnak, amely egy URL-en keresztül érhető el. A kliens SDK-k (Android, iOS, Web) WebSocketen keresztül feliratkoznak a fa adott csomópontjaira, és minden adatváltozáskor frissítéseket kapnak — anélkül, hogy pingelnék a szervert, és anélkül, hogy saját Push-mechanizmust kellene implementálniuk.

Történelem és fejlődés

Az eredeti Firebase-t 2011-ben alapította James Tamplin és Andrew Lee, és az első termék pont a Realtime Database volt. Miután a Google 2014-ben felvásárolta (a TechCrunch szerint — 50-100 millió dollár közötti összegért), az adatbázis integrálódott a Google Cloudba, és jelentősen nagyobb sávszélességet kapott. 2017-ben a Google bejelentette a Firestore-t evolúciós helyettesítőként, de a Realtime Database továbbra is aktívan támogatott és frissített. A Google (2026) adatai szerint a Realtime Database még mindig több mint 1,5 millió aktív projektben használatos.

Ingyenes korlátok és díjak

Spark tarifa (ingyenes) tartalmazza: 1 GB tárhely, 10 GB letöltött adat havonta, 100 egyidejű kapcsolat és adatbázis-támogatás egy régióban. A Blaze tarifán (pay-as-you-go) a többlet tárhelyért (1 $/GB), forgalomért (0,12 $/GB) és egyidejű kapcsolatokért (5 $ minden 100 ezer után a limit felett) kell fizetni. Teszteléshez emulációs mód is elérhető — firebase emulators:start — amely helyben futtatja a Realtime Database-t a felhőhöz való csatlakozás nélkül.

Adatstruktúra: JSON-fa és normalizálás

Realtime Database nem rendelkezik táblákkal, gyűjteményekkel vagy dokumentumokkal — minden egyetlen JSON-fa, amely a https://project-name-default-rtdb.firebaseio.com/ címen érhető el. A fa minden kulcsa vagy egy végérték (karakterlánc, szám, boolean, null), vagy egy beágyazott csomópont gyermekkulcsokkal. Az adatbázismotor nem támogatja a JOIN, alkérdéseket vagy aggregációkat — egy lekérdezés mindig egyetlen csomópont tartalmát adja vissza az összes gyermekelemmel együtt.

Adatnormalizálás

A JOIN hiánya miatt a Realtime Database-ben az adatnormalizálás kötelező. A beágyazott fa (felhasználó → bejegyzéseinek listája) helyett az adatok lapos listákra vannak bontva, kulcsokon keresztüli hivatkozásokkal. Ez a szabványos megközelítés: az adatok denormalizálódnak, hogy egy csomópont olvasása ne húzza magával a teljes kontextust. Például a csevegőüzenetek listája külön tárolódik a felhasználói profiloktól, és minden bejegyzés csak a szerző ID-ját tartalmazza, nem a teljes profilját.

Lekérdezések a Realtime Database-ben

Lekérdezések a Realtime Database-ben filter segítségével (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt) hajtódnak végre. A Firestore-tól eltérően az indexek manuálisan jönnek létre a Rules szakaszon (.indexOn) keresztül. Ha az index nincs deklarálva, a rendezéssel rendelkező lekérdezés PERMISSION_DENIED hibát ad vissza. A lekérdezések csak egy mezőn működnek — az összetett lekérdezések (ár szerinti szűrés + dátum szerinti rendezés) nem támogatottak. Az összetett szűréshez az adatok gyakran különböző csomópontokban duplikálódnak eltérő rendezési kulcsokkal.

Realtime Database vs Firestore: mit válasszunk

A Realtime Database és a Firestore közötti választás az egyik gyakori architektúrális döntés a projekt indításakor. A Google a Firestore-t ajánlja a legtöbb új alkalmazáshoz, de a Realtime Database továbbra is a legjobb választás azokban a forgatókönyvekben, ahol a minimális adatátviteli késleltetés kritikus.

Három kulcsfontosságú forgatókönyv a Realtime Database-hez

Első forgatókönyv — többszereplős játékok állapotszinkronizációval (sakk, kártyajátékok, valós idejű akció). A Realtime Database késleltetése 10-30 ms, szemben a Firestore 50-100 ms-ával ugyanabban a régióban. Második forgatókönyv — csevegések és üzenetküldők magas üzenetgyakorisággal. A Realtime Database az adatmennyiség alapján díjazott, nem az írások száma alapján, ami jelentősen olcsóbbá teszi a Firestore-nál másodpercenként 1 üzenet feletti gyakoriságnál. Harmadik forgatókönyv — a felhasználók online/offline jelenléte (presence), ahol a Realtime Database onDisconnect-kezelői lehetővé teszik az állapot atomi beállítását a kapcsolat megszakadásakor.

A Google (2026) adatai szerint az új Firebase-projektek körülbelül 15%-a tudatosan választja a Realtime Database-t — amikor a csapat világosan érti a késleltetési, adatstruktúra- és költségvetési követelményeket. A fennmaradó 85%-ban a Firestore a biztonságosabb választás a jobb skálázhatóság, az erősebb lekérdezések és az automatikus replikáció miatt.

Realtime Database integrálása Androidban

A Realtime Database csatlakoztatása egy Android-alkalmazáshoz a firebase-database-ktx függőség hozzáadásával történik a build.gradle fájlban. A FirebaseDatabase objektum a getInstance(url) segítségével érhető el — több adatbázis is csatlakoztatható egyetlen Firebase-projekten belül. Az inicializálás után az SDK automatikusan WebSocket-kapcsolatot létesít a szerverrel, és megkezdi az adatok szinkronizációját.

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

// Inicializálás egyéni URL-lel
val database = FirebaseDatabase.getInstance(
    "https://my-project-default-rtdb.firebaseio.com/"
)
val ref = database.getReference("chats")

Adatok írása és olvasása

Realtime Database a DatabaseReference objektumot használja minden művelethez. A setValue() adatokat ír a megadott csomópontba, teljesen felülírva annak teljes tartalmát. A push() automatikusan egyedi kulcsot generál (időbélyeg alapján) egy elem lista hozzáadásához — ez a szabványos módja a csevegőüzenetek, bejegyzések és rekordok létrehozásának. Az updateChildren() több csomópontot atomi módon módosít egyetlen műveletben. Az addValueEventListener feliratkozik egy csomópont változásaira, és minden adatfrissítéskor callback-et kap.

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

Valós idejű szinkronizáció és offline mód

A szinkronizációs mechanizmus a Realtime Database-ben a WebSocket protokollon alapul (korábban — long-polling). A kliens feliratkozási kérelmet küld egy adott csomópontra, és a szerver nyitva tartja a kapcsolatot. A feliratkozott csomópont minden adatváltozásakor a szerver elküldi a kliensnek a csomópont teljes JSON-ját. A kliens oldali SDK automatikusan frissíti a helyi állapotot, és meghívja a megfelelő callback-eket (onDataChange).

OnDisconnect — kapcsolat-megszakítási triggerek

OnDisconnect — a Realtime Database egyedi képessége, amely hiányzik a Firestore-ból. A fejlesztő regisztrálhat egy írási műveletet, amely automatikusan végrehajtódik a szerveren a kliens kapcsolatának megszakadásakor. Ezt a jelenléti állapotokhoz használják: "user123/status": "online" onDisconnect.setValue("offline") paraméterrel. Ha a felhasználó bezárta az alkalmazást vagy elvesztette az internetet, a szerver automatikusan beállítja az "offline" állapotot, legfeljebb 3 percen belül (beállítható a Firebase konzolban).

Offline gyorsítótár

Persistence a Realtime Database-ben egy sorral aktiválható: FirebaseDatabase.getInstance().setPersistenceEnabled(true). Az SDK az összes feliratkozott csomópont utolsó állapotát a lemezen gyorsítótárazza (alapértelmezés szerint 10 MiB-ig, 100 MiB-ig állítható). Kapcsolat elvesztésekor a kliens tovább dolgozik a gyorsítótárazott adatokkal, és az összes írási művelet sorba kerül. Amikor a kapcsolat helyreáll, az SDK az összes felhalmozott változtatást a helyes sorrendben (FIFO) elküldi a szerverre.

A Google (2026) adatai szerint a persistence gyorsítótárat használó alkalmazások 40%-kal ritkábban veszítenek el felhasználói adatokat kapcsolat megszakadásakor. Ha azonban a kliens több mint 1000 halasztott műveletet halmozott fel, a szerver elutasíthatja az összeset, és teljes szinkronizációt kérhet — ez egy védelmi mechanizmus az elavult kliensek ellen.

Biztonsági szabályok és validálás

Security Rules a Realtime Database-ben egy JSON-konfiguráció, amely leírja, hogy ki és milyen feltételek mellett olvashat és írhat adatokat az egyes csomópontokban. A szabályok a Google szerverén működnek, és minden művelet előtt végrehajtódnak. Alapértelmezés szerint (éles környezetben) ajánlott a szabályokat "zárt" módban beállítani — csak a hitelesített felhasználók férhetnek hozzá.

A rules struktúrája

A Realtime Database szabályai JSON formátumban íródnak .read, .write, .validate, .indexOn szakaszokkal. A Firestore-tól eltérően (amely match szintaxist használ), a Realtime Database beágyazott objektumokat használ, amelyek tükrözik az adatstruktúrát. A feltételek ellenőrzik az auth-ot (hitelesítés), data-t (meglévő adatok), newData-t (új adatok íráskor) és now-t (szerveridő). A validációs szabályok (.validate) lehetővé teszik a típusok, értéktartományok és adatstruktúrák ellenőrzését.

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

Kaszkád viselkedés és a rules tesztelése

A Realtime Database szabályai kaszkádolva öröklődnek — ha a felső szinten .read = false, akkor az összes gyermek csomópont nem érhető el olvasásra, függetlenül a saját szabályaiktól. A Firebase egy szabály-szimulátort biztosít a konzolban, ahol a műveletek különböző auth tokenekkel tesztelhetők az élesítés előtt. Javasolt mindig tesztelni a szabályokat a szimulátorban — egy hiba a szabályban hozzáférhetővé teheti az összes felhasználó privát adatait. A Google (2026) adatai szerint a Firebase-projektek adatszivárgásainak 40%-át helytelenül konfigurált biztonsági szabályok okozzák.