Firebase Realtime Database: bu nədir, JSON strukturu və sinxronizasiya

Firebase Realtime Database nədir

Firebase Realtime Database — Google tərəfindən 2012-ci ildə Firebase ilə birlikdə işə salınan ilk real vaxt bulud verilənlər bazalarından biridir. Bu NoSQL bazadır, burada verilənlər bir URL vasitəsilə əldə edilə bilən vahid JSON ağacı kimi saxlanılır. Kliyent SDK-lar (Android, iOS, Web) WebSocket vasitəsilə ağacın müəyyən qovşaqlarına abunə olur və hər verilən dəyişikliyində yeniləmələri alır — serveri ping etmədən və öz Push mexanizmini tətbiq etmədən.

Tarix və inkişaf

Orijinal Firebase 2011-ci ildə Ceyms Templin və Endryu Li tərəfindən qurulub və ilk məhsul məhz Realtime Database oldu. Google tərəfindən 2014-cü ildə satın alındıqdan sonra (TechCrunch məlumatına görə — 50-100 milyon dollar arasında) baza Google Cloud-a inteqrasiya edildi və əhəmiyyətli dərəcədə daha yüksək ötürmə qabiliyyəti əldə etdi. 2017-ci ildə Google Firestore-u təkamül əvəzedicisi kimi elan etdi, lakin Realtime Database aktiv şəkildə dəstəklənməyə və yenilənməyə davam edir. Google (2026) məlumatlarına görə, Realtime Database hələ də 1,5 milyondan çox aktiv layihədə istifadə olunur.

Pulsuz limitlər və tariflər

Spark tarifi (pulsuz) daxildir: 1 GB yaddaş, ayda 10 GB yüklənmiş verilən, 100 eyni vaxtda qoşulma və bir regionda verilənlər bazası dəstəyi. Blaze tarifində (pay-as-you-go) əlavə yaddaş (1 $/GB), trafik (0,12 $/GB) və eyni vaxtda qoşulmalar (hər 100 mindən sonra 5 $) üçün ödəniş tutulur. Test üçün həmçinin emulyasiya rejimi mövcuddur — firebase emulators:start — buluda qoşulmadan Realtime Database-i lokal olaraq işə salır.

Verilənlər strukturu: JSON ağacı və normalizasiya

Realtime Database-in cədvəlləri, kolleksiyaları və ya sənədləri yoxdur — hər şey https://project-name-default-rtdb.firebaseio.com/ ünvanında mövcud olan vahid JSON ağacıdır. Ağacın hər bir açarı ya son dəyərdir (sətir, rəqəm, boolean, null), ya da alt açarları olan iç-içə qovşaqdır. Verilənlər bazası mühərriki JOIN, alt sorğular və ya aqreqasiyaları dəstəkləmir — sorğu həmişə bütün alt elementləri ilə birlikdə bir qovşağın məzmununu qaytarır.

Verilənlərin normalizasiyası

Realtime Database-də JOIN-in olmaması səbəbindən verilənlərin normalizasiyası məcburidir. İç-içə ağac (istifadəçi → onun postlarının siyahısı) əvəzinə verilənlər açarlar vasitəsilə keçidlərlə yastı siyahılara bölünür. Bu standart yanaşmadır: verilənlərin denormalizasiyası edilir ki, bir qovşağın oxunması bütün konteksti çəkməsin. Məsələn, söhbət mesajlarının siyahısı istifadəçi profillərindən ayrı saxlanılır və hər bir post yalnız müəllifin ID-sini ehtiva edir, bütün profilini deyil.

Realtime Database-də sorğular

Sorğular Realtime Database-də filter (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt) istifadə edilərək yerinə yetirilir. Firestore-dan fərqli olaraq, indekslər Rules bölməsi (.indexOn) vasitəsilə əl ilə yaradılır. İndeks elan edilməyibsə, sıralama ilə sorğu PERMISSION_DENIED xətası qaytarır. Sorğular yalnız bir sahə üzrə işləyir — mürəkkəb sorğular (qiymətə görə filtr + tarixə görə sıralama) dəstəklənmir. Mürəkkəb filtrləmə üçün verilənlər tez-tez müxtəlif sıralama açarları ilə müxtəlif qovşaqlarda dublikasiya edilir.

