Calculateur de taille de base de données vectorielle
Données
| Nombre de vecteurs | 1 000 000 |
|---|---|
| Dimensions | 1 536 |
| Octets par valeur | 4 |
| Surcoût d'index | 25 % |
Calculateur de taille de base de données vectorielle
Estimez l'empreinte de stockage d'un index d'embeddings à partir du nombre de vecteurs, de la dimension des vecteurs, du nombre d'octets par valeur et du surcoût d'index ajouté par les structures de recherche du plus proche voisin approché.
Données
Vecteurs
Index
Résultats
Saisissez une valeur pour afficher les résultats.
Détails
La taille d'une base de données vectorielle expliquée
La taille d'une base de données vectorielle est la quantité de stockage nécessaire pour conserver un ensemble de vecteurs d'embedding ainsi que l'index de recherche construit par-dessus. Lorsqu'un système de recherche encode un corpus, chaque fragment de document devient un vecteur — une liste de nombres de longueur fixe — et tous ces vecteurs doivent résider quelque part qui prend en charge une recherche de similarité rapide. L'empreinte dépend de trois facteurs : le nombre de vecteurs, la longueur de chaque vecteur et le nombre d'octets qu'occupe chaque valeur.
Comment se cumule l'empreinte
Un vecteur est un tableau de dimensions nombres. Chaque nombre est stocké à une
précision choisie : 4 octets pour un flottant 32 bits, 2 octets pour un flottant
16 bits, ou 1 octet pour un entier quantifié 8 bits. Multiplier la taille en
octets d'une valeur par la dimension donne la taille d'un vecteur, et multiplier
par le nombre de vecteurs donne la charge utile brute.
Au-dessus des vecteurs bruts se trouve l'index. Comparer une requête à chaque vecteur stocké est exact mais lent dès que le nombre atteint les millions ; les bases de données vectorielles construisent donc une structure du plus proche voisin approché — le plus souvent un graphe HNSW — qui permet à la recherche de ne visiter qu'une petite fraction des vecteurs. Ce graphe stocke des liens vers les voisins pour chaque vecteur, et ces liens constituent des données supplémentaires, ajoutant généralement entre un cinquième et la moitié de la taille brute.
La formule
Avec vecteurs de dimension , chaque valeur occupant octets, le stockage brut vaut
Sraw=N⋅d⋅bet l'ajout d'un surcoût d'index fractionnaire donne le total :
S=Sraw⋅(1+o)Exemple chiffré
Considérons un stockage de 2 400 000 vecteurs issus d'un modèle de dimension 768, conservés en pleine précision si bien que chaque valeur occupe 4 octets, avec un index HNSW ajoutant 35 pour cent de surcoût. La taille brute est
Sraw=2400000×768×4=7372800000 octets≈7,37 Goet avec l'index,
S=7,37 Go×1,35≈9,95 GoPasser les mêmes vecteurs à la quantification 8 bits, soit 1 octet par valeur, ramènerait la taille brute à environ 1,84 Go et le total à environ 2,49 Go — une réduction par quatre — au prix d'une légère perte de précision dans le calcul des distances.
Notes et variantes
L'estimation ne couvre que les vecteurs et l'index. La plupart des bases de données stockent aussi le fragment de texte d'origine et des métadonnées à côté de chaque vecteur ; pour de courts fragments, cette charge utile peut être comparable au vecteur lui-même, aussi convient-il de l'ajouter séparément lors du dimensionnement total du disque. La réduction de dimension et la quantification sont les deux principaux leviers pour réduire un index : diviser la dimension par deux ou quantifier en int8 réduisent chacun nettement la taille brute avant tout surcoût d'index.
Application
La taille de stockage est l'entrée du coût d'hébergement — une fois connu le nombre de gigaoctets qu'occupe un index, le Calculateur de coût d'une base de données vectorielle le convertit en facture mensuelle. Les vecteurs dimensionnés ici sont produits par l'étape d'embedding tarifée dans le Calculateur de coût d'embeddings, et le nombre de vecteurs découle généralement de la façon dont les documents sources sont découpés.
Questions fréquentes (FAQ)
Pourquoi l'index ajoute-t-il un surcoût ?
Stocker les vecteurs bruts permet de comparer une requête à chaque vecteur, mais ce balayage exhaustif devient lent à grande échelle. Les index du plus proche voisin approché comme HNSW construisent un graphe navigable pour que la recherche ne visite qu'une petite fraction des vecteurs.
Ce graphe stocke des liens vers les voisins pour chaque vecteur, ce qui constitue des données supplémentaires en plus des vecteurs eux-mêmes — couramment 20 à 50 pour cent de plus, selon la densité des connexions du graphe.
Combien la quantification fait-elle économiser ?
Les valeurs d'embedding sont produites en flottants 32 bits, soit 4 octets chacune. Les stocker en flottants 16 bits réduit l'empreinte de moitié, et la quantification en entiers 8 bits la ramène à un quart.
La quantification introduit de petites erreurs d'arrondi dans le calcul des distances, mais pour la recherche, la perte de qualité du classement reste généralement mineure ; int8 est donc un moyen courant de réduire un grand index. Le champ octets par valeur permet de comparer directement les trois options.
Cette estimation inclut-elle les métadonnées et le texte ?
Non. L'estimation couvre uniquement les vecteurs et l'index de recherche. La plupart des bases de données vectorielles stockent aussi le fragment de texte d'origine et des métadonnées telles que les identifiants de document, les titres et les étiquettes à côté de chaque vecteur.
Cette charge utile peut rivaliser avec la taille du vecteur, voire la dépasser pour de courts fragments ; ajoutez-la donc séparément lors du dimensionnement total du disque.
Mentions légales
Il s'agit d'une empreinte approximative pour les vecteurs et l'index. Les bases de données réelles stockent aussi le texte source, les métadonnées et des données de gestion internes, et le surcoût d'un index donné dépend de sa configuration. Considérez le résultat comme une estimation de planification, et non comme une mesure exacte du disque.