Meilleures pratiques pour le stockage hiérarchiséCompatible with Milvus 2.6.4+
Milvus propose le stockage hiérarchisé pour vous aider à traiter efficacement les données à grande échelle tout en équilibrant la latence des requêtes, la capacité et l'utilisation des ressources. Ce guide résume les configurations recommandées pour les charges de travail typiques et explique le raisonnement qui sous-tend chaque stratégie de réglage.
Avant de commencer
Milvus v2.6.4 ou version ultérieure
Les QueryNodes doivent disposer de ressources locales dédiées (mémoire et disque). Les environnements partagés peuvent fausser l'estimation du cache et conduire à une mauvaise évaluation de l'éviction.
Choisir la bonne stratégie
Le stockage hiérarchisé offre des stratégies de chargement et de mise en cache flexibles qui peuvent être combinées pour s'adapter à votre charge de travail.
Objectif |
Objectif recommandé |
Mécanisme clé |
|---|---|---|
Minimiser la latence de la première requête |
Précharger les champs critiques |
Réchauffement |
Traiter efficacement les données à grande échelle |
Chargement à la demande |
Chargement paresseux + chargement partiel |
Maintenir la stabilité à long terme |
Prévenir le débordement du cache |
Eviction |
Équilibrer les performances et la capacité |
Combiner la précharge et la mise en cache dynamique |
Configuration hybride |
Scénario 1 : recherche en temps réel et à faible latence
Quand utiliser
Le temps de latence des requêtes est critique (par exemple, recommandation en temps réel ou classement des recherches).
Les index vectoriels de base et les filtres scalaires sont fréquemment consultés.
La constance des performances importe plus que la vitesse de démarrage
Configuration recommandée
# milvus.yaml
queryNode:
segcore:
tieredStorage:
warmup:
# scalar field/index warm-up to eliminate first-time latency
scalarField: sync
scalarIndex: sync
# warm-up of vector fields is disabled (if the original vector is not required)
vectorField: disable
# vector indexes warm-up to elminate first-time latenct
vectorIndex: sync
# enable cache eviction, and also turn on background asynchronous eviction
# to reduce the triggering of synchronous eviction.
evictionEnabled: true
backgroundEvictionEnabled: true
memoryLowWatermarkRatio: 0.75
memoryHighWatermarkRatio: 0.8
diskLowWatermarkRatio: 0.75
diskHighWatermarkRatio: 0.8
# no expiration time, which avoids frequent reloading
cacheTtl: 0
Raison d'être
L'échauffement élimine la latence du premier accès pour les index scalaires et vectoriels à haute fréquence.
L'éviction en arrière-plan maintient une pression stable sur le cache sans bloquer les requêtes.
La désactivation du TTL du cache évite les rechargements inutiles pour les données chaudes.
Scénario 2 : analyse hors ligne par lots
Quand utiliser
La tolérance à la latence des requêtes est élevée
Les charges de travail impliquent des ensembles de données massifs ou de nombreux segments.
La capacité et le débit sont prioritaires par rapport à la réactivité.
Configuration recommandée
# milvus.yaml
queryNode:
segcore:
tieredStorage:
enabled: true
warmup:
# disable scalar field/index warm-up to speed up loading
scalarField: disable
scalarIndex: disable
# disable vector field/index warm-up to speed up loading
vectorField: disable
vectorIndex: disable
# enable cache eviction, and also turn on background asynchronous eviction
# to reduce the triggering of synchronous eviction.
evictionEnabled: true
backgroundEvictionEnabled: true
memoryLowWatermarkRatio: 0.7
memoryHighWatermarkRatio: 0.85
diskLowWatermarkRatio: 0.7
diskHighWatermarkRatio: 0.85
# use 1 day expiration to clean unused cache
cacheTtl: 86400
Raison d'être
La désactivation de l'échauffement accélère le démarrage lors de l'initialisation de nombreux segments.
Des filigranes plus élevés permettent une utilisation plus dense du cache, ce qui améliore la capacité de charge totale.
Le TTL du cache nettoie automatiquement les données inutilisées pour libérer de l'espace local.
Scénario 3 : déploiement hybride (mixte en ligne et hors ligne)
Quand utiliser
Un seul cluster sert à la fois les charges de travail en ligne et analytiques.
Certaines collections nécessitent une faible latence, d'autres privilégient la capacité.
Stratégie recommandée
Appliquer la configuration en temps réel aux collections sensibles à la latence
Appliquer la configuration hors ligne aux collections analytiques ou d'archivage
Ajuster les ratios evictableMemoryCacheRatio, cacheTtl et watermark indépendamment pour chaque type de charge de travail.
Raison d'être
La combinaison des configurations permet un contrôle fin de l'allocation des ressources.
Les collections critiques conservent des garanties de faible latence, tandis que les collections secondaires peuvent gérer davantage de segments et de volumes de données.
Conseils de réglage supplémentaires
Aspect |
Recommandation |
Explication |
|---|---|---|
Périmètre d'échauffement |
Ne préchargez que les champs ou les index dont la fréquence de requête est élevée. |
Le préchargement inutile augmente le temps de chargement et l'utilisation des ressources. |
Réglage de l'éviction |
Commencez par les filigranes par défaut (75-80 %) et ajustez-les progressivement. |
Un petit écart entraîne une éviction fréquente ; un grand écart retarde la libération des ressources. |
TTL du cache |
Désactiver pour les ensembles de données stables et chaudes ; activer (par exemple, 1 à 3 jours) pour les données dynamiques. |
Empêche l'accumulation de cache périmé tout en équilibrant la charge de nettoyage. |
Taux de surengagement |
Éviter les valeurs > 0,7, sauf si la marge de manœuvre des ressources est importante. |
Un surengagement excessif peut entraîner un battement du cache et une latence instable. |
Surveillance |
Suivre le taux de réussite du cache, l'utilisation des ressources et la fréquence d'éviction. |
Des charges à froid fréquentes peuvent indiquer que le réchauffement ou les filigranes doivent être ajustés. |