Firebase Realtime Database: nedir, JSON yapısı ve senkronizasyon

Firebase Realtime Database Nedir

Firebase Realtime Database, Google tarafından Firebase ile birlikte 2012'de başlatılan ilk bulut gerçek zamanlı veritabanlarından biridir. Verilerin tek bir URL üzerinden erişilebilen tek bir JSON ağacı olarak depolandığı bir NoSQL veritabanıdır. İstemci SDK'ları (Android, iOS, Web), WebSocket aracılığıyla belirli ağaç düğümlerine abone olur ve her veri değişikliğinde güncellemeler alır — sunucu yoklaması veya özel Push mekanizması uygulaması olmadan.

Tarihçe ve Gelişim

Orijinal Firebase, 2011'de James Tamplin ve Andrew Lee tarafından kuruldu ve ilk ürün Realtime Database'in kendisiydi. Google tarafından 2014'te satın alındıktan sonra (TechCrunch'a göre — 50 ila 100 milyon dolar arası bir bedelle), veritabanı Google Cloud'a entegre edildi ve önemli ölçüde daha yüksek verim elde etti. 2017'de Google, Firestore'u evrimsel bir yedek olarak duyurdu, ancak Realtime Database hala aktif olarak desteklenmekte ve güncellenmektedir. Google (2026)'ya göre, Realtime Database hala 1,5 milyondan fazla aktif projede kullanılmaktadır.

Ücretsiz Sınırlar ve Fiyatlandırma

Spark Planı (ücretsiz) şunları içerir: 1 GB depolama, aylık 10 GB indirilen veri, 100 eşzamanlı bağlantı ve tek bir bölgede veritabanı desteği. Blaze planında (kullandıkça öde), ek depolama (1$/GB), trafik (0,12$/GB) ve eşzamanlı bağlantılar (sınırın üzerindeki her 100 bin için 5$) için ücret alınır. Test için bir öykünme modu da mevcuttur — firebase emulators:start — buluta bağlanmadan Realtime Database'i yerel olarak çalıştırır.

Veri Yapısı: JSON Ağacı ve Normalizasyon

Realtime Database'in tabloları, koleksiyonları veya belgeleri yoktur — her şey https://project-name-default-rtdb.firebaseio.com/ gibi bir URL üzerinden erişilebilen tek bir JSON ağacıdır. Ağaçtaki her anahtar ya bir son değer (dize, sayı, boolean, null) ya da alt anahtarları olan iç içe bir düğümdür. Veritabanı motoru JOIN, alt sorgu veya toplama işlemlerini desteklemez — bir sorgu her zaman tüm alt öğeleriyle birlikte tek bir düğümün içeriğini döndürür.

Veri Normalizasyonu

Realtime Database'de JOIN eksikliği nedeniyle veri normalizasyonu zorunludur. İç içe bir ağaç (kullanıcı → gönderi listesi) yerine, veriler anahtarlar aracılığıyla referanslarla düz listelere bölünür. Bu standart yaklaşımdır: bir düğümün okunması tüm bağlamı çekmesin diye veriler normalden çıkarılır. Örneğin, sohbet mesajlarının listesi kullanıcı profillerinden ayrı olarak depolanır ve her gönderi, yazarın tam profilini değil yalnızca kimliğini içerir.

Realtime Database'de Sorgular

Sorgular, Realtime Database'de filtreler (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt) kullanılarak gerçekleştirilir. Firestore'un aksine, dizinler Rules bölümü (.indexOn) aracılığıyla manuel olarak oluşturulur. Bir dizin bildirilmezse, sıralamalı sorgu PERMISSION_DENIED hatası döndürür. Sorgular yalnızca tek bir alanda çalışır — bileşik sorgular (fiyata göre filtrele + tarihe göre sırala) desteklenmez. Karmaşık filtreleme için veriler genellikle farklı sıralama anahtarlarıyla farklı düğümlerde tekrarlanır.

Realtime Database vs Firestore: Hangisi Seçilmeli

Realtime Database ve Firestore arasında seçim yapmak, bir projeye başlarken sık karşılaşılan mimari kararlardan biridir. Google, yeni uygulamaların çoğu için Firestore'u önerir, ancak Realtime Database, minimum veri aktarım gecikmesinin kritik olduğu senaryolarda en iyi seçim olmaya devam etmektedir.

Realtime Database İçin Üç Temel Senaryo

İlk senaryo — durum senkronizasyonu olan çok oyunculu oyunlar (satranç, kart oyunları, gerçek zamanlı aksiyon). Realtime Database'in gecikmesi 10-30 ms iken aynı bölgede Firestore'un 50-100 ms'dir. İkinci senaryo — yüksek mesaj frekansına sahip sohbetler ve mesajlaşma uygulamaları. Realtime Database, yazma sayısına değil veri hacmine göre faturalandırılır ve bu da saniyede 1 mesajın üzerindeki frekanslarda Firestore'dan önemli ölçüde daha ucuz olmasını sağlar. Üçüncü senaryo — kullanıcıların çevrimiçi/çevrimdışı varlığı (presence), Realtime Database'in onDisconnect işleyicileri bağlantı kesildiğinde durumu atomik olarak ayarlamaya olanak tanır.

Google (2026)'ya göre, yeni Firebase projelerinin yaklaşık %15'i bilinçli olarak Realtime Database'i seçer — ekip gecikme, veri yapısı ve bütçe gereksinimlerini açıkça anladığında. Kalan %85 vakada Firestore, daha iyi ölçeklenebilirlik, daha güçlü sorgular ve otomatik çoğaltma sayesinde daha güvenli seçimdir.

