Firebase Firestore — ano ito, mga dokumento at NoSQL koleksyon

Ano ang Firebase Firestore

Firebase Firestore ay isang cloud NoSQL database na inilunsad ng Google noong 2019 bilang kapalit ng Realtime Database. Ang Firestore ay binuo sa imprastraktura ng Google Cloud Spanner at Google Cloud Datastore, na nagbibigay ng mahigpit na pagkakapare-pareho ng data sa loob ng isang transaksyon at awtomatikong multi-regional na replikasyon. Sinusuportahan ng SDK ang Android, iOS, Web (JavaScript), Flutter, Kotlin Multiplatform, at Unity.

Ebolusyon mula sa Realtime Database

Ang Firestore ay inanunsyo sa Google I/O 2017 bilang “Cloud Firestore” — isang solusyon na nag-aalis ng mga pangunahing limitasyon ng Realtime Database: kakulangan ng suporta para sa mga kumplikadong query, kawalan ng kakayahang mag-scale ng data sa maraming node, at mahinang pagkakapare-pareho. Ayon sa data ng Google (2026), ang Firestore ay nagpoproseso ng higit sa 1 trilyong query bawat araw at ito ang default na database para sa 80% ng mga bagong Firebase project. Gayunpaman, ang Realtime Database ay nananatiling may kaugnayan para sa mga senaryo na may ultra-mababang latency (mga laro, collaborative editing) dahil sa simpleng JSON structure nito.

Mga libreng limitasyon ng Firestore

Firestore ay inaalok sa modelong pay-as-you-go na may mapagbigay na libreng limitasyon sa Spark plan: 1 GB storage, 10 GB network traffic bawat buwan, 50 libong read operations, 20 libong write operations, at 20 libong delete operations bawat araw. Sa Blaze plan lahat ay parehong libre, at ang sobra ay may bayad: $0.06 bawat 100 libong read operations, $0.18 bawat 100 libong write operations. Ayon sa data ng Google (2026), 90% ng mga project ay hindi lumalampas sa libreng limitasyon.

Modelo ng data: mga koleksyon, dokumento, at field

Ang modelo ng data ng Firestore ay naka-organisa nang hierarchical: ang root ay naglalaman ng mga koleksyon, bawat koleksyon ay naglalaman ng mga dokumento, bawat dokumento ay naglalaman ng mga field (primitive types, arrays, Map) at mga nested na koleksyon (subcollections). Ang lalim ng nesting ng mga koleksyon ay hindi limitado, ngunit ang isang dokumento ay hindi maaaring direktang maglaman ng isa pang dokumento — sa pamamagitan lamang ng referensya (Reference type).

Mga koleksyon at dokumento

Ang koleksyon ay isang lalagyan ng mga dokumento na may awtomatikong binuo o itinakdang mga identifier. Ang bawat dokumento ay isang JSON-like na bagay na may sukat hanggang 1 MiB. Ang mga field ng dokumento ay maaaring mga string, numero, boolean value, array, Map, timestamp (Timestamp), geographic point (GeoPoint), at referensya sa ibang mga dokumento (Reference). Ang laki ng dokumento ay limitado sa 1 MiB, kasama ang mga pangalan ng lahat ng field.

Batch write at mga transaksyon

Firestore ay sumusuporta sa atomic transaksyon sa antas ng database. Ang isang transaksyon ay maaaring magbasa at magsulat ng maraming dokumento — ang Commit ay atomic na nag-aplay ng lahat ng pagbabago o wala. Maximum na 500 operations bawat transaksyon, timeout na 60 segundo. Ang batch write ay isang non-transactional atomic write operation na walang reading stage. Ang mga transaksyon ay kritikal para sa financial operations, booking ng lugar, at inventory.

Paghahambing ng Firestore at Realtime Database

