Moteur de Requête Redis

Guidance pour utiliser le Moteur de Requête Redis (RQE) afin d'indexer et de rechercher des documents Hash ou JSON. Couvre la conception de schéma avec FT.CREATE, les choix de type de champ, la syntaxe des requêtes, la gestion du cycle de vie des index et les pièges de performance les plus courants.

Quand appliquer

• Création, modification ou révision d'un index RQE (FT.CREATE, FT.ALTER).
• Écriture ou optimisation de requêtes FT.SEARCH / FT.AGGREGATE.
• Choix entre TEXT, TAG, NUMERIC, GEO, GEOSHAPE ou VECTOR pour un champ.
• Déploiement d'un nouveau schéma d'index sans interruption.
• Initialisation d'un index couvrant uniquement les clés nouvellement écrites.

1. Utiliser DIALECT 2 (la valeur par défaut moderne)

DIALECT 2 est la base. Les autres dialectes (1, 3, 4) sont dépréciés depuis Redis 8. La plupart des bibliothèques client modernes en font déjà la valeur par défaut — mais spécifiez-le explicitement dans les commandes brutes pour la portabilité.

FT.SEARCH idx:products "@name:laptop" DIALECT 2

DIALECT 2 est obligatoire pour les requêtes de recherche vectorielle. Il gère aussi les caractères spéciaux et les NULL de manière prévisible.

Voir references/dialect.md.

2. Choisir le bon type de champ

Le type de champ détermine à la fois ce que vous pouvez requêter et la vitesse de cette requête. Utilisez le type le plus étroit qui supporte votre pattern d'accès.

L'erreur classique est d'utiliser TEXT pour un champ de catégorie ou de statut parce que « c'est une chaîne ». TAG est 10× plus rapide pour ceux-ci.

Voir references/field-types.md.

3. Indexer uniquement ce que vous requêtez — et toujours définir un préfixe

FT.CREATE sans PREFIX indexe chaque clé correspondante dans la base de données ; avec un schéma large, cela peut faire exploser la taille de l'index et la latence d'écriture.

FT.CREATE idx:products ON HASH PREFIX 1 product:
    SCHEMA
        name TEXT WEIGHT 2.0
        category TAG SORTABLE
        price NUMERIC SORTABLE
        location GEO

Règles de base :

• Commencez avec le schéma minimal. Ajoutez des champs au fur et à mesure que de nouveaux patterns de requête apparaissent.
• Toujours définir PREFIX (ou filtrer via expression FILTER).
• Utiliser FT.INFO idx:<name> pour surveiller la taille de l'index après ajout de champs.
• Utiliser SORTABLE uniquement sur les champs selon lesquels vous triez réellement ; cela a un coût mémoire.

Voir references/index-creation.md.

4. Mises à jour d'index sans interruption — utiliser des alias

Pour les changements de schéma en production, gardez les requêtes d'application pointant sur un alias et échangez l'index sous-jacent.

FT.CREATE idx:products_v2 ON HASH PREFIX 1 product: SCHEMA ...
FT.ALIASUPDATE products idx:products_v2

# Les requêtes d'app sont stables :
FT.SEARCH products "@category:{electronics}"

Commandes de gestion utiles : FT.INFO, FT.DROPINDEX, FT._LIST, FT.ALIASADD/UPDATE/DEL.

Voir references/index-management.md.

5. SKIPINITIALSCAN — uniquement quand les données historiques ne sont pas pertinentes

Par défaut, FT.CREATE parcourt toutes les clés existantes correspondant au préfixe et les indexe. Utilisez SKIPINITIALSCAN uniquement quand :

• Vous mettez en place l'index pour une nouvelle fonctionnalité et les données existantes ne doivent pas être requêtables.
• Les données existantes sont trop volumineuses pour être scannées de manière synchrone.
• Vous indexez des flux d'événements où seuls les événements futurs comptent.

Pour la plupart des migrations de schéma, la valeur par défaut (tout scanner) est ce que vous voulez.

Voir references/skip-initial-scan.md.

6. Écrire des requêtes spécifiques, pas *

Réduisez l'ensemble de résultats avec des filtres avant paging ou agrégation.

# Bon — filtre spécifique, champs limités retournés
FT.SEARCH idx:products "@category:{electronics} @price:[100 500]"
    LIMIT 0 20
    RETURN 3 name price category

# Mauvais — scan complet plus LIMIT non limité
FT.SEARCH idx:products "*" LIMIT 0 10000

Autres leviers :

• SORTBY nécessite SORTABLE sur le champ de tri. Sans cela, le tri est lent.
• LIMIT tôt ; le moteur traite quand même tout ce qui est au-dessus de la limite si vous ne le faites pas.
• RETURN des champs spécifiques — ne récupérez pas le document entier si vous n'avez besoin que de quelques champs.
• Profiler avec FT.PROFILE idx:<name> SEARCH QUERY "<query>" quand une requête est lente.

Voir references/query-optimization.md.

Références

• Redis: Query Engine — Indexing
• Redis: Query syntax
• Redis: Query dialects
• Redis: Administration (aliases, dropindex)
• FT.CREATE