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 залишається актуальною для сценаріїв з ultra-low latency (ігри, спільне редагування) завдяки однозначній структурі JSON.

Безкоштовні ліміти Firestore

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

Модель даних: колекції, документи та поля

Модель даних Firestore організована ієрархічно: корінь містить колекції, кожна колекція містить документи, кожен документ містить поля (примітивні типи, масиви, Map) і вкладені колекції (підколекції). Глибина вкладеності колекцій не обмежена, але документ не може містити інший документ безпосередньо — тільки через посилання (Reference type).

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

Колекція — це контейнер документів з автоматично генерованими або задаваними ідентифікаторами. Кожен документ — це JSON-подібний об'єкт розміром до 1 МіБ. Поля документа можуть бути рядками, числами, булевими значеннями, масивами, Map, часовими мітками (Timestamp), геоточками (GeoPoint) і посиланнями на інші документи (Reference). Розмір документа обмежений 1 МіБ, включаючи імена всіх полів.

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

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 мс) і структура даних пласка. Обидві бази можуть працювати одночасно в одному проекті.

Запити, індекси та пагінація в 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 ГБ вихідного трафіку на місяць. Використання офлайн-кешу (Persistence Cache) скорочує обсяг повторних завантажень на 60-70%, оскільки SDK завантажує тільки змінені документи при відновленні з'єднання.

Офлайн-режим

Persistence Cache — вбудований механізм Firestore для роботи без інтернету. SDK автоматично кешує всі прочитані документи на пристрої (до 500 МіБ на 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-подібний вираз, що повертає boolean. Правила можуть перевіряти аутентифікацію (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 — він bypasses правила за визначенням. Для повного захисту використовуйте Transaction Functions та Firebase Extensions.