L'empreinte de stockage ou le nombre d'entrées maintenues par un index de recherche, exprimée soit en octets (disque ou mémoire), soit en comptages logiques (nombre de postings, termes uniques, documents ou paires terme‑document). La taille de l'index dépend du volume de données, des structures d'indexation, de la compression et des métadonnées, et constitue une métrique de ressource utilisée en conception et évaluation système.

Principe

La taille de l'index traduit un compromis entre couverture/détail et coût en ressources : des index plus volumineux stockent en général plus de postings, des métadonnées plus fines ou une compression moins agressive, augmentant l'utilisation disque/mémoire et affectant souvent I/O, comportement du cache et débit de mise à jour.

Démonstration

Scénario illustratif → Deux index sur le même corpus : Index A stocke des postings bruts avec compression minimale et contient 500 millions de postings occupant 120 Go ; Index B stocke postings compressés et pointeurs de saut et occupe 45 Go. Bien que le contenu documentaire soit identique, Index B utilise moins de stockage mais peut nécessiter plus de CPU pour la décompression ; la latence des requêtes et le coût des mises à jour diffèreront entre A et B.

Mauvaise application

Assimiler une taille d'index plus grande à une meilleure qualité de recherche. L'augmentation de taille peut provenir de métadonnées verbeuses, de réplication ou de listes de postings non élaguées sans améliorer la pertinence visible par l'utilisateur. Inversement, supposer que l'index le plus petit est toujours le plus performant néglige le coût CPU d'une compression forte ou la perte de métadonnées utiles.

Conséquence

La taille de l'index oriente les décisions d'infrastructure : capacité de stockage, provisionnement mémoire, stratégie de shards/réplicas, coûts de sauvegarde/restauration et compromis latence/débit opérationnels. Elle contraint aussi les fonctionnalités (p. ex. statistiques par posting, offsets de position) économiquement stockables.

Inversion

Une plus petite taille d'index n'implique pas universellement des requêtes plus rapides ou un coût inférieur : la compression agressive peut augmenter le CPU et réduire le débit ; l'architecture de distribution et de cache, la taille du working set et les schémas d'accès peuvent dominer les implications de performance liées à la taille.

Limite

Clairement dans : mesures des fichiers d'index sur disque ou en mémoire, comptages de postings, nombres de termes uniques ou paires terme‑document utilisées pour planifier les ressources. Cas limite : le working set runtime effectif (sous‑ensemble cacheable) peut être bien plus petit que la taille totale de l'index et constituer la contrainte opérationnelle pour la latence. Clairement hors : stockage externe des documents sources, caches applicatifs ou données éphémères en temps de requête non persistées dans l'index.

Tension sémantique

Taille ↔ Performance/Coût — des index plus petits réduisent le coût de stockage mais peuvent accroître la consommation CPU ou réduire la richesse fonctionnelle ; des index plus grands améliorent la flexibilité de recherche au prix du stockage, de la réplication et du surcoût de mise à jour.

Synthèse

La taille de l'index est une métrique système à interpréter conjointement avec la compression, les schémas d'accès et l'architecture : privilégiez des designs d'index équilibrant empreinte de stockage, CPU, latence et exigences fonctionnelles plutôt que d'optimiser la taille isolément.