Présentation de Firestore en mode natif

Firestore en mode natif comprend deux ensembles d'opérations : les opérations Firestore Core et les opérations Firestore Pipeline.

Les opérations Firestore Core fournissent les fonctionnalités standard de création, de lecture, de mise à jour et de suppression de documents (CRUD), ainsi qu'une prise en charge intégrée des requêtes d'écoute en temps réel et de la persistance hors connexion. Dans cette édition, les index sont facultatifs et ne sont pas créés automatiquement pour les champs uniques. Bien que cela permette d'exécuter des requêtes sans configuration d'index préalable, les requêtes non indexées analyseront par défaut l'ensemble de la collection. Cela peut entraîner une augmentation de la latence et des coûts à mesure que l'ensemble de données augmente.

Les opérations Firestore Pipeline sont une fonctionnalité centrale de l'édition Firestore Enterprise, basée sur un moteur de requête avancé qui élargit considérablement l'éventail des requêtes possibles. Les opérations de pipeline utilisent une syntaxe de requête flexible et une méthode d'indexation distincte dans laquelle les index sont facultatifs et ne sont pas créés automatiquement, ce qui permet des opérations avancées de récupération de données pour les applications.

Fonctionnalités des opérations Firestore Core

Les opérations Core permettent des opérations CRUD standards et des requêtes d'écoute en temps réel. Toutefois, lorsque vous utilisez ces opérations dans l'édition Enterprise, le comportement sous-jacent concernant l'indexation et la facturation change considérablement par rapport à l'édition Standard.

Fonctionnalité et continuité

Les opérations Core conservent la syntaxe de chaînage de méthodes familière (par exemple, .where(), .orderBy()) utilisée dans l'édition Standard. Ces opérations sont compatibles avec les requêtes d'écoute en temps réel et la persistance hors connexion pour les clients Web et mobiles. Il est recommandé d'utiliser ces opérations pour les charges de travail transactionnelles standards, les recherches simples et la migration du code d'application existant.

Indexation personnalisée

Contrairement à l'édition Standard, les opérations Core de l'édition Enterprise ne créent pas automatiquement d'index à champ unique. Les index sont facultatifs et ne sont pas nécessaires pour exécuter une requête. Si un index spécifique est manquant, la requête effectue une analyse complète de la collection. Bien que les requêtes non indexées permettent un prototypage rapide, elles peuvent être plus lentes et plus coûteuses à mesure que l'ensemble de données augmente. Les développeurs doivent créer manuellement des index pour optimiser les performances des requêtes et réduire la consommation d'unités de lecture.

Modèle de facturation (basé sur les unités)

Les unités de lecture sont facturées par tranches de 4 Ko plutôt que par nombre de documents. Une requête non indexée qui analyse une grande collection consomme des unités de lecture en fonction du nombre total d'octets analysés dans tous les documents. Les unités d'écriture sont facturées par tranches de 1 Ko. L'écriture d'un document consomme des unités pour les données, plus des unités supplémentaires pour chaque entrée d'index mise à jour. Contrairement à l'édition Standard, qui applique l'indexation automatique à champ unique, vous pouvez désormais choisir des champs spécifiques à indexer pour optimiser les coûts et les performances d'écriture.

Fonctionnalités des opérations Firestore Pipeline

L'édition Firestore Enterprise avec des opérations de pipeline utilise un moteur de requête avancé qui supprime de nombreuses limites existantes de l'édition Firestore Standard. Les opérations de pipeline offrent des centaines de fonctionnalités de requête supplémentaires. Les opérations de pipeline présentent les fonctionnalités suivantes :

Syntaxe composable basée sur les étapes

Les requêtes de pipeline sont construites en définissant une série d'étapes séquentielles stages qui sont exécutées dans l'ordre. Cela permet des opérations complexes, telles que le filtrage sur le résultat d'une agrégation, ce qui n'était pas possible auparavant.

L'exemple suivant montre une requête de pipeline qui recherche le nombre d'ID de produit uniques consultés au cours du dernier mois :

guard let cutoffDate = Calendar.current.date(byAdding: .month, value: -1, to: Date()) else {
  return
}
let snapshot = try await db.pipeline()
  .collection("productViews")
  .where(Field("viewedAt").greaterThan(cutoffDate.timeIntervalSince1970))
  .aggregate([Field("productId").countDistinct().as("uniqueProductViews")])
  .execute()

Fonctionnalités étendues

La requête de pipeline introduit un grand nombre de nouvelles fonctionnalités, y compris les suivantes :

  • Agrégations : prise en charge de nouvelles fonctions d'agrégation (telles que sum(...), min(...) et count_distinct(...)) combinées à des champs de regroupement arbitraires.
  • Jointures relationnelles : effectuez des jointures côté serveur sur des collections et des sous-collections à l'aide de sous-requêtes corrélées.
  • Filtrage complexe : prise en charge de centaines de fonctions supplémentaires pour exprimer des instructions where(...) arbitrairement complexes, y compris regex_match(...), add(...) et str_contains(...), le tout sans exigences d'index strictes.
  • Lectures partielles / Projections : récupérez des sous-ensembles dynamiques de documents à l'aide de select(...), remove_fields(...) et de nombreuses autres étapes de manipulation de documents.

