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 standards de création, de lecture, de mise à jour et de suppression (CRUD) de documents, ainsi qu'une compatibilité intégrée avec les requêtes d'écoute en temps réel et la persistance hors connexion. Une différence opérationnelle distincte dans cette édition est que 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 analysent par défaut l'intégralité de la collection. Cela peut augmenter la latence et les coûts à mesure que l'ensemble de données s'agrandit.
Les opérations de pipeline Firestore sont une fonctionnalité centrale de l'édition Enterprise de Firestore. Elles reposent sur un moteur de requêtes 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, où les index sont facultatifs et ne sont pas créés automatiquement. Cela permet d'effectuer des opérations de récupération de données avancées pour les applications.
Caractéristiques des opérations Firestore Core
Les opérations de base permettent d'effectuer 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 de base 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 mobiles et Web. Il est recommandé d'utiliser ces opérations pour les charges de travail transactionnelles standards, les recherches simples et la migration de 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 requis 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 s'agrandit. 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, ainsi que des unités supplémentaires pour chaque entrée d'index mise à jour. Contrairement à l'édition Standard, qui applique l'indexation automatique à un seul champ, vous pouvez désormais choisir des champs spécifiques à indexer pour optimiser les coûts d'écriture et les performances.
Fonctionnalités des opérations de pipeline Firestore
L'édition Firestore Enterprise avec 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 fournissent des centaines de fonctionnalités de requête supplémentaires. Les opérations de pipeline offrent 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 qui sont exécutées dans l'ordre. Cela permet d'effectuer 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'identifiants produit uniques consultés au cours du mois dernier :
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()
Capacités étendues
La requête de pipeline introduit un grand nombre de nouvelles fonctionnalités, y compris :
- Agrégations : prise en charge de nouvelles fonctions d'agrégation (comme
sum(...),min(...)etcount_distinct(...)) combinées à des champs de regroupement arbitraires. - Jointures relationnelles : effectuez des jointures côté serveur entre des collections et des sous-collections à l'aide de sous-requêtes corrélées.
- Filtrage complexe : compatibilité avec des centaines de fonctions supplémentaires pour exprimer des instructions
where(...)arbitrairement complexes, y comprisregex_match(...),add(...)etstr_contains(...), 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.
Fonctionnalités 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 du client et des outils
L'édition Enterprise inclut des fonctionnalités spécialisées pour interagir avec les requêtes Pipeline et les gérer :
- Explication et profilage des requêtes : vous pouvez utiliser les résultats de Query Explain 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 les insights sur les requêtes, qui vous aident à déterminer où des index pourraient être créés pour améliorer les performances et réduire les coûts en offrant une visibilité sur les principales requêtes exécutées sur votre base de données et 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. Il 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 Pipeline réside dans la gestion de l'indexation, qui affecte directement les performances et les coûts.
| Édition Standard – Opérations de base | Édition Enterprise : opérations de base et opérations de pipeline | |
| Exigence d'indexation | Les index sont requis pour les requêtes.
Les index des champs individuels sont créés automatiquement, tandis que les requêtes plus complexes s'appuient 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 grand nombre 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 si cela 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 champ __name__ à la fin (s'ils ne sont pas déjà présents). 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 le coût de vos requêtes. |
| Implication sur les coûts de stockage | Les index automatiques et les index composites entraînent des frais de stockage supplémentaires. | Vous réduisez les coûts de stockage, car les index ne sont pas créés automatiquement pour chaque champ. |
| Coût de base | Facturé par opération de lecture, d'écriture et de suppression de document. | Facturé 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 la nouvelle tarification à l'aide de 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 Modèle de données. |