Ang pagpili sa pagitan ng Firestore at Realtime Database ay depende sa mga kinakailangan ng project. Ang parehong database ay bahagi ng Firebase ecosystem, nagbibigay ng real-time na pag-sync, at available sa lahat ng platform, ngunit pangunahing nagkakaiba sa modelo ng data, pag-scale, at pagpepresyo.

Mga pangunahing pagkakaiba

Ang Realtime Database ay nag-iimbak ng data sa isang JSON tree, na maginhawa para sa mga simpleng structure, ngunit nagpapahirap sa pag-scale sa nesting na mas malalim sa 3 levels. Ang Firestore ay gumagamit ng collection-document model na may awtomatikong sharding, na nagpapahintulot sa pag-scale hanggang milyong dokumento nang walang pagbaba ng performance. Ayon sa data ng Google (2026), ang Firestore ay sumusuporta ng hanggang 10 libong sabay-sabay na koneksyon sa isang koleksyon nang walang pagkawala ng bilis, ang Realtime Database — hanggang 200 libong koneksyon sa isang instance.

Pagpepresyo

Ang Realtime Database ay may bayad batay sa dami ng nailipat na data (na-download na bytes) at bilang ng sabay-sabay na koneksyon. Ang Firestore — batay sa bilang ng operations (read, write, delete). Para sa mga application na may madalas na maliit na update (chat, notification), ang Firestore ay karaniwang mas matipid — bawat write operation ay may nakapirming presyo anuman ang laki ng data. Para sa mga application na may bihirang pagbasa ng malaking volume ng data, ang Realtime Database ay maaaring mas mura.

Rekomendasyon ng Google (2026): gamitin ang Firestore bilang default na database para sa mga bagong project, at ang Realtime Database — para sa mga laro at application kung saan ang minimal na latency (mas mababa sa 50 ms) ay kritikal at ang structure ng data ay flat. Ang parehong database ay maaaring gumana nang sabay sa isang project.

Mga query, index, at pagination sa Firestore

Ang mga query sa Firestore ay isinasagawa sa mga koleksyon o grupo ng mga koleksyon na may filtering, sorting, at limit. Hindi tulad ng Realtime Database, kung saan ang bawat query ay pag-ikot sa buong JSON tree na may filter sa client side, ang Firestore ay nagsasagawa ng lahat ng query sa server, gamit ang pre-created na mga index. Ito ay ginagarantiyahan na ang complexity ng query ay depende lamang sa laki ng resulta, hindi sa laki ng koleksyon.

Mga uri ng query

Sinusuportahan ng Firestore ang pag-filter sa isa o maraming field (equality, range, in, array-contains, array-contains-any), pag-uuri pataas at pababa, limit, at cursor para sa pagination. Mga limitasyon: ang compound query na may pag-filter sa iba't ibang field (where price > 10 AND where category == “books”) ay nangangailangan ng compound index; ang OR query ay ipinagbabawal (ginagamit ang in at array-contains-any) at ang mga query na may inequality sa iba't ibang field ay ipinagbabawal.

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

Awtomatiko at compound na mga index

Ang Firestore ay awtomatikong gumagawa ng mga index para sa mga indibidwal na field — ang mga query sa isang field ay gumagana nang walang anumang configuration. Para sa mga query na may dalawa o higit pang field (filter + sort), ginagawa ang mga compound index. Sa unang pagpapadala ng query, ang Firestore ay nagbabalik ng error na may link sa console, kung saan maaaring gawin ang index sa isang click. Maximum na 200 compound index bawat database. Ang mga index ay maaaring i-export at i-import sa pamamagitan ng firebase CLI.

Pagsasama ng Firestore sa Android

Ang pagkonekta ng Firestore sa Android application ay ginagawa nang standard sa pamamagitan ng Firebase BOM. Pagkatapos idagdag ang dependency na firebase-firestore-ktx, ang FirebaseFirestore object ay available sa pamamagitan ng getInstance() — nang walang karagdagang key o token. Ang Firestore ay gumagamit ng parehong Firebase project gaya ng iba pang serbisyo.

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

