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 данные organised в иерархическую структуру. Коллекция — это контейнер документов, аналогичный таблице в SQL, но без фиксированной схемы. Документ — это запись, содержащая поля различных типов: строки, числа, булевы значения, массивы, вложенные объекты и геоточки. Документы могут содержать подколлекции, что позволяет строить вложенные структуры данных любой глубины.

val db = FirebaseFirestore.getInstance()

val user = hashMapOf(
    "name" to "Анна Петрова",
    "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 автоматически синхронизирует изменения между всеми клиентами: если задачу добавляет один пользователь, остальные видят её в реальном времени без перезагрузки экрана.