Pour en savoir plus sur ces fonctionnalités, consultez Interroger des données avec des opérations de pipeline.

Assistance en temps réel et hors connexion

Pour utiliser les fonctionnalités en temps réel et hors connexion, les développeurs peuvent utiliser les opérations Firestore Core dans l'édition Firestore Enterprise.

Intégration des clients et des outils

L'édition Enterprise inclut des fonctionnalités spécialisées pour interagir avec les requêtes de pipeline et les gérer :

  • Explication et profilage des requêtes : vous pouvez utiliser les résultats de l'explication des requêtes pour comprendre le nombre d'unités de lecture ou d'écriture consommées par une requête et analyser son exécution.
  • Insights sur les requêtes : l'édition Enterprise est compatible avec Query Insights, qui vous aide à déterminer où des index peuvent être créés pour améliorer les performances et réduire les coûts en vous offrant une visibilité sur les principales requêtes exécutées sur votre base de données et sur leurs caractéristiques de performances.
  • Nouveaux types d'index : vous pouvez créer des index spécialisés pour l'édition Enterprise, y compris des types d'index tels que les index creux, non creux et uniques. Elle permet également de créer et de modifier des index de recherche vectorielle pour les bases de données Enterprise.

Différences entre l'édition Firestore Standard et l'édition Firestore Enterprise

La principale différence opérationnelle entre les opérations Core et les opérations de pipeline réside dans la gestion de l'indexation, qui affecte directement les performances et les coûts.

Édition Standard – Opérations Core Édition Enterprise – Opérations Core et opérations de pipeline
Exigence d'indexation Les index sont obligatoires pour les requêtes.

Les index pour les champs individuels sont créés automatiquement, tandis que les requêtes plus complexes reposent sur des index composites ou des index de groupe de collections qui doivent être configurés manuellement.

Les index ne sont pas obligatoires et sont donc facultatifs pour les requêtes.

Vous définissez les index selon vos besoins. L'édition Enterprise est également compatible avec un plus large éventail de types d'index, y compris les index non creux/creux et uniques.

Champs indexés Un champ __name__ supplémentaire est automatiquement ajouté aux champs indexés s'il n'est pas déjà présent. __name__ n'est pas automatiquement ajouté aux champs indexés. Vous devez spécifier explicitement __name__ dans les champs indexés s'il est important pour votre application.
Normalisation de l'ordre de tri La clause "order by" de la requête est normalisée en ajoutant des champs d'inégalité et le __name__ champ à la fin (s'il n'est pas déjà présent). Cela garantit un ordre unique et déterministe des résultats, quels que soient les autres champs de la clause "order by". Aucune normalisation de l'ordre de tri. Un ordre de tri tel que sort a ASC garantit uniquement que les résultats sont triés par champ a. Cloud Firestore utilisera vos index existants pour renvoyer les résultats dans l'ordre le plus efficace possible. Par conséquent, si a n'est pas unique dans l'ensemble de résultats, l'ordre des résultats peut varier d'une requête à l'autre en fonction de la configuration de l'index, des stratégies d'exécution, etc. Pour garantir un ordre unique et déterministe des résultats, vous devez ajouter un champ unique tel que __name__ à l'ordre de tri.
Performances Requêtes indexées : les performances et les coûts évoluent en fonction de la taille de votre ensemble de résultats.

Requêtes non indexées : les performances et les coûts évoluent en fonction de la taille de votre ensemble de données.

Requêtes indexées : les performances et les coûts évoluent en fonction de la taille de votre ensemble de résultats.

Nous vous recommandons d'utiliser les outils Query Explain et Insights sur les requêtes pour créer des index et améliorer les performances et les coûts de vos requêtes.

Implication sur les coûts de stockage Vous encourez des frais de stockage supplémentaires liés aux index automatiques et aux index composites. Vous économisez sur les coûts de stockage, car les index ne sont pas créés automatiquement pour chaque champ.
Base de coûts Facturation par opération de lecture, d'écriture et de suppression de document. Facturation par unité de lecture (tranches de 4 Ko) et par unité d'écriture (tranches de 1 Ko). L'écriture d'entrées d'index consomme des unités d'écriture.

Découvrez les nouveaux tarifs avec quelques exemples.

Règles de sécurité Les règles de sécurité protègent les collections en vérifiant les autorisations de lecture/écriture. Les règles de sécurité protègent les collections en vérifiant les autorisations de lecture/écriture. Découvrez comment modéliser vos données pour prendre en charge les requêtes de pipeline dans le guide sur le modèle de données.