Présentation des interfaces de requête

Cette page décrit les différentes interfaces disponibles pour accéder aux données d'une base de données Firestore en mode natif.

Interfaces d'opération

Le mode natif est compatible avec deux interfaces pour accéder aux données :

Opérations de pipeline

Il s'agit de la nouvelle interface de requête pour Firestore. Les opérations de pipeline sont compatibles avec une syntaxe composable basée sur des étapes. Vous créez une opération 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 dans l'interface d'origine (opérations de base).

Les opérations de pipeline ne sont disponibles que dans l'édition Firestore Enterprise et sont en version preview.

Opérations de base

Les opérations de base sont l'interface d'origine de Firestore. Elles utilisent une syntaxe d'enchaînement de méthodes (.where(), .orderBy(), .get()) sur des références de document ou de collection pour récupérer des documents. L'ordre des étapes de la requête est implicite et la compatibilité avec l'agrégation est limitée.

Les opérations de base sont disponibles dans les éditions Enterprise et Standard, mais les valeurs par défaut des index sont très différentes entre les éditions. Pour en savoir plus, consultez la section suivante.

Différences entre les éditions

Avec l'introduction de la compatibilité avec le mode natif dans l'édition Enterprise, les opérations de base et de pipeline Firestore sont disponibles. Lorsque vous utilisez des opérations de base dans l'édition Enterprise, le nouveau comportement d'index et le nouveau modèle de tarification suppriment de nombreuses restrictions de l'édition Standard.

Fonctionnalité Édition Standard Édition Enterprise
Opérations compatibles Limitées aux opérations de base Firestore. Compatibles avec les opérations de base et de pipeline Firestore, ainsi qu'avec les opérations de compatibilité Firestore MongoDB.
Exigence d'indexation Toutes les requêtes nécessitent des index. Les index ne sont pas obligatoires pour les requêtes.
Création d'index Des index automatiques sont créés pour les champs uniques. Vous pouvez créer manuellement des index composites. Aucun index automatique n'est créé. Les index doivent être gérés manuellement.
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 le champ a. Firestore utilise 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 et coût des requêtes Les requêtes sont généralement performantes en raison des exigences d'index. Optimisez les performances et les coûts des requêtes en créant des index. Vous pouvez identifier les index manquants à l'aide de Query Explain et Insights sur les requêtes.

Les requêtes sans index peuvent être peu performantes et coûteuses à mesure que l'ensemble de données augmente, ce qui nécessite une surveillance et un réglage.
Coût de surcharge de l'indexation Aucun frais pour les écritures d'index, car les index sont automatiques. L'écriture d'entrées d'index consomme des unités d'écriture lorsqu'un document associé est écrit (1 unité d'écriture par 1 Kio de taille d'entrée d'index). Vous économisez sur les coûts de stockage en ne créant pas d'entrées d'index pour chaque champ.
Modèle de facturation (lectures/écritures/suppressions) Facturé par lecture, écriture et suppression de document. Facturé par lecture et écriture (tranche). Les lectures sont facturées en unités de lecture (tranches de 4 Kio). Les écritures et les suppressions sont fusionnées en unités d'écriture (tranches de 1 Kio).
Tarification de base (par million)

Les prix indiqués concernent la région us-central1

 		Lectures : 0,03$pour 100 000 documents (ou 0,30 $par million).

Écritures : 0,09$pour 100 000 documents (ou 0,90 $par million).

Suppressions : 0,01$pour 100 000 documents (ou 0,10 $par million)

Unités de lecture : 0,05$par million d'unités de lecture.

Unités d'écriture : 0,26$par million d'unités d'écriture. Les prix sont généralement plus bas si les documents font moins de 4 Kio que le coût de lecture standard.
Mises à jour en temps réel

Les prix indiqués concernent la région us-central1

 Les mises à jour en temps réel sont incluses et facturées en tant que lectures à 0,03 $pour 100 000 documents. Les mises à jour en temps réel disposent d'une nouvelle référence distincte (unités de mises à jour en temps réel), facturée par tranche de 4 Kio. Les mises à jour en temps réel coûtent 0,30$par million d'unités de lecture.

Étape suivante