Realtime Database vs Firestore: nə seçmək

Realtime Database və Firestore arasında seçim layihəyə başlayarkən tez-tez verilən memarlıq qərarlarından biridir. Google yeni tətbiqlərin əksəriyyəti üçün Firestore-u tövsiyə edir, lakin Realtime Database minimal verilən ötürmə gecikməsinin kritik olduğu ssenarilər üçün ən yaxşı seçim olaraq qalır.

Realtime Database üçün üç əsas ssenari

Birinci ssenari — vəziyyət sinxronizasiyası olan çoxistifadəçili oyunlar (şahmat, kart oyunları, real vaxt aksiyaları). Realtime Database gecikməsi eyni regionda Firestore üçün 50-100 ms qarşı 10-30 ms təşkil edir. İkinci ssenari — yüksək tezlikli mesajlaşma ilə söhbətlər və messencerlər. Realtime Database verilənlərin həcminə görə tarifləşdirilir, yazıların sayına görə deyil, bu da onu saniyədə 1 mesajdan çox tezlikdə Firestore-dan əhəmiyyətli dərəcədə ucuz edir. Üçüncü ssenari — istifadəçilərin online/offline iştirakı (presence), burada Realtime Database-in onDisconnect emalçıları bağlantı qırıldıqda statusu atomik olaraq təyin etməyə imkan verir.

Google (2026) məlumatlarına görə, yeni Firebase layihələrinin təxminən 15%-i şüurlu şəkildə Realtime Database-i seçir — komanda gecikmə, verilənlər strukturu və büdcə tələblərini dəqiq başa düşdükdə. Qalan 85% hallarda Firestore daha təhlükəsiz seçimdir, daha yaxşı miqyaslana bilmə, daha güclü sorğular və avtomatik replikasiya sayəsində.

Realtime Database-in Android-ə inteqrasiyası

Realtime Database-in qoşulması Android tətbiqinə build.gradle faylına firebase-database-ktx asılılığını əlavə etməklə həyata keçirilir. FirebaseDatabase obyekti getInstance(url) vasitəsilə mövcuddur — bir Firebase layihəsi çərçivəsində bir neçə bazaya qoşulmaq olar. İnisializasiyadan sonra SDK avtomatik olaraq serverlə WebSocket bağlantısı qurur və verilənlərin sinxronizasiyasına başlayır.

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

// İnitializasiya ilə xüsusi URL
val database = FirebaseDatabase.getInstance(
    "https://my-project-default-rtdb.firebaseio.com/"
)
val ref = database.getReference("chats")

Verilənlərin yazılması və oxunması

Realtime Database bütün əməliyyatlar üçün DatabaseReference obyektindən istifadə edir. setValue() göstərilən qovşaqda verilənləri yazır, onun bütün məzmununu tamamilə əvəz edir. push() siyahıya element əlavə etmək üçün avtomatik olaraq unikal açar yaradır (vaxt damğası əsasında) — bu, söhbət mesajları, postlar və qeydlər yaratmaq üçün standart üsuldur. updateChildren() bir əməliyyatda bir neçə qovşağı atomik olaraq dəyişir. addValueEventListener qovşaqdakı dəyişikliklərə abunə olur və hər verilən yeniləməsində callback 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) }
    }
}

Real vaxt sinxronizasiyası və offlayn rejim

Sinxronizasiya mexanizmi Realtime Database WebSocket protokoluna əsaslanır (əvvəllər — long-polling). Kliyent müəyyən bir qovşağa abunə olmaq üçün sorğu göndərir və server bağlantını açıq saxlayır. Abunə olunmuş qovşaqda hər hansı verilən dəyişikliyində server kliyentə həmin qovşağın tam JSON-nı göndərir. Kliyent tərəfdə SDK avtomatik olaraq lokal vəziyyəti yeniləyir və müvafiq callback-ləri (onDataChange) çağırır.

