Présentation de l'indexation
Les index sont un facteur important de performances pour une base de données. Tout comme le sommaire d'un livre qui indique la correspondance des sujets avec des numéros de page, l'index d'une base de données associe les éléments qu'elle contient à leur emplacement. Lorsque vous envoyez une requête, l'index permet à la base de données interrogée de trouver rapidement les emplacements des éléments que vous avez demandés.
Cette page décrit les deux types d'index utilisés par Firestore : les index à champ unique et les index composites.
Définition et structure des index
Un index est défini sur une liste de champs d'un document donné, avec un mode d'index correspondant à chaque champ.
Un index contient une entrée pour chaque champ nommé dans sa définition. L'index inclut tous les documents constituant les résultats potentiels des requêtes basées sur l'index. Un document n'est inclus dans l'index que s'il possède une valeur indexée définie pour chaque champ utilisé dans l'index. Si la définition de l'index fait référence à un champ pour lequel le document n'a pas de valeur définie, ce document n'apparaîtra pas dans l'index et ne sera donc jamais renvoyé comme résultat pour toute requête basée sur l'index.
L'index composite est trié par valeurs de champ, dans l'ordre spécifié dans la définition de l'index.
Un index derrière chaque requête
Si aucun index n'est disponible pour une requête, la plupart des bases de données parcourent un à un les éléments qu'elles contiennent. Ce processus devient de plus en plus lent à mesure que la base de données s'agrandit. Pour garantir des performances de requêtes élevées, Firestore fait appel à des index pour toutes les requêtes. Ainsi, les performances des requêtes dépendent de la taille de l'ensemble de résultats et non du nombre d'éléments disponibles dans la base de données.
Une gestion d'index aisée pour développer plus rapidement
Firestore inclut des fonctionnalités qui vous permettent de consacrer moins de temps à gérer des index. Les index requis pour traiter les requêtes les plus simples sont créés automatiquement. Firestore vous aide à identifier et à créer d'autres index requis à mesure que vous utilisez et testez votre application.
Types d'index
Firestore utilise deux types d'index : les index à champ unique et les index composites. Outre le nombre de champs indexés, les index à champ unique et les index composites diffèrent dans la façon dont vous les gérez.
Index à champ unique
Un index à champ unique stocke un tri de correspondances entre tous les documents d'une collection qui contiennent un seul champ spécifique. Chaque entrée d'un index à champ unique enregistre la valeur d'un document pour un champ spécifique ainsi que l'emplacement du document dans la base de données. Firestore exécute de nombreuses requêtes élémentaires à l'aide de ces index. Pour gérer les index à champ unique, vous devez configurer les paramètres d'indexation automatique et les exceptions d'index de votre base de données.
Indexation automatique
Par défaut, Firestore conserve automatiquement des index à champ unique pour chaque champ d'un document et chaque sous-champ d'une carte. Pour les index à champ unique, Firestore utilise les paramètres par défaut suivants :
Pour chaque champ non issu d'un tableau ou d'une carte, Firestore crée deux index à champ unique dont le champ d'application est défini sur une collection, l'un en mode croissant et l'autre en mode décroissant.
Pour chaque champ de la carte, Firestore crée les éléments suivants:
- Un index croissant dont le champ d'application est défini sur une collection pour chaque sous-champ non lié à un tableau et à une carte.
- Un index décroissant dont le champ d'application est défini sur une collection pour chaque sous-champ non lié à un tableau ni à une carte.
- Un index "array-contains" dont le champ d'application est défini sur une collection pour chaque sous-champ de tableau
- Firestore indexe de manière récursive chaque sous-champ de la carte.
Pour chaque champ de tableau d'un document, Firestore crée et conserve un index "array-contains" dont le champ d'application est défini sur une collection.
Les index à champ unique dont le champ d'application est défini sur un groupe de collections ne sont pas conservés par défaut.
Exceptions d'index à champ unique
Vous pouvez exclure un champ de vos paramètres d'indexation automatique en créant une exception d'index à champ unique. Les exceptions d'indexation vous permettent de remplacer les paramètres d'index automatiques de votre base de données. Une exception permet d'activer un index à champ unique qui était à l'origine désactivé par vos paramètres d'indexation automatiques. À l'inverse, vous pouvez désactiver un index à champ unique qui était à l'origine activé par l'indexation automatique. Pour découvrir dans quelles situations utiliser les exceptions, consultez les bonnes pratiques en matière d'indexation.
Utilisez la valeur du chemin d'accès du champ * pour ajouter des exceptions d'index au niveau de la collection sur tous les champs d'un groupe de collections. Par exemple, pour le groupe de collections comments, définissez le chemin d'accès du champ sur * pour qu'il corresponde à tous les champs du groupe de collections comments et désactivez l'indexation de tous les champs du groupe de collections. Vous pouvez ensuite ajouter des exceptions pour indexer uniquement les champs requis pour vos requêtes. La réduction du nombre de champs indexés réduit les coûts de stockage et peut améliorer les performances d'écriture.
Si vous créez une exception d'index à champ unique pour un champ de carte, les sous-champs de la carte héritent de ces paramètres. Vous pouvez toutefois définir des exceptions d'index à champ unique pour des sous-champs spécifiques. Si vous supprimez une exception pour un sous-champ, le sous-champ hérite des paramètres d'exception de son parent, s'ils existent. Si aucune exception n'existe pour le parent, le sous-champ hérite des paramètres de base de données.
Pour découvrir comment créer et gérer des exceptions d'index à champ unique, consultez la page Gérer les index dans Firestore.
Index composites
Un index composite stocke un tri de correspondances entre tous les documents d'une collection, en fonction d'une liste numérotée de champs à indexer.
Firestore utilise des index composites pour traiter les requêtes qui ne sont pas déjà prises en charge par des index à champ unique.
À l'inverse des index à champ unique, les index composites ne sont pas créés automatiquement par Firestore en raison du grand nombre de combinaisons de champs possibles. Firestore vous aide toutefois à identifier et créer les index composites requis à mesure que vous développez votre application.
Si vous essayez d'envoyer la requête ci-dessus sans avoir créé l'index requis au préalable, Firestore affiche un message d'erreur contenant un lien que vous pouvez suivre pour créer l'index manquant. Cette erreur se produit chaque fois que vous essayez d'envoyer une requête non prise en charge par un index. Vous pouvez aussi définir et gérer manuellement des index composites à l'aide de la console ou de l'interface en ligne de commandes CLI Firebase. Pour découvrir comment créer et gérer des index composites, consultez la page Gérer les index.
Modes d'index et champs d'application des requêtes
Même si la configuration des index à champ unique diffère de celle des index composites, vous devez configurer les modes d'index et les champs d'application des requêtes pour les deux types d'index.
Modes d'index
Lorsque vous définissez un index, vous sélectionnez un mode d'index pour chaque champ indexé. Le mode d'index de chaque champ accepte des clauses de requête spécifiques à ce champ. Vous pouvez choisir parmi les modes d'index suivants :
| Mode d'index | Description |
|---|---|
| Croissant | Le champ accepte les clauses de requête <, <=, ==, >=, >, !=, in et not-in, et les résultats sont triés par ordre croissant en fonction de la valeur de ce champ. |
| Décroissant | Le champ accepte les clauses de requête <, <=, ==, >=, >, !=, in et not-in, et les résultats sont triés par ordre décroissant en fonction de la valeur de ce champ. |
| Array‑contains | Le champ accepte les clauses de requête array-contains et array-contains-any. |
| Vecteur | Le champ accepte les clauses de requête FindNearest. |
Champs d'application des requêtes
Chaque index s'applique à une collection ou à un groupe de collections. C'est ce qu'on appelle le champ d'application des requêtes d'index :
- Champ d'application de la collection
- Par défaut, Firestore crée des index qui s'appliquent à une collection. Ces index acceptent les requêtes qui renvoient les résultats d'une seule collection.
- Champ d'application du groupe de collections
- Un groupe de collections inclut toutes les collections possédant le même identifiant. Pour obtenir des résultats filtrés ou triés d'un groupe de collections lorsque vous exécutez une requête de groupe de collections, vous devez créer un index correspondant qui s'applique au groupe de collections.
Ordre par défaut et champ __name__
En plus de trier les documents selon les modes d'index spécifiés pour chaque champ (croissant ou décroissant) , les index appliquent un tri final en fonction du champ __name__ de chaque document. La valeur du champ __name__ est définie sur le chemin d'accès complet du document. Cela signifie que les documents de l'ensemble de résultats ayant les mêmes valeurs de champ sont triés par chemin d'accès du document.
Par défaut, le champ __name__ est trié dans la même direction que le dernier champ trié dans la définition d'index. Exemple :
| Collection | Champs indexés | Champ d'application de la requête |
|---|---|---|
| cities | Nom de , __name__ |
Collection |
| cities | État de , __name__ |
Collection |
| cities | pays, population, __name__ |
Collection |
Pour trier les résultats dans le sens __name__ autre que celui par défaut, vous devez créer cet index.
Indice parfait
L'index parfait pour une requête, permettant de l'exécuter plus efficacement, est défini dans les propriétés suivantes, dans l'ordre:
- Champs utilisés dans les filtres d'égalité
- Champs utilisés dans les ordres de tri
- Champs utilisés dans les filtres de plage et d'inégalité (qui ne sont pas déjà inclus dans les ordres de tri)
- Champs utilisés dans les agrégations (qui ne sont pas déjà inclus dans les ordres de tri et les filtres de plage et d'inégalité)
Firestore calcule les résultats des requêtes comme suit:
- Il identifie l'index correspondant à la collection, aux propriétés de filtrage, aux opérateurs de filtrage et aux ordres de tri de la requête.
- Identifie la position de l'index à partir de laquelle l'analyse doit commencer à utiliser les filtres d'égalité de la requête et les filtres de plage et d'inégalité sur le premier champ par champ.
- Démarre l'analyse de l'index en renvoyant chaque document répondant à tous les filtres, jusqu'à ce qu'il :
- rencontre un document qui ne remplit pas les conditions de filtre et confirme qu'un document ultérieur ne remplira jamais complètement les conditions de filtre ;
- atteigne la fin de l'index ;
- ait collecté le nombre maximal de résultats demandés par la requête.
Exemple d'indexation
Firestore crée automatiquement des index à champ unique, ce qui permet à votre application de prendre en charge rapidement les requêtes de bases de données les plus simples.
Les index à champ unique vous permettent d'effectuer des requêtes simples à partir des valeurs des champs et des comparateurs <, <=, ==, >=, > et in. Pour les champs de tableau, les index à champ unique vous permettent d'effectuer des requêtes array-contains et array-contains-any.
Examinez les exemples suivants qui illustrent les index à champ unique du point de vue de leur création. L'extrait de code suivant permet de créer des documents city dans une collection cities et de définir les champs name, state, country, capital, population et tags pour chaque document :
Web
var citiesRef = db.collection("cities");
citiesRef.doc("SF").set({
name: "San Francisco", state: "CA", country: "USA",
capital: false, population: 860000,
regions: ["west_coast", "norcal"] });
citiesRef.doc("LA").set({
name: "Los Angeles", state: "CA", country: "USA",
capital: false, population: 3900000,
regions: ["west_coast", "socal"] });
citiesRef.doc("DC").set({
name: "Washington, D.C.", state: null, country: "USA",
capital: true, population: 680000,
regions: ["east_coast"] });
citiesRef.doc("TOK").set({
name: "Tokyo", state: null, country: "Japan",
capital: true, population: 9000000,
regions: ["kanto", "honshu"] });
citiesRef.doc("BJ").set({
name: "Beijing", state: null, country: "China",
capital: true, population: 21500000,
regions: ["jingjinji", "hebei"] });
Firestore devine les paramètres d'indexation automatiques par défaut afin de mettre à jour un index à champ unique croissant et un index à champ unique décroissant pour chaque champ non issu d'un tableau, ainsi qu'un index à champ unique "array-contains" pour le champ de tableau. Chaque ligne du tableau suivant représente une entrée dans un index à champ unique :
| Collection | Champ indexé | Champ d'application de la requête |
|---|---|---|
| cities | name | Collection |
| cities | state | Collection |
| cities | country | Collection |
| cities | capital | Collection |
| cities | population | Collection |
| cities | name | Collection |
| cities | state | Collection |
| cities | country | Collection |
| cities | capital | Collection |
| cities | population | Collection |
| cities | array-contains regions |
Collection |
Requêtes acceptées par les index à champ unique
À l'aide de ces index à champ unique créés automatiquement, vous pouvez exécuter des requêtes simples comme suit :
Web
const stateQuery = citiesRef.where("state", "==", "CA");
const populationQuery = citiesRef.where("population", "<", 100000);
const nameQuery = citiesRef.where("name", ">=", "San Francisco");
Vous pouvez également créer des requêtes in et des requêtes d'égalité composées (==) :
Web
citiesRef.where('country', 'in', ["USA", "Japan", "China"])
// Compound equality queries
citiesRef.where("state", "==", "CO").where("name", "==", "Denver")
citiesRef.where("country", "==", "USA")
.where("capital", "==", false)
.where("state", "==", "CA")
.where("population", "==", 860000)
Si vous devez exécuter une requête composée en comparant des plages (<, <=, > ou >=) ou si vous devez trier les résultats en fonction d'un autre champ, vous devez créer un index composite pour cette requête.
L'index array-contains vous permet d'interroger le champ de tableau regions :
Web
citiesRef.where("regions", "array-contains", "west_coast")
// array-contains-any and array-contains use the same indexes
citiesRef.where("regions", "array-contains-any", ["west_coast", "east_coast"])
Requêtes acceptées par les index composites
Firestore utilise des index composites pour accepter les requêtes composées qui ne sont pas déjà prises en charge par les index à champ unique. Par exemple, les requêtes suivantes nécessitent un index composite :
Web
citiesRef.where("country", "==", "USA").orderBy("population", "asc")
citiesRef.where("country", "==", "USA").where("population", "<", 3800000)
citiesRef.where("country", "==", "USA").where("population", ">", 690000)
// in and == clauses use the same index
citiesRef.where("country", "in", ["USA", "Japan", "China"])
.where("population", ">", 690000)
Ces requêtes nécessitent d'utiliser l'index composite ci-dessous. Étant donné que la requête utilise une clause d'égalité (== ou in) pour le champ country, vous pouvez utiliser un mode d'index croissant ou décroissant pour ce champ. Par défaut, les clauses d'inégalité appliquent un ordre de tri croissant en fonction du champ qu'elles concernent.
| Collection | Champs indexés | Champ d'application de la requête |
|---|---|---|
| cities | (ou ) country, population | Collection |
Pour exécuter les mêmes requêtes avec un ordre de tri décroissant, vous devez créer un index composite supplémentaire en appliquant le sens décroissant à population :
Web
citiesRef.where("country", "==", "USA").orderBy("population", "desc")
citiesRef.where("country", "==", "USA")
.where("population", "<", 3800000)
.orderBy("population", "desc")
citiesRef.where("country", "==", "USA")
.where("population", ">", 690000)
.orderBy("population", "desc")
citiesRef.where("country", "in", ["USA", "Japan", "China"])
.where("population", ">", 690000)
.orderBy("population", "desc")
| Collection | Champs indexés | Champ d'application de la requête |
|---|---|---|
| cities | country, population | Collection |
| cities | country, population | Collection |
Vous devez également créer un index composite pour associer une requête array-contains ou array-contains-any à des clauses supplémentaires.
Web
citiesRef.where("regions", "array-contains", "east_coast")
.where("capital", "==", true)
// array-contains-any and array-contains use the same index
citiesRef.where("regions", "array-contains-any", ["west_coast", "east_coast"])
.where("capital", "==", true)
| Collection | Champs indexés | Champ d'application de la requête |
|---|---|---|
| cities | tags array-contains, (ou ) capital | Collection |
Requêtes acceptées par les index de groupes de collections
Pour illustrer un index dont le champ d'application est défini sur un groupe de collections, imaginons que vous ajoutiez une sous-collection landmarks à certains des documents de la collection city :
Web
var citiesRef = db.collection("cities");
citiesRef.doc("SF").collection("landmarks").doc().set({
name: "Golden Gate Bridge",
category : "bridge" });
citiesRef.doc("SF").collection("landmarks").doc().set({
name: "Golden Gate Park",
category : "park" });
citiesRef.doc("DC").collection("landmarks").doc().set({
name: "National Gallery of Art",
category : "museum" });
citiesRef.doc("DC").collection("landmarks").doc().set({
name: "National Mall",
category : "park" });
Cet index à champ unique dont le champ d'application est défini sur une collection vous permet d'interroger la collection landmarks d'une seule ville en fonction du champ category :
| Collection | Champs indexés | Champ d'application de la requête |
|---|---|---|
| landmarks | (ou ) category | Collection |
Web
citiesRef.doc("SF").collection("landmarks").where("category", "==", "park")
citiesRef.doc("SF").collection("landmarks").where("category", "in", ["park", "museum"])
Maintenant, imaginez que vous souhaitez interroger les points de repère de toutes les villes.
Pour exécuter cette requête sur le groupe de collections qui se compose de toutes les collections landmarks, vous devez activer un index à champ unique landmarks dont le champ d'application est défini sur un groupe de collections :
| Collection | Champs indexés | Champ d'application de la requête |
|---|---|---|
| landmarks | (ou ) category | Groupe de collections |
Lorsque cet index est activé, vous pouvez interroger le groupe de collections landmarks :
Web
var landmarksGroupRef = db.collectionGroup("landmarks");
landmarksGroupRef.where("category", "==", "park")
landmarksGroupRef.where("category", "in", ["park", "museum"])
Pour obtenir des résultats filtrés ou triés lorsque vous exécutez une requête de groupe de collections, vous devez activer un index à champ unique ou composite correspondant qui s'applique au groupe de collections. En revanche, si une requête de groupe de collections n'exige pas de trier ou de filtrer les résultats, aucun autre index n'est nécessaire.
Par exemple, vous pouvez exécuter la requête de groupe de collections suivante sans activer d'index supplémentaire :
Web
db.collectionGroup("landmarks").get()
Entrées d'index
Les index configurés pour votre projet et la structure d'un document déterminent le nombre d'entrées d'index pour un document. Les entrées d'index sont comptabilisées dans le nombre maximal d'entrées d'index.
L'exemple suivant illustre les entrées d'index d'un document.
Document
/cities/SF
city_name : "San Francisco"
temperatures : {summer: 67, winter: 55}
neighborhoods : ["Mission", "Downtown", "Marina"]
Index à champ unique
- city_name ASC
- nom de ville DESC
- températures.été ASC
- températures.été DESC
- températures.winter ASC
- températures.winter DESC
- quartiers Le tableau contient (ASC et DESC)
Index composites
- city_name ASC, quartiers ARRAY
- city_name DESC, quartiers ARRAY
Entrées d'index
Cette configuration d'indexation génère les 18 entrées d'index suivantes pour le document:
| Index | Données indexées |
|---|---|
| Entrées d'index à champ unique | |
| city_name ASC | city_name: "San Francisco" |
| nom de ville DESC | city_name: "San Francisco" |
| températures.été ASC | temperatures.summer: 67 |
| températures.été DESC | temperatures.summer: 67 |
| températures.winter ASC | temperatures.winter: 55 |
| températures.winter DESC | temperatures.winter: 55 |
| quartiers Tableau contient ASC | neighborhoods: "Mission" |
| quartiers Le tableau contient DESC | neighborhoods: "Mission" |
| quartiers Tableau contient ASC | neighborhoods: "Downtown" |
| quartiers Le tableau contient DESC | neighborhoods: "Downtown" |
| quartiers Tableau contient ASC | neighborhoods: "Marina" |
| quartiers Le tableau contient DESC | neighborhoods: "Marina" |
| Entrées d'index composite | |
| city_name ASC, quartiers ARRAY | city_name: "San Francisco", quartiers: "Mission" |
| city_name ASC, quartiers ARRAY | city_name: "San Francisco", quartiers: "Centre-ville" |
| city_name ASC, quartiers ARRAY | city_name: "San Francisco", quartiers: "Marina" |
| city_name DESC, quartiers ARRAY | city_name: "San Francisco", quartiers: "Mission" |
| city_name DESC, quartiers ARRAY | city_name: "San Francisco", quartiers: "Centre-ville" |
| city_name DESC, quartiers ARRAY | city_name: "San Francisco", quartiers: "Marina" |
Index et tarifs
Les coûts de stockage de votre application prennent en compte les index. Pour savoir comment Cloud Firestore calcule la taille des entrées d'index, consultez la page Taille des entrées d'index.
Tirer parti de la fusion d'index
Bien que chaque requête effectuée dans Firestore utilise un index, il n'est pas nécessaire d'avoir recours à un index unique par requête. Pour les requêtes comportant plusieurs clauses d'égalité (==) et, éventuellement, une clause orderBy, Firestore peut réutiliser des index existants. Firestore est capable de fusionner les index des requêtes d'égalité simples pour créer les index composites requis lorsque vous effectuez des requêtes d'égalité plus volumineuses.
En identifiant les opportunités de fusion d'index, vous pouvez réduire vos frais d'indexation. Imaginons, par exemple, une collection restaurants associée à une application de notation de restaurants :
restaurants
burgerthyme
name : "Burger Thyme"
category : "burgers"
city : "San Francisco"
editors_pick : true
star_rating : 4
Imaginons maintenant que cette application utilise des requêtes similaires à celles répertoriées ci-dessous. Vous remarquerez que l'application utilise des combinaisons de clauses d'égalité pour category, city et editors_pick tout en triant toujours star_rating par ordre croissant :
Web
db.collection("restaurants").where("category", "==", "burgers")
.orderBy("star_rating")
db.collection("restaurants").where("city", "==", "San Francisco")
.orderBy("star_rating")
db.collection("restaurants").where("category", "==", "burgers")
.where("city", "==", "San Francisco")
.orderBy("star_rating")
db.collection("restaurants").where("category", "==", "burgers")
.where("city", "==" "San Francisco")
.where("editors_pick", "==", true )
.orderBy("star_rating")
Vous pourriez créer un index pour chaque requête :
| Collection | Champs indexés | Champ d'application de la requête |
|---|---|---|
| restaurants | category, star_rating | Collection |
| restaurants | city, star_rating | Collection |
| restaurants | category, city, star_rating | Collection |
| restaurants | category, city, editors_pick, star_rating | Collection |
Toutefois, une solution plus efficace consiste à réduire le nombre d'index à l'aide de la fusion d'index pour les clauses d'égalité permise par Firestore :
| Collection | Champs indexés | Champ d'application de la requête |
|---|---|---|
| restaurants | category, star_rating | Collection |
| restaurants | city, star_rating | Collection |
| restaurants | editors_pick, star_rating | Collection |
Non seulement cet ensemble d'index est plus petit, mais il accepte également une requête supplémentaire :
Web
db.collection("restaurants").where("editors_pick", "==", true)
.orderBy("star_rating")
Limites d'indexation
Les limites suivantes s'appliquent aux index. Pour plus d'informations sur l'ensemble des quotas et limites, consultez la page Quotas et limites.
Cette page présente les quotas et limites de requêtes pour Firestore.
| Limite | Détails |
|---|---|
| Nombre maximal d'index composites pour une base de données |
|
| Nombre maximal de configurations à champ unique pour une base de données |
Une configuration au niveau du champ peut contenir plusieurs configurations pour le même champ. Par exemple, une exception d'indexation à champ unique et une règle TTL sur le même champ comptent pour une configuration de champ dans le calcul de la limite. |
|
Nombre maximal d'entrées d'index pour chaque document |
40 000 Le nombre d'entrées d'index représente la somme des entrées suivantes pour un document :
Pour savoir comment Firestore transforme un document et un ensemble d'index en entrées d'index, consultez cet exemple de nombre d'entrées d'index. |
| Nombre maximal de champs dans un index composite | 100 |
| Taille maximale d'une entrée d'index |
7,5 Kio Pour savoir comment Firestore calcule la taille des entrées d'index, consultez la page Taille des entrées d'index. |
| Somme maximale des tailles d'entrée d'index d'un document |
8 Mio La taille totale représente la somme des tailles suivantes pour un document : |
| Taille maximale d'une valeur de champ indexé |
1 500 octets Les valeurs de champ au-delà de 1 500 octets sont tronquées. Les requêtes impliquant des valeurs de champ tronquées peuvent renvoyer des résultats incohérents. |
Bonnes pratiques d'indexation
Pour la plupart des applications, vous pouvez compter sur l'indexation automatique et sur les liens affichés dans les messages d'erreur pour gérer vos index. Toutefois, les cas suivants peuvent nécessiter l'ajout d'exceptions de champs uniques :
| Cas | Description |
|---|---|
| Champs de chaîne volumineux | S'il existe un champ de chaîne contenant souvent des chaînes longues que vous n'utilisez pas pour les requêtes, vous pouvez réduire les coûts de stockage en excluant le champ de l'indexation. |
| Taux d'écriture élevés dans une collection contenant des documents avec des valeurs séquentielles | Si vous indexez un champ qui augmente ou diminue séquentiellement entre les documents d'une collection, comme un horodatage, le taux d'écriture maximal pour la collection est de 500 écritures par seconde. Si vous ne faites pas de requête en fonction du champ avec des valeurs séquentielles, vous pouvez exclure le champ de l'indexation pour contourner cette limite. Par exemple, dans le cas d'un IoT avec un taux d'écriture élevé, une collection contenant des documents avec un champ d'horodatage peut approcher la limite des 500 écritures par seconde. |
| Champs TTL |
Si vous utilisez des règles TTL (Time To Live), notez que le champ TTL doit être un horodatage. L'indexation sur les champs TTL est activée par défaut et peut affecter les performances à des taux de trafic plus élevés. Nous vous recommandons d'ajouter des exceptions de champs uniques pour vos champs TTL. |
| Champs de tableau ou de carte volumineux | Les champs de tableau ou de mappage volumineux peuvent approcher la limite de 40 000 entrées d'index par document. Si vous ne faites pas de requête en fonction d'un champ de tableau ou de carte volumineux, vous devez exclure ce champ de l'indexation. |
Si vous utilisez des requêtes avec des opérateurs de plage et d'inégalité sur plusieurs champs, consultez les remarques concernant l'indexation à prendre en compte pour optimiser les performances et le coût des requêtes Firestore
Pour plus d'informations sur la résolution des problèmes d'indexation (distribution d'index, erreurs INVALID_ARGUMENT), consultez la page de dépannage.