Firebase Firestore — ce este, documente și colecții NoSQL

Ce este Firebase Firestore

Firebase Firestore este o bază de date NoSQL în cloud lansată de Google în 2019 ca succesor al Realtime Database. Firestore este construit pe infrastructura Google Cloud Spanner și Google Cloud Datastore, asigurând consistență strictă a datelor în cadrul unei singure tranzacții și replicare automată multiregională. SDK suportă Android, iOS, Web (JavaScript), Flutter, Kotlin Multiplatform și Unity.

Evoluția de la Realtime Database

Firestore a fost anunțat la Google I/O 2017 ca „Cloud Firestore” — o soluție care elimină limitările cheie ale Realtime Database: lipsa suportului pentru interogări complexe, imposibilitatea scalării datelor pe mai multe noduri și consistența slabă. Conform datelor Google (2026), Firestore procesează peste 1 trilion de interogări pe zi și este baza de date implicită pentru 80% din noile proiecte Firebase. Cu toate acestea, Realtime Database rămâne relevantă pentru scenarii cu latență ultra-scăzută (jocuri, editare colaborativă) datorită structurii JSON simple.

Limitele gratuite ale Firestore

Firestore este oferit în modelul pay-as-you-go cu o limită gratuită generoasă la tariful Spark: 1 GB de stocare, 10 GB de trafic de rețea pe lună, 50 de mii de operații de citire, 20 de mii de operații de scriere și 20 de mii de operații de ștergere pe zi. La tariful Blaze toate acestea sunt gratuite, iar depășirile sunt tarifate: $0.06 la 100 de mii de operații de citire, $0.18 la 100 de mii de operații de scriere. Conform datelor Google (2026), 90% din proiecte nu depășesc limita gratuită.

Modelul de date: colecții, documente și câmpuri

Modelul de date Firestore este organizat ierarhic: rădăcina conține colecții, fiecare colecție conține documente, fiecare document conține câmpuri (tipuri primitive, array-uri, Map) și colecții imbricate (subcollections). Adâncimea de imbricare a colecțiilor nu este limitată, dar un document nu poate conține direct un alt document — doar prin referință (Reference type).

Colecții și documente

Colecția este un container de documente cu identificatori generați automat sau specificați. Fiecare document este un obiect asemănător JSON de dimensiune de până la 1 MiB. Câmpurile documentului pot fi șiruri de caractere, numere, valori booleene, array-uri, Map, marcaje de timp (Timestamp), puncte geografice (GeoPoint) și referințe către alte documente (Reference). Dimensiunea documentului este limitată la 1 MiB, inclusiv numele tuturor câmpurilor.

Scrierea în lot și tranzacțiile

Firestore suportă tranzacții atomice la nivelul bazei de date. O tranzacție poate citi și scrie mai multe documente — Commit aplică atomic toate modificările sau niciuna. Maximum 500 de operații per tranzacție, timeout de 60 de secunde. Scrierea în lot (batch write) este o operație atomică netranzacțională de scriere fără etapa de citire. Tranzacțiile sunt critice pentru operații financiare, rezervări de locuri și inventariere.

Comparație între Firestore și Realtime Database

Alegerea între Firestore și Realtime Database depinde de cerințele proiectului. Ambele baze de date fac parte din ecosistemul Firebase, oferă sincronizare în timp real și sunt disponibile pe toate platformele, dar diferă fundamental prin modelul de date, scalare și prețuri.

Diferențe cheie

Realtime Database stochează datele într-un singur arbore JSON, ceea ce este convenabil pentru structuri simple, dar îngreunează scalarea la o imbricare mai profundă de 3 niveluri. Firestore folosește modelul colecție-document cu shardare automată, permițând scalarea până la milioane de documente fără degradarea performanței. Conform datelor Google (2026), Firestore suportă până la 10 mii de conexiuni simultane la o singură colecție fără pierdere de viteză, Realtime Database — până la 200 de mii de conexiuni la o singură instanță.

Prețuri

Realtime Database este tarifată în funcție de volumul de date transferate (octeți descărcați) și numărul de conexiuni simultane. Firestore — în funcție de numărul de operații (citire, scriere, ștergere). Pentru aplicații cu actualizări mici frecvente (chat, notificări) Firestore este de obicei mai avantajos — fiecare operație de scriere are un preț fix indiferent de dimensiunea datelor. Pentru aplicații cu citiri rare ale unor volume mari de date, Realtime Database poate fi mai ieftină.

Recomandarea Google (2026): utilizați Firestore ca bază de date implicită pentru proiecte noi, iar Realtime Database — pentru jocuri și aplicații unde latența minimă (sub 50 ms) este critică și structura datelor este plată. Ambele baze de date pot funcționa simultan într-un singur proiect.

Interogări, indecși și paginare în Firestore

Interogările Firestore sunt executate pe colecții sau grupuri de colecții cu filtrare, sortare și limită. Spre deosebire de Realtime Database, unde fiecare interogare este o parcurgere a întregului arbore JSON cu filtru pe client, Firestore execută toate interogările pe server, folosind indecși pre-creați. Aceasta garantează că complexitatea interogării depinde doar de dimensiunea rezultatului, nu de dimensiunea colecției.

