Stockage V3Compatible with Milvus 3.0.x

Présentation

Les ensembles de données d’IA évoluent souvent après la création d’une collection. À mesure que les modèles et les workflows changent, les équipes peuvent avoir besoin d’ajouter du texte, de générer de nouveaux champs vectoriels pour des entités existantes ou d’utiliser des données stockées en dehors de Milvus. La prise en charge de ces workflows nécessite un modèle de stockage capable d’évoluer avec l’ensemble de données.

Le stockage V3 fournit ce modèle dans Milvus 3.0. Il utilise une structure de stockage versionnée pour intégrer les données ajoutées ou réécrites au fil du temps, tandis que les applications continuent d’accéder aux collections via les mêmes API Milvus.

Le stockage V3 est désactivé par défaut. Une fois l’ common.storage.useLoonFFI e prise en compte, les nouvelles écritures et les résultats de la compaction utilisent le stockage V3. Les données existantes conservent leur structure actuelle jusqu’à ce que les données éligibles soient réécrites par la compaction en arrière-plan. Milvus peut lire les deux structures pendant cette transition. Activez le stockage V3 pour utiliser les fonctionnalités qui en dépendent, plutôt que dans le but d’une optimisation générale des performances.

Formats de données dans Storage V3

Storage V3 utilise des manifestes pour décrire les données d’une collection indépendamment du format de données sous-jacent. Cela permet à la même couche de stockage de fonctionner à la fois avec les données gérées par Milvus et celles qui restent dans un système externe.

Formats de fichiers des collections gérées

Pour les collections gérées, l’option « dataNode.storage.format » (Utiliser le format de fichier de la collection) sélectionne le format de fichier pour les nouvelles données de Storage V3. Ce paramètre prend en charge les valeurs suivantes :

Format Description

parquet Format de fichier en colonnes par défaut, largement adopté, offrant une grande compatibilité avec l’écosystème et des outils éprouvés. Parquet organise les données en groupes de lignes et prend en charge l’encodage et la compression par colonne, ce qui permet à Milvus de ne lire que les colonnes requises et de traiter efficacement les balayages séquentiels de grande envergure.

vortex Un format de fichier en colonnes optionnel de nouvelle génération, basé sur des encodages extensibles et modulables ainsi que sur des statistiques riches. Dans Milvus, Vortex prend en charge la projection de colonnes, les lectures par plage et les lectures en accès aléatoire. Ces fonctionnalités permettent de réduire les lectures de données superflues pour les charges de travail adaptées.

Format	Description
`parquet`	Format de fichier en colonnes par défaut, largement adopté, offrant une grande compatibilité avec l’écosystème et des outils éprouvés. Parquet organise les données en groupes de lignes et prend en charge l’encodage et la compression par colonne, ce qui permet à Milvus de ne lire que les colonnes requises et de traiter efficacement les balayages séquentiels de grande envergure.
`vortex`	Un format de fichier en colonnes optionnel de nouvelle génération, basé sur des encodages extensibles et modulables ainsi que sur des statistiques riches. Dans Milvus, Vortex prend en charge la projection de colonnes, les lectures par plage et les lectures en accès aléatoire. Ces fonctionnalités permettent de réduire les lectures de données superflues pour les charges de travail adaptées.

La modification de l’ dataNode.storage.format e affecte les nouvelles écritures dans Storage V3. Les fichiers existants conservent leur format actuel jusqu’à ce que la compaction réécrive les segments correspondants. La plupart des déploiements devraient conserver le format par défaut « parquet », à moins que des tests de performance représentatifs ne démontrent que « vortex » est mieux adapté à leurs données et à leurs modèles d’accès.

Collections externes et formats source pris en charge

Les collections externes permettent à Milvus d’utiliser des données stockées dans des fichiers ou des tables externes. Storage V3 prend en charge les formats de source externes suivants :

Format	Catégorie	Source attendue	Prise en charge par Storage V3
`parquet`	Format de fichier	Un répertoire ou un préfixe de stockage d'objets contenant des fichiers Parquet.	Détecte les fichiers, lit leurs métadonnées et leurs groupes de lignes, puis les enregistre dans un manifeste Storage V3.
`vortex`	Format de fichier	Un répertoire ou un préfixe de stockage d'objets contenant des fichiers Vortex.	Détecte les fichiers et utilise la structure et les statistiques Vortex pour la projection, les lectures par plage et les lectures en accès aléatoire.
`lance-table`	Format de table	Un répertoire de jeu de données Lance.	Lit les métadonnées du jeu de données et mappe ses fragments dans un manifeste Storage V3.
`iceberg-table`	Format de table	Un fichier JSON de métadonnées Iceberg et un ID d’instantané.	Résout l’instantané spécifié, planifie ses fichiers de données et conserve les métadonnées de suppression par position. Les suppressions par égalité ne sont pas prises en charge et doivent être converties en suppressions par position avant l’actualisation de la collection externe.

Les sources externes sont en lecture seule. Storage V3 crée et actualise son propre manifeste sans modifier ni copier les données sources. Milvus peut alors créer des index et effectuer des recherches et des requêtes sur les données via une collection externe.

Stockage dans le cloud et authentification inter-comptes

