Firebase Realtime DB — mi ez, architektúra és munka JSON-nal

Mi az a Firebase Realtime Database?

Firebase Realtime Database egy felhőalapú NoSQL adatbázis, amely valós időben tárolja és szinkronizálja az adatokat az összes csatlakoztatott kliens között. 2012-ben indították Firebase ként (még mielőtt a Google felvásárolta volna), és ez volt az első felhőalapú valós idejű adatbázis a mobilfejlesztők számára. Az adatok JSON formátumban vannak bemutatva és hierarchikus fába szervezve, ahol minden csomópontnak egyedi útja van.

A Realtime Database fő értéke a beépített szinkronizáció. Amikor az alkalmazás megváltoztatja az adatokat bármely eszközön, az összes többi csatlakoztatott kliens azonnal frissítést kap egy állandó kapcsolaton keresztül. Ez megkíméli a fejlesztőt a saját szinkronizációs mechanizmus, WebSocket szerver vagy REST API megvalósításától az adatok kliensek közötti átviteléhez.

Az adatbázis SDK-t biztosít az összes fő platformhoz: Android (Java, Kotlin), iOS (Swift, Objective-C), Web (JavaScript) és szerver környezetekhez az Admin SDK-n keresztül. A Google adatai szerint a Realtime Database-t több mint 1,5 millió aktív Firebase-projektben használják világszerte. A modernebb Firestore megjelenése ellenére a Realtime Database továbbra is népszerű választás az egyszerű adatszerkezetű projektek számára.

Adatszerkezet: JSON-fa

A relációs adatbázisokkal ellentétben a Realtime Database nem használ táblákat és sorokat. Minden adat egyetlen JSON-fát alkot, amely egymásba ágyazott JavaScript-objektumoknak néz ki. Például a felhasználók és üzeneteik tárolásához hierarchia jön létre: users/userId/name és messages/messageId/text. A fa minden útja egy karakterlánc, és az adatok közvetlenül ezen az úton keresztül olvashatók.

{
  "users": {
    "user1": {
      "name": "Ivan Petrov",
      "email": "ivan@example.com"
    },
    "user2": {
      "name": "Maria Sokolova",
      "email": "maria@example.com"
    }
  },
  "messages": {
    "-Nabc123": {
      "text": "Szia!",
      "userId": "user1"
    }
  }
}

Fontos jellemző, hogy a mély egymásba ágyazás befolyásolja a teljesítményt. Amikor az alkalmazás egy adott úton olvassa az adatokat, betölti az út összes gyermek csomópontját. Ezért ajánlott az adatszerkezetet a lehető leglaposabbra tervezni, elkerülve a 3–4 szintnél mélyebb egymásba ágyazást. A probléma megoldásához adatdenormalizálást használnak — az információk megkettőzését a fa különböző csomópontjaiban.

Realtime Database vs Firestore: mikor válasszuk

Realtime Database és Firestore gyakran összehasonlítják mint két felhőalapú valós idejű adatbázis a Google-tól. A köztük való választás a projekt konkrét követelményeitől függ: a lekérdezések összetettségétől, a szükséges konzisztenciától és a tervezett terheléstől. Az egyes adatbázisok erősségeinek megértése segít a helyes architektúrális döntés meghozatalában.

A Realtime Database fő előnye az alacsony szinkronizációs késleltetés. Mivel minden adat egyetlen JSON-fában, további absztrakciós rétegek nélkül van tárolva, a szinkronizáció gyorsabb, mint a Firestore-ban. Azon alkalmazások számára, ahol a frissítések kézbesítésének sebessége kritikus (chat-ek, online játékok, közös szerkesztő rendszerek), a Realtime Database megfelelőbb választás lehet.

Mikor használjuk a Realtime Database-t

