Firebase Realtime Database: co to je, struktura JSON a synchronizace

Co je Firebase Realtime Database

Firebase Realtime Database je jedna z prvních cloudových databází v reálném čase, kterou Google spustil společně s Firebase v roce 2012. Jedná se o NoSQL databázi, kde jsou data uložena jako jeden JSON strom přístupný přes jednu URL. Klientské SDK (Android, iOS, Web) se prostřednictvím WebSocketu přihlašují k odběru konkrétních uzlů stromu a dostávají aktualizace při každé změně dat — bez pingování serveru a bez implementace vlastního Push mechanismu.

Historie a vývoj

Původní Firebase založili v roce 2011 James Tamplin a Andrew Lee a prvním produktem byl právě Realtime Database. Po akvizici společností Google v roce 2014 (podle TechCrunch — za částku mezi 50 a 100 miliony dolarů) byla databáze integrována do Google Cloud a získala výrazně vyšší propustnost. V roce 2017 Google oznámil Firestore jako evoluční náhradu, ale Realtime Database je nadále aktivně podporována a aktualizována. Podle údajů Google (2026) se Realtime Database stále používá ve více než 1,5 milionu aktivních projektů.

Bezplatné limity a tarify

Spark tarif (zdarma) zahrnuje: 1 GB úložiště, 10 GB stažených dat měsíčně, 100 současných připojení a podporu databáze v jedné oblasti. V tarifu Blaze (pay-as-you-go) se platí za dodatečné úložiště (1 $/GB), provoz (0,12 $/GB) a současná připojení (5 $ za každých 100 tisíc nad limit). Pro testování je k dispozici také režim emulace — firebase emulators:start — který spouští Realtime Database lokálně bez připojení k cloudu.

Struktura dat: JSON strom a normalizace

Realtime Database nemá tabulky, kolekce ani dokumenty — vše je jeden JSON strom přístupný na URL ve tvaru https://project-name-default-rtdb.firebaseio.com/. Každý klíč stromu je buď konečná hodnota (řetězec, číslo, boolean, null), nebo vnořený uzel s podřízenými klíči. Databázový engine nepodporuje JOIN, poddotazy ani agregace — dotaz vždy vrací obsah jednoho uzlu se všemi podřízenými prvky.

Normalizace dat

Kvůli absenci JOIN v Realtime Database je normalizace dat povinná. Místo vnořeného stromu (uživatel → seznam jeho příspěvků) jsou data rozdělena do plochých seznamů s odkazy prostřednictvím klíčů. Toto je standardní přístup: data jsou denormalizována tak, aby čtení jednoho uzlu nestahovalo celý kontext. Například seznam zpráv chatu je uložen odděleně od profilů uživatelů a každý příspěvek obsahuje pouze ID autora, nikoli celý jeho profil.

Dotazy v Realtime Database

Dotazy v Realtime Database se provádějí pomocí filter (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt). Na rozdíl od Firestore se indexy vytvářejí ručně prostřednictvím sekce Rules (.indexOn). Pokud index není deklarován, dotaz s řazením vrátí chybu PERMISSION_DENIED. Dotazy fungují pouze na jednom poli — složené dotazy (filtr podle ceny + řazení podle data) nejsou podporovány. Pro složité filtrování jsou data často duplikována v různých uzlech s různými klíči řazení.

Realtime Database vs Firestore: co vybrat

Volba mezi Realtime Database a Firestore je jedno z častých architektonických rozhodnutí při zahájení projektu. Google doporučuje Firestore pro většinu nových aplikací, ale Realtime Database zůstává nejlepší volbou pro scénáře, kde je kritická minimální latence přenosu dat.

Tři klíčové scénáře pro Realtime Database

První scénář — multiplayerové hry se synchronizací stavu (šachy, karetní hry, akce v reálném čase). Latence Realtime Database je 10-30 ms oproti 50-100 ms u Firestore ve stejné oblasti. Druhý scénář — chaty a messenger s vysokou frekvencí zpráv. Realtime Database je účtována podle objemu dat, nikoli podle počtu zápisů, což ji činí výrazně levnější než Firestore při frekvenci vyšší než 1 zpráva za sekundu. Třetí scénář — přítomnost (presence) uživatelů online/offline, kde obslužné rutiny onDisconnect v Realtime Database umožňují atomické nastavení stavu při přerušení připojení.

Podle údajů Google (2026) přibližně 15 % nových Firebase projektů vědomě volí Realtime Database — když tým jasně rozumí požadavkům na latenci, strukturu dat a rozpočet. Ve zbývajících 85 % případů je Firestore bezpečnější volbou díky lepší škálovatelnosti, výkonnějším dotazům a automatické replikaci.

