Firebase Firestore — какво е, документи и NoSQL колекции

Какво е Firebase Firestore

Firebase Firestore е облачна NoSQL база данни, пусната от Google през 2019 г. като наследник на Realtime Database. Firestore е изграден върху инфраструктурата на Google Cloud Spanner и Google Cloud Datastore, осигурявайки строга консистентност на данните в рамките на една транзакция и автоматична мултирегионална репликация. SDK поддържа Android, iOS, Web (JavaScript), Flutter, Kotlin Multiplatform и Unity.

Еволюция от Realtime Database

Firestore беше обявен на Google I/O 2017 като „Cloud Firestore” — решение, което премахва ключовите ограничения на Realtime Database: липса на поддръжка за сложни заявки, невъзможност за мащабиране на данни на множество възли и слаба консистентност. Според данни на Google (2026) Firestore обработва над 1 трилион заявки на ден и е базата данни по подразбиране за 80% от новите Firebase проекти. Въпреки това Realtime Database остава актуален за сценарии с ултра-ниска латентност (игри, съвместно редактиране) благодарение на простата JSON структура.

Безплатни лимити на Firestore

Firestore се предлага по модела pay-as-you-go с щедър безплатен лимит на тарифа Spark: 1 GB хранилище, 10 GB мрежов трафик на месец, 50 хиляди операции за четене, 20 хиляди операции за запис и 20 хиляди операции за изтриване на ден. На тарифа Blaze всичко е също безплатно, а превишенията се таксуват: $0.06 на 100 хиляди операции за четене, $0.18 на 100 хиляди операции за запис. Според данни на Google (2026) 90% от проектите не излизат извън безплатния лимит.

Модел на данни: колекции, документи и полета

Моделът на данни на Firestore е организиран йерархично: коренът съдържа колекции, всяка колекция съдържа документи, всеки документ съдържа полета (примитивни типове, масиви, Map) и вложени колекции (subcollections). Дълбочината на влагане на колекциите не е ограничена, но документ не може директно да съдържа друг документ — само чрез референция (Reference type).

Колекции и документи

Колекцията е контейнер за документи с автоматично генерирани или зададени идентификатори. Всеки документ е JSON-подобен обект с размер до 1 MiB. Полетата на документа могат да бъдат низове, числа, булеви стойности, масиви, Map, времеви отпечатъци (Timestamp), географски точки (GeoPoint) и референции към други документи (Reference). Размерът на документа е ограничен до 1 MiB, включително имената на всички полета.

Пакетен запис и транзакции

Firestore поддържа атомарни транзакции на ниво база данни. Транзакция може да чете и пише множество документи — Commit атомарно прилага всички промени или нито една. Максимум 500 операции на транзакция, таймаут 60 секунди. Пакетният запис (batch write) е нетранзакционна атомарна операция за запис без фаза на четене. Транзакциите са критични за финансови операции, резервации на места и инвентаризация.

Сравнение на Firestore и Realtime Database

Изборът между Firestore и Realtime Database зависи от изискванията на проекта. И двете бази данни са част от екосистемата на Firebase, предоставят синхронизация в реално време и са достъпни на всички платформи, но се различават фундаментално по модел на данни, мащабиране и ценообразуване.

Ключови разлики

Realtime Database съхранява данни в едно JSON дърво, което е удобно за прости структури, но затруднява мащабирането при влагане по-дълбоко от 3 нива. Firestore използва колекционно-документен модел с автоматично шардиране, което позволява мащабиране до милиони документи без влошаване на производителността. Според данни на Google (2026) Firestore поддържа до 10 хиляди едновременни връзки към една колекция без загуба на скорост, Realtime Database — до 200 хиляди връзки към една инстанция.

Ценообразуване

Realtime Database се таксува според обема на предадените данни (изтеглени байтове) и броя на едновременните връзки. Firestore — според броя операции (четене, запис, изтриване). За приложения с чести малки актуализации (чат, известия) Firestore обикновено е по-изгоден — всяка операция за запис има фиксирана цена независимо от размера на данните. За приложения с редки четения на големи обеми данни Realtime Database може да бъде по-евтин.

Препоръка на Google (2026): използвайте Firestore като база данни по подразбиране за нови проекти, а Realtime Database — за игри и приложения, където минималната латентност (под 50 ms) е критична и структурата на данните е плоска. И двете бази данни могат да работят едновременно в един проект.

