• À propos de Milvus
  • Commencer
  • Concepts
  • Guide de l'utilisateur
  • Importation de données
  • Outils d'IA
  • Guide d'administration
  • Outils
  • Intégrations
  • Tutoriels
  • FAQ
  • API Reference

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.