Firebase Firestore: що це таке, NoSQL та як працює

Що таке Firebase Firestore?

Firebase Firestore — це гнучка масштабована NoSQL база даних, запущена Google у 2019 році як еволюція Firebase Realtime Database. Вона зберігає дані у вигляді колекцій документів, де кожен документ містить набір пар ключ-значення. На відміну від традиційних реляційних баз, Firestore не вимагає заздалегідь визначеної схеми — структура даних формується динамічно на основі записуваних документів.

Ключова відмінність Firestore від класичних хмарних баз — вбудована синхронізація реального часу. Коли дані змінюються на сервері, всі підключені клієнти отримують оновлення через постійне WebSocket-з'єднання. Це усуває необхідність у ручному опитуванні сервера та дозволяє будувати додатки з живими оновленнями: чати, стрічки активності, спільні редактори та системи моніторингу.

База даних доступна на всіх основних платформах: Android, iOS, Web (JavaScript) та серверних мовах через Admin SDK. Firestore надає SDK для Swift, Kotlin, JavaScript, Python, Go, Java та Node.js. За даними Google, Firestore обробляє понад 100 мільярдів запитів на день по всій екосистемі Firebase, що підтверджує її надійність як основи для production-додатків.

Основні поняття: колекції та документи

У Firestore дані організовані в ієрархічну структуру. Колекція — це контейнер документів, аналогічний таблиці в SQL, але без фіксованої схеми. Документ — це запис, що містить поля різних типів: рядки, числа, булеві значення, масиви, вкладені об'єкти та геоточки. Документи можуть містити підколекції, що дозволяє будувати вкладені структури даних будь-якої глибини.

val db = FirebaseFirestore.getInstance()

val user = hashMapOf(
    "name" to "Anna Petrova",
    "email" to "anna@example.com",
    "age" to 28,
    "isActive" to true
)

db.collection("users")
    .add(user)
    .addOnSuccessListener { docRef ->
        Log.d("TAG", "Документ додано з ID: ${docRef.id}")
    }

Кожен документ у колекції має унікальний ідентифікатор, який може бути згенерований автоматично або заданий вручну. Firestore автоматично індексує всі поля документа, що дозволяє виконувати складні запити з фільтрацією, сортуванням та обмеженням кількості результатів без попереднього налаштування індексів.

Firebase Firestore vs Realtime Database: порівняння

Firestore та Firebase Realtime Database — це дві хмарні бази даних реального часу від Google. Хоча обидві надають синхронізацію в реальному часі, вони мають принципові відмінності в моделі даних, масштабуванні та ціноутворенні. Розуміння цих відмінностей критично важливе при виборі відповідної бази для конкретного проекту.

Основна архітектурна відмінність — модель даних. Realtime Database зберігає все в одному великому JSON-дереві, що ускладнює запити з глибокою вкладеністю. Firestore використовує колекції та документи, що дозволяє виконувати складні запити з кількома умовами. Крім того, Firestore забезпечує сильну узгодженість даних: після успішного запису всі наступні читання гарантовано повертають актуальні дані.

Масштабованість та структура даних

Firestore масштабується автоматично до мільйонів одночасних підключень завдяки мультирегіональній архітектурі. Realtime Database обмежена одним регіоном і максимум 200 000 одночасних з'єднань. Для проектів, які планують глобальну аудиторію, Firestore кращий, оскільки дані автоматично реплікуються між кількома дата-центрами Google.

Структура даних у Firestore дозволяє будувати складні ієрархічні моделі з підколекціями. Наприклад, у користувача може бути підколекція «замовлення», а в кожного замовлення — підколекція «товари». У Realtime Database така глибока вкладеність призводить до проблем продуктивності при запитах, оскільки завантажується весь шлях від кореня до потрібного вузла.

Як працює синхронізація даних у Firestore

Firestore використовує постійне WebSocket-з'єднання між клієнтом і сервером для синхронізації даних у реальному часі. Коли додаток підписується на зміни документа або колекції через snapshot listener, SDK встановлює канал зв'язку, по якому сервер надсилає оновлення при кожній зміні даних. Клієнт отримує тільки змінені документи, а не повний знімок всієї колекції щоразу.