Заявки, индекси и пагинация в Firestore

Заявките на Firestore се изпълняват върху колекции или групи от колекции с филтриране, сортиране и лимит. За разлика от Realtime Database, където всяка заявка е обхождане на цялото JSON дърво с филър от страна на клиента, Firestore изпълнява всички заявки на сървъра, използвайки предварително създадени индекси. Това гарантира, че сложността на заявката зависи само от размера на резултата, а не от размера на колекцията.

Видове заявки

Firestore поддържа филтриране по едно или няколко полета (equality, range, in, array-contains, array-contains-any), сортиране възходящо и низходящо, лимит и курсори за пагинация. Ограничения: съставни заявки с филтриране по различни полета (where price > 10 AND where category == „books”) изискват съставен индекс; OR заявките са забранени (използва се in и array-contains-any) и заявки с неравенство по различни полета са забранени.

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

Автоматични и съставни индекси

Firestore автоматично създава индекси за отделни полета — заявките по едно поле работят без никаква конфигурация. За заявки с две или повече полета (филтриране + сортиране) се създават съставни индекси. При първото изпращане на заявка Firestore връща грешка с връзка към конзолата, където индексът може да бъде създаден с едно кликване. Максимум 200 съставни индекса на база данни. Индексите могат да бъдат експортирани и импортирани чрез firebase CLI.

Интегриране на Firestore в Android

Свързването на Firestore към Android приложение се извършва стандартно чрез Firebase BOM. След добавяне на зависимостта firebase-firestore-ktx обектът FirebaseFirestore е достъпен чрез getInstance() — без допълнителни ключове или токени. Firestore използва същия Firebase проект като останалите услуги.

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

// Инициализиране
val db = FirebaseFirestore.getInstance()

Четене и запис на данни

Firestore предоставя два режима на четене: еднократно (get) и в реално време (addSnapshotListener). Еднократното четене получава документа веднъж — полезно за настройки и конфигурация. Слушателят се абонира за промени — всяка актуализация на документа автоматично доставя актуализираните данни до всички свързани клиенти в реално време. set() създава или презаписва документ, update() променя само указаните полета без презаписване на целия документ.

Според данни на Google (2026) приложения със среден размер (100 хиляди DAU) с Firestore в реално време консумират около 5-10 GB изходящ трафик на месец. Използването на офлайн кеш (Persistence Cache) намалява обема на повторните изтегляния с 60-70%, тъй като SDK изтегля само променените документи при възстановяване на връзката.

Офлайн режим

Persistence Cache е вграден механизъм на Firestore за работа без интернет. SDK автоматично кешира всички прочетени документи на устройството (до 500 MiB на Android). При загуба на връзка четенето продължава от кеша, записът се поставя на опашка. При възстановяване на връзката всички отложени операции се изпращат на сървъра и кешът се синхронизира със сървъра. За контрол на конфликтите се използват snapshot-metadata.hasPendingWrites и setOptions(ServerTimestampBehavior).

Правила за сигурност и валидиране на данни

Security Rules е декларативен език за ограничаване на достъпа до Firestore, който се изпълнява на сървъра на Google преди всяка операция за четене или запис. Rules не изискват сървърен код — пишат се в конзолата на Firebase или чрез firebase CLI и се версионират чрез Git. Всяка операция се проверява за съответствие с правилата и при нарушение се връща грешка PERMISSION_DENIED.

Структура на правилата

Правилата на Firestore Security Rules се състоят от match блокове и allow изрази. match определя пътя до колекцията или документа, allow указва разрешените операции (read, write, create, update, delete) и условието — израз, подобен на JavaScript, който връща булева стойност. Правилата могат да проверяват удостоверяване (request.auth), данни на заявката (request.resource.data), съществуващи данни (resource.data), време (request.time) и път (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;
    }
  }
}

Валидиране на данни

Security Rules поддържат валидиране на типове и стойности от страна на сървъра. Може да се забрани запис, ако цената е отрицателна или името е празно. Всички проверки се извършват на сървъра на Google преди запис — това гарантира консистентност на данните независимо от клиента (Android, iOS, Web, Admin SDK). Rules не защитават от злонамерен Admin SDK — той по дефиниция заобикаля правилата. За пълна защита използвайте Transaction Functions и Firebase Extensions.