Realtime Database alkalmasabb az egyszerű adatszerkezetű és magas frissítési gyakoriságú forgatókönyvekhez. Tipikus példák: chat-ek, valós idejű like-ok, gépelési jelzők, felhasználói jelenléti állapotok. Ez jó választás prototípusok és korlátozott költségvetésű projektek számára is, mivel az árképzés az adatmennyiségen alapul, nem a műveletek számán.

Másrészt, az összetett lekérdezésekkel rendelkező alkalmazások számára (több mező szerinti szűrés, rendezés, aggregáció) a Firestore sokkal erősebb lehetőségeket kínál. A Realtime Database csak egy paraméter szerinti szűrést támogat, és nem képes az eredményeket egyszerre több mező szerint rendezni. Ha a projekt összetett adatelemzést tervez az üfél oldalon, a Firestore praktikusabb választás lesz.

Hogyan működik a szinkronizáció a Realtime Database-ben

Realtime Database állandó WebSocket-kapcsolatot használ a kétirányú adatszinkronizációhoz. Amikor az üfél meghívja a setValue vagy updateChildren függvényt egy adott úton, az adatok egy nyitott csatornán keresztül elküldődnek a Firebase szerverre. A szerver alkalmazza a változtatásokat és ezredmásodperceken belül terjeszti a frissítéseket az összes feliratkozott kliensnek. Minden kapcsolatot egy egyedi munkamenet-kulcs azonosít.

A feliratkozási mechanizmus listener-eken keresztül működik. A fejlesztő feliratkozhat egy adott csomópont változására (addListenerForSingleValueEvent) vagy állandó frissítéseket kaphat (addValueEventListener). Minden adatváltozáskor meghívódik az onDataChange callback a megadott úton lévő adatok teljes pillanatképével. Ez eltér a Firestore-tól, ahol csak a módosított dokumentumok érkeznek — a Realtime Database-ben mindig a csomópont összes adata betöltődik.

Offline mód és ütközéskezelés

Realtime Database támogatja az offline módot Android és iOS platformokon lemez gyorsítótár segítségével. Az SDK megőrzi az adatok helyi másolatát és folytatja az írási műveletek feldolgozását hálózat hiányában. Amikor a kapcsolat helyreáll, az összes felhalmozódott változtatás elküldődik a szerverre. Az ütközések feloldásához a last-write-wins stratégiát használja, de a fejlesztő egyéni logikát is megvalósíthat a ServerValue.TIMESTAMP segítségével az ütközések feloldásához.

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

// Adatok írása
myRef.push().setValue(
    hashMapOf(
        "text" to "Új üzenet",
        "timestamp" to ServerValue.TIMESTAMP
    )
)

// Olvasás folyamatos frissítéssel
myRef.addValueEventListener(object : ValueEventListener {
    override fun onDataChange(snapshot: DataSnapshot) {
        val data = snapshot.getValue()
        Log.d("TAG", "Adatok: $data")
    }

    override fun onCancelled(error: DatabaseError) {
        Log.w("TAG", "Hiba: ${error.message}")
    }
})

A forgalom és a teljesítmény optimalizálása érdekében ajánlott a child listener-ek használata a value listener-ek helyett, amikor bizonyos gyermek csomópontok változásait kell követni. A ChildEventListener külön callback-eket biztosít a gyermek elemek hozzáadásához, módosításához, törléséhez és áthelyezéséhez, ami lehetővé teszi a UI-frissítések pontosabb szabályozását és a lista összes eleme újrarajzolásának elkerülését minden adatváltozáskor.

Biztonsági szabályok és adatérvényesítés

Realtime Database deklaratív szabálynyelvet használ az adathozzáférés szabályozásához. A szabályok leírják, hogy ki olvashat és írhat adatokat a JSON-fa minden útján. Ezek a szerveren ellenőrződnek minden kérés előtt, és nem igényelnek szerver logikát az engedélyezéshez. A szabályok támogatják a változókat, beépített objektumokat és függvényeket a rugalmas hozzáférési konfigurációhoz.

