Comprendre l'utilisation mémoire

Qdrant fonctionne avec deux types de mémoire :

• Mémoire résidente (aka RSSAnon) - mémoire utilisée pour les structures de données internes comme le suivi des IDs, plus les composants qui doivent rester en RAM, comme les vecteurs quantifiés quand always_ram=true et les index de payload.

• OS page cache - mémoire utilisée pour mettre en cache les lectures disque, qui peut être libérée si nécessaire. Les vecteurs originaux sont normalement stockés dans le page cache, de sorte que le service ne s'arrêtera pas si la RAM est pleine, mais les performances peuvent se dégrader.

Il est normal que le OS page cache occupe toute la RAM disponible, mais si la mémoire résidente dépasse 80 % de la RAM totale, c'est le signe d'un problème.

Surveillance de l'utilisation mémoire

• Qdrant expose l'utilisation mémoire via l'endpoint /metrics. Voir Documentation Monitoring.

<!-- ToDo: Talk about memory usage of each components once API is available -->

Combien de mémoire est nécessaire pour Qdrant ?

L'utilisation mémoire optimale dépend du cas d'usage.

• Pour les scénarios de recherche réguliers, des directives générales sont fournies dans la Documentation Capacity planning.

Pour une ventilation détaillée de l'utilisation mémoire à grande échelle, voir Large scale memory usage example.

Les index de payload et le graphe HNSW requièrent également de la mémoire, ainsi que les vecteurs eux-mêmes, il est donc important de les considérer dans les calculs.

De plus, Qdrant nécessite un peu de mémoire supplémentaire pour les optimisations. Lors de l'optimisation, les segments optimisés sont entièrement chargés en RAM, il est donc important de laisser suffisamment de marge. Plus la valeur de max_segment_size est grande, plus la marge nécessaire est importante.

Quand placer l'index HNSW sur le disque

Placer sur le disque des composants fréquemment utilisés (comme l'index HNSW) peut causer une dégradation significative des performances. Il existe cependant certains scénarios où cela peut être une bonne option :

• Déploiements avec disques à faible latence - NVMe local ou similaire.
• Déploiements multi-tenant, où seul un sous-ensemble de tenants est fréquemment accédé, de sorte que seulement une fraction des données et de l'index est chargée en RAM à la fois.
• Pour les déploiements avec inline storage activé.

Comment réduire l'empreinte mémoire

Le principal défi est de placer sur le disque les parties de données qui sont rarement accédées. Voici les principales techniques pour y parvenir :

• Utilisez la quantification pour stocker uniquement les vecteurs compressés en RAM Documentation Quantization

• Utilisez les types de données float16 ou int8 pour réduire l'utilisation mémoire des vecteurs de 2x ou 4x respectivement, avec un certain compromis en précision. En savoir plus sur les types de données vectoriels dans la documentation

• Tirez parti de Matryoshka Representation Learning (MRL) pour stocker uniquement les petits vecteurs en RAM tout en gardant les grands vecteurs sur le disque. Exemples d'utilisation de MRL avec Qdrant Cloud inference : Documentation MRL

• Pour les déploiements multi-tenant avec de petits tenants, les vecteurs peuvent être stockés sur le disque car les données du même tenant sont stockées ensemble Documentation Multitenancy

• Pour les déploiements avec stockage local rapide et des exigences relativement faibles en débit de recherche, il peut être possible de stocker tous les composants du vector store sur le disque. En savoir plus sur les implications de performance du stockage sur disque dans l'article

• Pour les environnements avec peu de RAM, envisagez la configuration async_scorer, qui active le support de io_uring pour l'accès parallèle au disque, ce qui peut améliorer significativement les performances du stockage sur disque. En savoir plus sur async_scorer dans l'article (uniquement disponible sur Linux avec kernel 5.11+)

• Envisagez de stocker les Sparse Vectors et le text payload sur le disque, car ils sont généralement plus adaptés au disque que les vecteurs denses.

• Configurez les index de payload pour être stockés sur le disque documentation

• Configurez les vecteurs creux pour être stockés sur le disque documentation