// Initialisasyon
val db = FirebaseFirestore.getInstance()

Pagbasa at pagsulat ng data

Ang Firestore ay nagbibigay ng dalawang mode ng pagbasa: isang beses (get) at real-time (addSnapshotListener). Ang isang beses na pagbasa ay kumukuha ng dokumento nang isang beses — kapaki-pakinabang para sa mga setting at configuration. Ang listener ay nag-subscribe sa mga pagbabago — anumang update ng dokumento ay awtomatikong naghahatid ng updated na data sa lahat ng konektadong kliyente sa real-time. Ang set() ay gumagawa o nag-overwrite ng dokumento, ang update() ay nagbabago lamang ng mga tinukoy na field nang hindi na-o-overwrite ang buong dokumento.

Ayon sa data ng Google (2026), ang mga medium-sized na application (100 libong DAU) na may Firestore sa real-time ay kumukonsumo ng humigit-kumulang 5-10 GB ng outgoing traffic bawat buwan. Ang paggamit ng offline cache (Persistence Cache) ay nagbabawas ng dami ng paulit-ulit na pag-download ng 60-70%, dahil ang SDK ay nagda-download lamang ng mga binagong dokumento kapag naibalik ang koneksyon.

Offline mode

Ang Persistence Cache ay isang built-in na mekanismo ng Firestore para sa pagtatrabaho nang walang internet. Awtomatikong nini-cache ng SDK ang lahat ng binasang dokumento sa device (hanggang 500 MiB sa Android). Kapag nawala ang koneksyon, ang pagbasa ay nagpapatuloy mula sa cache, ang pagsulat ay naka-queue. Kapag naibalik ang koneksyon, lahat ng deferred operations ay ipinapadala sa server, at ang cache ay nagsi-sync sa server. Para sa pagkontrol ng conflict, ginagamit ang snapshot-metadata.hasPendingWrites at setOptions(ServerTimestampBehavior).

Mga panuntunan sa seguridad at pag-validate ng data

Ang Security Rules ay isang deklaratibong wika para sa paghihigpit ng access sa Firestore, na isinasagawa sa Google server bago ang bawat read o write operation. Ang Rules ay hindi nangangailangan ng server code — isinusulat ang mga ito sa Firebase console o sa pamamagitan ng firebase CLI at na-version sa pamamagitan ng Git. Ang bawat operasyon ay sinusuri para sa pagsunod sa mga panuntunan, at sa paglabag, isang PERMISSION_DENIED error ang ibinabalik.

Structure ng mga panuntunan

Ang mga panuntunan ng Firestore Security Rules ay binubuo ng mga match block at allow expression. Ang match ay tumutukoy sa path patungo sa koleksyon o dokumento, ang allow ay tumutukoy sa mga pinapayagang operasyon (read, write, create, update, delete) at kondisyon — isang JavaScript-like expression na nagbabalik ng boolean value. Ang mga panuntunan ay maaaring suriin ang authentication (request.auth), data ng request (request.resource.data), umiiral na data (resource.data), oras (request.time), at path (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;
    }
  }
}

Pag-validate ng data

Sinusuportahan ng Security Rules ang pag-validate ng mga type at value sa server side. Maaaring ipagbawal ang pagsulat kung ang presyo ay negatibo o ang pangalan ay blangko. Lahat ng pagsusuri ay isinasagawa sa Google server bago ang pagsulat — ito ay ginagarantiyahan ang pagkakapare-pareho ng data anuman ang kliyente (Android, iOS, Web, Admin SDK). Ang Rules ay hindi nagpoprotekta laban sa malisyosong Admin SDK — sa kahulugan, nilalampasan nito ang mga panuntunan. Para sa kumpletong proteksyon, gamitin ang Transaction Functions at Firebase Extensions.