Alapértelmezés szerint az adatbázishoz való hozzáférés minden felhasználó számára tiltott. A fejlesztő fokozatosan nyitja meg a hozzáférést a ".read" és ".write" szabályok használatával a fa különböző szintjein. A feltételek ellenőrizhetik a hitelesítést az auth változón keresztül, a kérés típusát (read/write) és a meglévő adatokat a data objektumon keresztül. Ezenkívül a szabályok támogatják az írt adatok érvényesítését a newData objektumon keresztül.

{
  "rules": {
    "users": {
      "$uid": {
        // Csak a tulajdonos olvashatja saját adatait
        ".read": "$uid === auth.uid",
        // Csak a tulajdonos írhat
        ".write": "$uid === auth.uid",
        // Mezők érvényesítése íráskor
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      // Bármely hitelesített felhasználó olvashat
      ".read": "auth !== null",
      // Csak hitelesített írhat
      ".write": "auth !== null",
      ".indexOn": ["timestamp"]
    }
  }
}

A szabályok támogatják az adatok indexelését is a ".indexOn" direktíván keresztül. Enélkül a rendezéses lekérdezések (orderByChild) elutasításra kerülnek vagy hatéktalanul hajthatók végre. Az indexek minden olyan úthoz meg vannak adva, ahol rendezés történik egy adott mező szerint. A szabályok kaszkád jellegűek: a mélyebb szabályok felülírják a szülő szabályokat, és ha egy adott szinten nincs hozzáférés, az a szülő szabálytól függően engedélyezettnek vagy tiltottnak tekintendő.

Adattípusok és korlátozások

Realtime Database öt adattípust támogat: String, Number, Boolean, Map (objektum) és List (tömb). Az egymásba ágyazás mélysége 32 szintre korlátozódik, és egy csomópont maximális mérete nem haladhatja meg a 256 MB-ot. Az adatbázissal való hatékony munkához ajánlott lapos adatszerkezetet tervezni és denormalizálást használni a mély lekérdezések elkerüléséhez, amelyek nagy adatmennyiséget töltenek be.

Példa a Realtime Database használatára Androidban

Nézzünk egy gyakorlati példát a Realtime Database integrálására egy Android-alkalmazásban felhasználói állapotokhoz (online/offline). Az alkalmazás megjeleníti a felhasználók listáját az aktuális állapotukkal, amely valós időben frissül. A bemutatóhoz Firebase Authentication-t használunk a felhasználók azonosításához és korutinokat az aszinkron műveletekhez.

Függőségek beállítása és inicializálás

Először adja hozzá a firebase-database-ktx függőséget az alkalmazás modul build.gradle fájljához. A könyvtár verzióját a Firebase BoM kezeli az összes komponens kompatibilitásának biztosítása érdekében. A függőség hozzáadása után inicializálni kell a Firebase-t az Application osztályban vagy lusta inicializálással a ViewModel-ben.

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

A konfiguráció után létrejön egy repository a felhasználókkal való munkához. Minden felhasználót egy csomópont képvisel a /users/{uid} fában name, email és status mezőkkel. Az állapot követéséhez az onDisconnect-t használjuk — egy speciális Firebase mechanizmust, amely automatikusan végrehajt egy írási műveletet az üfél kapcsolatának megszakadásakor. Ez garantálja, hogy a felhasználó állapota "offline"-ra változzon az alkalmazás bezárásakor vagy a hálózat elvesztésekor, anélkül, hogy további kódra lenne szükség az üfél oldalán.

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

A példa kulcseleme az onDisconnect. Ez a mechanizmus lehetővé teszi egy írási művelet beállítását, amely a szerveren végrehajtódik az üfél kapcsolatának megszakadásakor. Ebben az esetben a felhasználó leválasztásakor az állapota automatikusan "offline"-ra állítódik anélkül, hogy kezelni kellene az alkalmazás bezárásának eseményét. Ha az alkalmazás váratlanul leáll, a Firebase maga hajtja végre az onDisconnect műveletet, és a többi felhasználó a helyes állapotot látja.