Tipuri de interogări

Firestore suportă filtrarea după unul sau mai multe câmpuri (equality, range, in, array-contains, array-contains-any), sortare ascendentă și descendentă, limită și cursoare pentru paginare. Limitări: interogările compuse cu filtrare după câmpuri diferite (where price > 10 AND where category == „books”) necesită un index compus; interogările OR sunt interzise (se folosește in și array-contains-any) și interogările cu inegalitate pe câmpuri diferite sunt interzise.

data class Product(
    val name: String = "",
    val category: String = "",
    val price: Double = 0.0,
    val inStock: Boolean = false
)

suspend fun FirestoreRepository.queryProducts(): List<Product> {
    return firestore
        .collection("products")
        .whereEqualTo("category", "electronics")
        .whereGreaterThanOrEqualTo("price", 100.0)
        .whereLessThan("price", 500.0)
        .orderBy("price")
        .limit(20)
        .get()
        .await()
        .toObjects(Product::class.java)
}

Indecși automati și compuși

Firestore creează automat indecși pentru câmpuri individuale — interogările după un singur câmp funcționează fără nicio configurare. Pentru interogări cu două sau mai multe câmpuri (filtrare + sortare) se creează indecși compuși. La prima trimitere a interogării, Firestore returnează o eroare cu un link către consolă, unde se poate crea indexul cu un singur clic. Maximum 200 de indecși compuși per bază de date. Indecșii pot fi exportați și importați prin firebase CLI.

Integrarea Firestore în Android

Conectarea Firestore la o aplicație Android se face standard prin Firebase BOM. După adăugarea dependenței firebase-firestore-ktx, obiectul FirebaseFirestore este disponibil prin getInstance() — fără chei sau tokenuri suplimentare. Firestore folosește același proiect Firebase ca și celelalte servicii.

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

// Inițializare
val db = FirebaseFirestore.getInstance()

Citirea și scrierea datelor

Firestore oferă două moduri de citire: o singură dată (get) și în timp real (addSnapshotListener). Citirea o singură dată obține documentul o dată — util pentru setări și configurare. Listenerul se abonează la modificări — orice actualizare a documentului livrează automat datele actualizate tuturor clienților conectați în timp real. set() creează sau suprascrie un document, update() modifică doar câmpurile specificate fără a suprascrie întregul document.

Conform datelor Google (2026), aplicațiile de dimensiune medie (100 de mii de DAU) cu Firestore în timp real consumă aproximativ 5-10 GB de trafic de ieșire pe lună. Utilizarea cache-ului offline (Persistence Cache) reduce volumul încărcărilor repetate cu 60-70%, deoarece SDK încarcă doar documentele modificate la restabilirea conexiunii.

Modul offline

Persistence Cache este un mecanism încorporat al Firestore pentru lucrul fără internet. SDK cache-uiște automat toate documentele citite pe dispozitiv (până la 500 MiB pe Android). La pierderea conexiunii, citirea continuă din cache, scrierea este pusă în coadă. La restabilirea conexiunii, toate operațiile amânate sunt trimise pe server, iar cache-ul este sincronizat cu serverul. Pentru controlul conflictelor se folosesc snapshot-metadata.hasPendingWrites și setOptions(ServerTimestampBehavior).

Reguli de securitate și validare a datelor

Security Rules este un limbaj declarativ de restricționare a accesului la Firestore, executat pe serverul Google înainte de fiecare operație de citire sau scriere. Rules nu necesită cod de server — se scriu în consola Firebase sau prin firebase CLI și se versionază prin Git. Fiecare operație este verificată pentru conformitatea cu regulile, iar la încălcare se returnează eroarea PERMISSION_DENIED.

Structura regulilor

Regulile Firestore Security Rules constau în blocuri match și expresii allow. match definește calea către colecție sau document, allow specifică operațiile permise (read, write, create, update, delete) și condiția — o expresie asemănătoare JavaScript care returnează o valoare booleană. Regulile pot verifica autentificarea (request.auth), datele cererii (request.resource.data), datele existente (resource.data), timpul (request.time) și calea (request.path).

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if request.auth != null;
      allow write: if request.auth.uid == userId;
    }

    match /products/{productId} {
      allow read: if true;
      allow create: if request.auth.token.role == "admin";
      allow update: if resource.data.authorId == request.auth.uid;
    }
  }
}

Validarea datelor

Security Rules suportă validarea tipurilor și valorilor pe partea de server. Se poate interzice scrierea dacă prețul este negativ sau numele este gol. Toate verificările sunt executate pe serverul Google înainte de scriere — aceasta garantează consistența datelor indiferent de client (Android, iOS, Web, Admin SDK). Rules nu protejează împotriva Admin SDK rău intenționat — prin definiție, acesta ocolește regulile. Pentru protecție completă, utilizați Transaction Functions și Firebase Extensions.