Integrace Realtime Database v Androidu

Připojení Realtime Database k Android aplikaci se provádí přidáním závislosti firebase-database-ktx do build.gradle. Objekt FirebaseDatabase je dostupný prostřednictvím getInstance(url) — lze se připojit k několika databázím v rámci jednoho Firebase projektu. Po inicializaci SDK automaticky naváže WebSocket připojení se serverem a zahájí synchronizaci dat.

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

// Inicializace s vlastní URL
val database = FirebaseDatabase.getInstance(
    "https://my-project-default-rtdb.firebaseio.com/"
)
val ref = database.getReference("chats")

Zápis a čtení dat

Realtime Database používá objekt DatabaseReference pro všechny operace. setValue() zapisuje data do určeného uzlu a zcela nahrazuje veškerý jeho obsah. push() automaticky generuje jedinečný klíč (na základě časového razítka) pro přidání prvku do seznamu — to je standardní způsob vytváření chatovacích zpráv, příspěvků a záznamů. updateChildren() mění více uzlů atomicky v jedné operaci. addValueEventListener se přihlašuje k odběru změn uzlu a přijímá callback při každé aktualizaci dat.

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

Synchronizace v reálném čase a offline režim

Mechanismus synchronizace Realtime Database je založen na protokolu WebSocket (dříve — long-polling). Klient odešle požadavek na odběr konkrétního uzlu a server udržuje připojení otevřené. Při každé změně dat v odebíraném uzlu server pošle klientovi kompletní JSON tohoto uzlu. SDK na straně klienta automaticky aktualizuje lokální stav a volá příslušné callbacky (onDataChange).

OnDisconnect — spouštěče odpojení

OnDisconnect — jedinečná schopnost Realtime Database, která ve Firestore chybí. Vývojář může zaregistrovat operaci zápisu, která se automaticky provede na serveru při přerušení připojení klienta. Používá se pro stavy přítomnosti: "user123/status": "online" s onDisconnect.setValue("offline"). Pokud uživatel zavřel aplikaci nebo ztratil internet, server automaticky nastaví stav "offline" nejpozději do 3 minut (lze nastavit v konzoli Firebase).

Offline mezipaměť

Persistence v Realtime Database se aktivuje jedním řádkem: FirebaseDatabase.getInstance().setPersistenceEnabled(true). SDK ukládá do mezipaměti na disk poslední stav všech odebíraných uzlů (ve výchozím nastavení až 10 MiB, lze nastavit až 100 MiB). Při ztrátě připojení klient pokračuje v práci s daty v mezipaměti a všechny operace zápisu jsou zařazeny do fronty. Po obnovení připojení SDK odešle všechny nahromaděné změny na server ve správném pořadí (FIFO).

Podle údajů Google (2026) aplikace s povolenou persistence mezipamětí ztrácejí data uživatelů při přerušení připojení o 40 % méně často. Pokud však klient nashromáždil více než 1000 odložených operací, server může všechny odmítnout a požádat o úplnou synchronizaci — jedná se o ochranný mechanismus proti zastaralým klientům.

Bezpečnostní pravidla a validace

Security Rules v Realtime Database je JSON konfigurace, která popisuje, kdo a za jakých podmínek může číst a zapisovat data v každém uzlu. Pravidla fungují na serveru Google a provádějí se před každou operací. Ve výchozím nastavení (v produkci) se doporučuje nastavit pravidla do režimu "uzamčeno" — přístup mají pouze autentizovaní uživatelé.

Struktura rules

Pravidla Realtime Database se píší ve formátu JSON s oddíly .read, .write, .validate, .indexOn. Na rozdíl od Firestore (který používá syntaxi match) používá Realtime Database vnořené objekty, které odrážejí strukturu dat. Podmínky kontrolují auth (autentizaci), data (existující data), newData (nová data při zápisu) a now (čas serveru). Validační pravidla (.validate) umožňují kontrolovat typy, rozsahy hodnot a strukturu dat.

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

Kaskádové chování a testování rules

Pravidla Realtime Database se dědí kaskádově — pokud je na nejvyšší úrovni .read = false, pak jsou všechny podřízené uzly nepřístupné pro čtení bez ohledu na jejich vlastní pravidla. Firebase poskytuje simulátor pravidel v konzoli, kde lze otestovat operace s různými auth tokeny před nasazením. Doporučuje se vždy testovat pravidla v simulátoru — chyba v pravidle může otevřít přístup k soukromým datům všech uživatelů. Podle údajů Google (2026) je 40 % úniků dat v projektech Firebase způsobeno nesprávně nakonfigurovanými bezpečnostními pravidly.