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) и вложенные коллекции (subcollections). Глубина вложенности коллекций не ограничена, но документ не может содержать другой документ напрямую — только через ссылку (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). Однократное чтение получает документ один раз — полезно для настроек и конфигурации. Слушатель подписывается на изменения — любой update документа автоматически доставляет обновлённые данные всем подключённым клиентам в реальном времени. 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.