Механізм синхронізації заснований на потоці подій: added (документ з'явився), modified (документ змінився) та removed (документ видалено). Розробник може обробляти кожну подію окремо, оновлюючи тільки відповідні елементи UI. Це забезпечує високу продуктивність навіть при тисячах документів, оскільки перемальовуються тільки змінені компоненти.

Офлайн-доступ та кешування

Одна з ключових переваг Firestore — вбудована підтримка офлайн-режиму. SDK автоматично кешує всі зчитані дані на пристрої та продовжує працювати при відсутності мережі. Коли додаток записує дані в офлайн-режимі, вони поміщаються в локальну чергу та надсилаються на сервер при відновленні з'єднання. Для вирішення конфліктів використовується стратегія last-write-wins.

val docRef = db.collection("cities").document("SF")

docRef.addSnapshotListener { snapshot, error ->
    if (error != null) {
        Log.w("TAG", "Помилка прослуховування", error)
        return@addSnapshotListener
    }

    if (snapshot != null && snapshot.exists()) {
        Log.d("TAG", "Поточні дані: ${snapshot.data}")
    }
}

Розмір кешу можна налаштувати через FirestoreSettings. За замовчуванням використовується значення 100 MB, але для додатків з інтенсивним читанням даних його можна збільшити. Також доступний режим persistent disk cache, який переживає перезапуск додатка. Для керування доступністю офлайн-режиму використовуються методи enableNetwork та disableNetwork, що дозволяють тимчасово вимикати мережеву взаємодію.

Безпека та правила доступу Firestore

Firestore Security Rules — це декларативна мова розмітки для контролю доступу до даних на рівні сервера. Правила визначають, хто і за яких умов може читати та записувати документи. Вони працюють до виконання запиту та не вимагають окремої серверної логіки для авторизації. Правила перевіряються на стороні Firebase перед кожним читанням або записом даних.

Правила доступу будуються за принципом дозволеного доступу (allow). За замовчуванням весь доступ заборонено. Розробник послідовно відкриває доступ для конкретних операцій (read, write, create, update, delete) за певних умов. Умови можуть перевіряти аутентифікацію користувача через request.auth, дані запиту через request.resource та існуючі дані через resource.

// Правила доступу Firestore
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Користувач читає та пише тільки свої дані
    match /users/{userId} {
      allow read, write: if
          request.auth != null &&
          request.auth.uid == userId;
    }

    // Будь-який аутентифікований може читати пости
    match /posts/{postId} {
      allow read: if request.auth != null;
      allow create: if request.auth != null
          && request.resource.data.author == request.auth.uid;
    }
  }
}

Валідація даних через правила

Окрім контролю доступу, Security Rules дозволяють валідувати структуру та типи записуваних даних. Наприклад, можна перевірити, що поле email відповідає регулярному виразу, або що вік не перевищує 120 років. Валідація виконується до запису, що запобігає збереженню некоректних даних на сервері. Для перевірки полів використовується об'єкт request.resource.data, що містить документ, який записується повністю.

Firestore також підтримує колекції, доступні тільки для серверного запису через Admin SDK, без доступу з боку клієнтів. Це зручно для зберігання службової інформації, ключів API та конфігурацій, які не повинні бути видні користувачам. Для цього в правилах достатньо заборонити всі клієнтські операції на відповідних колекціях, дозволивши доступ тільки через Admin SDK із серверної сторони.

Приклад використання Firebase Firestore в Android

Розглянемо приклад інтеграції Firestore в Android-додаток для створення списку завдань (todo). Додаток читатиме завдання в реальному часі, додавати нові та відмічати виконані. Для асинхронної роботи використовуються callback-інтерфейси Firebase та корутини Kotlin.

Налаштування Firebase та додавання залежностей

Перед початком роботи необхідно підключити проект до Firebase через Firebase Console та додати файл google-services.json у модуль додатка. Потім у build.gradle додається залежність firebase-firestore-ktx та плагін google-services. Версія бібліотеки має відповідати актуальній версії BoM Firebase для сумісності всіх компонентів Firebase між собою.

dependencies {
    // Firebase BoM — керування версіями
    implementation platform("com.google.firebase:firebase-bom:33.0.0")
    implementation "com.google.firebase:firebase-firestore-ktx"
    implementation "org.jetbrains.kotlinx:kotlinx-coroutines-play-services:1.9.0"
}

Після налаштування створюється модель даних Task та репозиторій для роботи з Firestore. Модель містить поля id, title, isCompleted та timestamp. Firestore автоматично серіалізує data class у документ, використовуючи імена полів як ключі. Для читання даних використовується snapshot listener, який повертає Flow через розширення snapshotFlow.

data class Task(
    val id: String = "",
    val title: String = "",
    val isCompleted: Boolean = false,
    val createdAt: Timestamp? = null
)

class TaskRepository {
    private val tasksRef = FirebaseFirestore
        .getInstance()
        .collection("tasks")

    fun getTasks(): Flow<List<Task>> = tasksRef
        .orderBy("createdAt", Query.Direction.DESCENDING)
        .snapshotFlow()
        .map { snapshot ->
            snapshot?.toObjects(Task::class.java) ?: emptyList()
        }

    suspend fun addTask(title: String) {
        tasksRef.add(Task(title = title))
    }
}

View-модель підписується на Flow із репозиторія та передає список завдань на UI-рівень. При додаванні нового завдання викликається suspend-функція репозиторія через корутинний scope. Firestore автоматично синхронізує зміни між усіма клієнтами: якщо завдання додає один користувач, інші бачать його в реальному часі без перезавантаження екрана.