Le tableau suivant décrit uniquement la manière dont une collection externe accède aux données sources stockées dans un autre compte cloud. Il ne décrit pas le stockage d’objets utilisé pour les données gérées par Milvus.

Stockage dans le cloud	Formats externes pris en charge	Authentification inter-comptes pour les collections externes
Amazon S3	Les quatre formats répertoriés ci-dessus.	Spécifiez l’ARN du rôle IAM appartenant au client. Storage V3 utilise l’ `AssumeRole` AWS STS pour obtenir des identifiants temporaires et les actualise si nécessaire. Vous pouvez également fournir un identifiant externe lorsque la politique de confiance du rôle l’exige.
Google Cloud Storage (GCS)	Les quatre formats indiqués ci-dessus.	Spécifiez le compte de service cible. Storage V3 se fait passer pour ce compte de service, utilise ses jetons d’accès OAuth à durée de vie limitée pour accéder au compartiment source et actualise les jetons avant leur expiration.
Azure Blob Storage	`parquet`, `vortex` et `lance-table`. Le format `iceberg-table` n’est pas pris en charge.	Milvus demande des informations d’identification SAS à durée de vie limitée via le service gRPC privé `milvus-tools`. Storage V3 utilise ces informations d’identification SAS pour accéder au conteneur source, et celles-ci sont renouvelées avant leur expiration.
Azure Data Lake Storage Gen2 (ADLS Gen2)	Les quatre formats mentionnés ci-dessus.	Milvus demande des identifiants SAS à durée de vie limitée via le service gRPC privé `milvus-tools`. Storage V3 utilise ces identifiants SAS pour accéder au conteneur source, et ceux-ci sont renouvelés avant leur expiration.
Alibaba Cloud Object Storage Service (OSS)	Les quatre formats répertoriés ci-dessus.	Spécifiez l’ARN du rôle RAM appartenant au client. Storage V3 endosse ce rôle à l’aide de l’identité de charge de travail du runtime ou du rôle RAM ECS, puis utilise des informations d’identification temporaires pour accéder au compartiment source.

Pour obtenir des instructions sur la configuration et l’utilisation de la collecte externe, consultez la section Créer une collecte externe.

Fonctionnalités nécessitant Storage V3

Fonctionnalité	Description	Configuration requise
Format de fichier Vortex	Écriture de nouvelles données de collection gérée au format de fichier Vortex.	`common.storage.useLoonFFI=true` `dataNode.storage.format=vortex`
`TEXT` champ	Stockez du texte source long, tel que des passages, des documents, des tickets ou des journaux, sans définir de longueur maximale fixe dans le schéma de la collection.	`common.storage.useLoonFFI=true`
Champs vectoriels générés par une fonction	Ajoutez une fonction BM25 ou MinHash à une collection existante afin que Milvus génère un nouveau champ vectoriel à partir d’un champ d’ `VARCHAR` s existant. Milvus remplit les valeurs générées pour les entités existantes de manière asynchrone via une compaction en arrière-plan.	`common.storage.useLoonFFI=true` `dataCoord.compaction.bumpSchemaVersion.enabled=true` `dataCoord.compaction.storageVersion.enabled=true`
Collections externes	Interrogez des données stockées en dehors de Milvus sans les copier dans une collection gérée. Actualisez la collection externe lorsque les données source changent. Pour exposer des champs source supplémentaires, consultez la section Modifier le schéma d’une collection externe.	`common.storage.useLoonFFI=true`

Avant d’activer Storage V3

Une fois que Milvus a écrit des données dans Storage V3, la rétrogradation vers une version de Milvus incapable de lire Storage V3 n’est pas prise en charge. La désactivation ultérieure de Storage V3 ne convertit pas immédiatement toutes les données Storage V3 existantes et ne rétablit pas la compatibilité avec l’ancienne version.

Avant d’activer Storage V3, tenez compte des comportements suivants des données :

dataCoord.compaction.storageVersion.enabled étant activé par défaut, les données existantes éligibles peuvent migrer progressivement vers Storage V3 via un processus de compaction en arrière-plan.
La désactivation de Storage V3 modifie la version de stockage cible pour les futures écritures et les résultats de compaction éligibles. Elle ne convertit pas de manière synchrone toutes les données Storage V3 existantes et ne garantit pas la sécurité d’un retour à une version antérieure.

Activer Storage V3

Définissez « common.storage.useLoonFFI » sur « true » dans votre configuration Milvus :

common:
  storage:
    useLoonFFI: true

Milvus considère ce paramètre comme actualisable. Appliquez la modification via le workflow de mise à jour de la configuration pris en charge par votre déploiement. La simple modification d’un fichier de configuration statique ne garantit pas que le déploiement en cours d’exécution ait bien reçu la nouvelle valeur.

Si vous prévoyez d’ajouter une fonction et son champ vectoriel généré à une collection existante, activez également les deux paramètres de compactage requis pour le remplissage des données existantes :

dataCoord:
  compaction:
    bumpSchemaVersion:
      enabled: true
    storageVersion:
      enabled: true

La sortie de la fonction pour les entités existantes est générée de manière asynchrone via une compaction en arrière-plan. Une mise à jour réussie du schéma ne signifie pas que le remplissage des données existantes est terminé pour toutes les entités existantes.