OnDisconnect — ayrılma tetikleyiciləri

OnDisconnect — Firestore-da olmayan, Realtime Database-in unikal imkanıdır. Developer kliyentin bağlantısı kəsildikdə serverdə avtomatik olaraq yerinə yetiriləcək yazma əməliyyatını qeydiyyatdan keçirə bilər. Bu, iştirak statusları üçün istifadə olunur: "user123/status": "online" onDisconnect.setValue("offline") ilə. İstifadəçi tətbiqi bağlayıbsa və ya interneti itiribsə, server avtomatik olaraq statusu "offline" olaraq təyin edəcək, ən çoxu 3 dəqiqə ərzində (Firebase konsolunda konfiqurasiya edilə bilər).

Offlayn keş

Persistence Realtime Database-də bir sətirlə aktivləşdirilir: FirebaseDatabase.getInstance().setPersistenceEnabled(true). SDK bütün abunə olunmuş qovşaqların son vəziyyətini diskdə keşləyir (standart olaraq 10 MiB-ə qədər, 100 MiB-ə qədər konfiqurasiya edilə bilər). Bağlantı itirildikdə kliyent keşləşdirilmiş verilənlərlə işləməyə davam edir və bütün yazma əməliyyatları növbəyə qoyulur. Bağlantı bərpa edildikdə, SDK bütün toplanmış dəyişiklikləri düzgün ardıcıllıqla (FIFO) serverə göndərir.

Google (2026) məlumatlarına görə, persistence keşi aktiv edilmiş tətbiqlər bağlantı qırılması zamanı istifadəçi verilənlərini 40% daha az itirir. Bununla belə, kliyent 1000-dən çox təxirə salınmış əməliyyat toplayıbsa, server onların hamısını rədd edə və tam sinxronizasiya tələb edə bilər — bu köhnəlmiş kliyentlərə qarşı qoruyucu mexanizmdir.

Təhlükəsizlik qaydaları və validasiya

Security Rules Realtime Database-də kimin hansı şərtlər altında hər bir qovşaqda verilənləri oxuya və yaza biləcəyini təsvir edən JSON konfiqurasiyasıdır. Qaydalar Google serverində işləyir və hər əməliyyatdan əvvəl yerinə yetirilir. Standart olaraq (produksiyada) qaydaların "qapalı" rejimində qurulması tövsiyə olunur — yalnız autentifikasiya olunmuş istifadəçilər giriş əldə edir.

Rules strukturu

Realtime Database qaydaları .read, .write, .validate, .indexOn bölmələri ilə JSON formatında yazılır. Firestore-dan (match sintaksisindən istifadə edən) fərqli olaraq, Realtime Database verilənlər strukturunu təkrarlayan iç-içə obyektlərdən istifadə edir. Şərtlər auth (autentifikasiya), data (mövcud verilənlər), newData (yazma zamanı yeni verilənlər) və now (server vaxtı) yoxlayır. Validasiya qaydaları (.validate) tipləri, dəyər diapazonlarını və verilənlər strukturunu yoxlamağa imkan verir.

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

Kaskad davranış və rules testi

Realtime Database qaydaları kaskad olaraq miras alınır — yuxarı səviyyədə .read = false olarsa, bütün alt qovşaqlar öz qaydalarından asılı olmayaraq oxumaq üçün əlçatmazdır. Firebase konsolda qaydalar simulyatorunu təqdim edir, burada yerləşdirmədən əvvəl müxtəlif auth tokenləri ilə əməliyyatları sınamaq olar. Qaydaları həmişə simulyatorda sınamaq tövsiyə olunur — qaydalardakı səhv bütün istifadəçilərin şəxsi verilənlərinə girişi aça bilər. Google (2026) məlumatlarına görə, Firebase layihələrində verilən sızmalarının 40%-i düzgün konfiqurasiya edilməmiş təhlükəsizlik qaydaları səbəbindən baş verir.