Android'de Realtime Database Entegrasyonu

Realtime Database'i bir Android uygulamasına bağlamak, build.gradle'a firebase-database-ktx bağımlılığını ekleyerek yapılır. FirebaseDatabase nesnesi getInstance(url) aracılığıyla kullanılabilir — tek bir Firebase projesi içinde birden çok veritabanına bağlanabilirsiniz. Başlatmanın ardından SDK otomatik olarak sunucuyla bir WebSocket bağlantısı kurar ve veri senkronizasyonunu başlatır.

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

Veri Yazma ve Okuma

Realtime Database tüm işlemler için DatabaseReference nesnesini kullanır. setValue() belirtilen düğüme veri yazar ve tüm içeriğini tamamen değiştirir. push(), bir listeye öğe eklemek için otomatik olarak benzersiz bir anahtar (zaman damgasına dayalı) oluşturur — bu, sohbet mesajları, gönderiler ve kayıtlar oluşturmanın standart yoludur. updateChildren() tek bir işlemde birden çok düğümü atomik olarak değiştirir. addValueEventListener düğüm değişikliklerine abone olur ve her veri güncellemesinde bir geri çağrım alır.

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

Gerçek Zamanlı Senkronizasyon ve Çevrimdışı Mod

Senkronizasyon mekanizması, WebSocket protokolüne (daha önce — uzun yoklama) dayanır. İstemci belirli bir düğüme abone olmak için bir istek gönderir ve sunucu bağlantıyı açık tutar. Abone olunan düğümde herhangi bir veri değişikliği olduğunda, sunucu o düğümün tam JSON'unu istemciye gönderir. İstemcideki SDK otomatik olarak yerel durumu günceller ve ilgili geri çağrımları (onDataChange) tetikler.

OnDisconnect — Bağlantı Kesme Tetikleyicileri

OnDisconnect, Firestore'da bulunmayan Realtime Database'e özgü bir özelliktir. Bir geliştirici, istemcinin bağlantısı kesildiğinde sunucuda otomatik olarak yürütülecek bir yazma işlemi kaydedebilir. Bu, varlık durumları için kullanılır: “user123/status”: onDisconnect.setValue(“offline”) ile “online”. Kullanıcı uygulamayı kapatırsa veya interneti kaybederse, sunucu en fazla 3 dakika içinde durumu otomatik olarak “offline” olarak ayarlar (Firebase konsolunda yapılandırılabilir).

Çevrimdışı Önbellek

Persistence, Realtime Database'de tek bir satırla etkinleştirilir: FirebaseDatabase.getInstance().setPersistenceEnabled(true). SDK, diskte abone olunan tüm düğümlerin son durumunu önbelleğe alır (varsayılan olarak 10 MiB'a kadar, 100 MiB'a kadar yapılandırılabilir). Bağlantı kesildiğinde, istemci önbellekteki verilerle çalışmaya devam eder ve tüm yazma işlemleri sıraya alınır. Bağlantı geri yüklendiğinde SDK, birikmiş tüm değişiklikleri doğru sırada (FIFO) sunucuya gönderir.

Google (2026)'ya göre, kalıcılık önbelleği etkin uygulamalar, bağlantı kesintisinde kullanıcı verilerini kaybetme olasılığını %40 oranında azaltır. Ancak, bir istemci 1000'den fazla bekleyen işlem biriktirirse, sunucu hepsini reddedebilir ve tam senkronizasyon isteyebilir — bu, eski istemcilere karşı bir koruma mekanizmasıdır.

Güvenlik Kuralları ve Doğrulama

Güvenlik Kuralları, Realtime Database'de her düğümde kimlerin hangi koşullar altında veri okuyup yazabileceğini tanımlayan bir JSON yapılandırmasıdır. Kurallar Google'ın sunucusunda çalışır ve her işlemden önce uygulanır. Varsayılan olarak (üretimde), kuralların “kapalı” moda ayarlanması önerilir — yalnızca kimliği doğrulanmış kullanıcılar erişebilir.

Kural Yapısı

Realtime Database kuralları, .read, .write, .validate, .indexOn bölümleriyle JSON formatında yazılır. Firestore'un (match sözdizimi kullanan) aksine, Realtime Database veri yapısını yansıtan iç içe nesneler kullanır. Koşullar auth (kimlik doğrulama), data (mevcut veriler), newData (yazma sırasında yeni veriler) ve now (sunucu saati) kontrol eder. Doğrulama kuralları (.validate), türleri, değer aralıklarını ve veri yapısını kontrol etmeye olanak tanır.

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

Basamaklı Davranış ve Kural Testi

Realtime Database kuralları basamaklı olarak devralınır — üst düzeyde .read = false ise, tüm alt düğümler kendi kurallarından bağımsız olarak okuma için kullanılamaz. Firebase, dağıtımdan önce farklı auth token'larıyla işlemleri test edebileceğiniz konsolda bir kural simülatörü sağlar. Kuralları her zaman simülatörde test etmeniz önerilir — bir kuraldaki hata tüm kullanıcıların özel verilerine erişimi açabilir. Google (2026)'ya göre, Firebase projelerindeki veri sızıntılarının %40'ı yanlış yapılandırılmış güvenlik kurallarından kaynaklanır.