Présentation du système de stockage de Milvus et des techniques pour évaluer et optimiser ses performances
Bienvenue dans notre exploration de Milvus, la base de données vectorielle open source connue pour son impressionnante scalabilité horizontale et ses performances ultrarapides. Au cœur de Milvus se trouve son système de stockage robuste, une fondation essentielle pour une persistance et un stockage fiables des données. Ce système comprend plusieurs composants essentiels : le stockage des métadonnées, le courtier de journaux et le stockage d’objets.
Ce guide se penchera sur l’architecture de Milvus, détaillera ses principaux composants de stockage et explorera des techniques efficaces pour évaluer leurs performances.
Un aperçu de l’architecture de Milvus
Milvus adopte une architecture distribuée qui garantit la séparation du stockage et du calcul et prend en charge la scalabilité horizontale de ses nœuds de calcul. Cette configuration est organisée en quatre couches clés : la couche d’accès, le service de coordination, les nœuds de travail et le stockage, chacune étant évolutive de manière indépendante et optimisée pour la reprise après sinistre.
Milvus Architecture Overview.png
Couche d’accès : Cette couche front-end se compose de proxys sans état qui traitent les requêtes des utilisateurs et optimisent les réponses, servant d’interface utilisateur principale du système.
Couche de coordination : Agissant comme le centre de commandement du système, le service de coordination gère la distribution des tâches, la topologie du cluster, l’équilibrage de charge et la gestion des données entre les nœuds de travail.
Nœuds de travail : Ce sont les exécuteurs qui traitent les commandes du langage de manipulation de données (DML) sous la direction du service de coordination.
Stockage : Essentielle à la persistance des données, cette couche inclut le stockage des métadonnées, un courtier de journaux et le stockage d’objets, garantissant l’intégrité et la disponibilité des données.
Composants de stockage de Milvus
Milvus utilise trois principaux composants de stockage pour garantir l’intégrité et la disponibilité des données : le stockage des métadonnées, le stockage d’objets et un courtier de journaux.
Stockage des métadonnées
Le stockage des métadonnées dans Milvus conserve des instantanés de métadonnées, tels que les schémas de collections, les statuts des nœuds et les points de contrôle de consommation des messages. Compte tenu du besoin de haute disponibilité, de forte cohérence et de prise en charge des transactions, Milvus utilise etcd comme solution de stockage des métadonnées. Etcd est un magasin clé-valeur distribué et robuste, crucial pour les systèmes distribués au sein de Milvus. Il gère des tâches telles que l’enregistrement des services et les contrôles d’intégrité, en plus de la préservation des métadonnées.
Stockage d’objets
Le stockage d’objets dans Milvus gère le stockage des fichiers d’instantanés de journaux, des fichiers d’index pour les données scalaires et vectorielles, ainsi que des résultats de requêtes intermédiaires. Milvus intègre MinIO pour le stockage d’objets en raison de ses performances élevées et de sa compatibilité avec Kubernetes, facilitant une exploitation fluide dans des environnements cloud comme AWS S3 et Azure Blob Storage.
Courtier de journaux
Le courtier de journaux dans Milvus adopte un système pub-sub avec des capacités de relecture. Il est essentiel pour la persistance des données en streaming, l’exécution de requêtes asynchrones fiables, les notifications d’événements et le renvoi des résultats de requêtes. Il garantit également l’intégrité des données incrémentales lors de la récupération des nœuds de travail après des pannes système. Selon le déploiement, Milvus utilise différents outils de courtier de journaux. Les configurations Milvus Cluster utilisent Pulsar ou Kafka, tandis que les versions autonomes de Milvus utilisent généralement RocksDB.
Comment évaluer et optimiser les performances du stockage de Milvus
Évaluer et améliorer constamment les performances de stockage est crucial.
Etcd : le magasin de métadonnées de Milvus
Etcd est un magasin clé-valeur distribué et robuste, conçu pour les systèmes distribués. Dans Milvus, etcd est un magasin de métadonnées qui stocke des données essentielles telles que les schémas de collections, les statuts des nœuds et les points de contrôle de consommation des messages.
La latence d’écriture disque est essentielle pour les performances d’etcd ; une vitesse de disque lente peut augmenter considérablement la latence des requêtes et mettre en péril la stabilité du système. Nous recommandons de maintenir au moins 500 IOPS séquentielles (opérations d’entrée/sortie par seconde) pour des performances optimales dans les environnements de production, en veillant à ce que 99 % des durées de fdatasync restent inférieures à dix millisecondes. Bien qu’etcd ne nécessite généralement qu’une bande passante disque modérée, l’augmentation de cette bande passante peut réduire considérablement les temps de récupération. Par conséquent, nous recommandons une bande passante disque de référence d’au moins 100MB/s pour les environnements de production.
Pour vérifier si votre solution de stockage répond à ces critères, envisagez de réaliser des évaluations de performances à l’aide de Fio, un outil de benchmarking de disque. Vous trouverez ci-dessous un guide sur l’utilisation de Fio pour évaluer les performances de votre stockage.
Tout d’abord, assurez-vous que Fio est installé sur votre système. Ensuite, exécutez la commande suivante, en spécifiant le répertoire où votre stockage est monté comme répertoire test-data. Ce répertoire doit se trouver sous votre point de connexion de stockage.
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest
Examinez les résultats pour vous assurer que 99 % de la durée de fdatasync est inférieure à 10 ms et que les IOPS d’écriture sont supérieures à 500. Si ces conditions sont remplies, votre stockage offre des performances adéquates.
Voici un exemple des résultats de sortie :
Jobs: 1 (f=1): [W(1)][100.0%][w=1771KiB/s][w=788 IOPS][eta 00m:00s]
mytest: (groupid=0, jobs=1): err= 0: pid=703: Mon Jul 25 08:36:48 2022
write: IOPS=967, BW=2173KiB/s (2225kB/s)(220MiB/103664msec); 0 zone resets
clat (nsec): min=1903, max=29662k, avg=287307.76, stdev=492386.04
lat (nsec): min=1981, max=29662k, avg=287583.67, stdev=492438.10
clat percentiles (usec):
| 1.00th=[ 3], 5.00th=[ 4], 10.00th=[ 4], 20.00th=[ 5],
| 30.00th=[ 6], 40.00th=[ 9], 50.00th=[ 233], 60.00th=[ 343],
| 70.00th=[ 437], 80.00th=[ 553], 90.00th=[ 701], 95.00th=[ 742],
| 99.00th=[ 1172], 99.50th=[ 2114], 99.90th=[ 6390], 99.95th=[ 8455],
| 99.99th=[15533]
bw ( KiB/s): min= 1630, max= 2484, per=100.00%, avg=2174.66, stdev=193.65, samples=207
iops : min= 726, max= 1106, avg=968.37, stdev=86.19, samples=207
lat (usec) : 2=0.03%, 4=16.49%, 10=27.68%, 20=3.21%, 50=0.71%
lat (usec) : 100=0.27%, 250=2.65%, 500=24.64%, 750=20.40%, 1000=2.57%
lat (msec) : 2=0.82%, 4=0.30%, 10=0.18%, 20=0.03%, 50=0.01%
fsync/fdatasync/sync_file_range:
sync (usec): min=309, max=21848, avg=741.93, stdev=489.64
sync percentiles (usec):
| 1.00th=[ 392], 5.00th=[ 437], 10.00th=[ 474], 20.00th=[ 529],
| 30.00th=[ 578], 40.00th=[ 619], 50.00th=[ 660], 60.00th=[ 709],
| 70.00th=[ 742], 80.00th=[ 791], 90.00th=[ 988], 95.00th=[ 1369],
| 99.00th=[ 2442], 99.50th=[ 3523], 99.90th=[ 6915], 99.95th=[ 8586],
| 99.99th=[11994]
Lors du déploiement d’un cluster Milvus dans des environnements cloud, le choix du type approprié de stockage en mode bloc pour etcd est crucial en raison de sa sensibilité aux performances du disque. Les fournisseurs cloud proposent diverses options de stockage en mode bloc, chacune présentant des caractéristiques de performance distinctes adaptées à différentes charges de travail.
Vous trouverez ci-dessous les types de volumes et les métriques de performance recommandés par différents fournisseurs cloud.
| Fournisseur cloud | Type de volume | TAILLE | IOPS | P99 sync |
| AWS | gp3 | 20Gi | 660 | 4.3ms |
| GCP | pd-ssd | 20Gi | 1262 | 1.3ms |
| Azure | PremiumV2 | 20Gi | 705 | 2.6ms |
| Aliyun | cloud_essd | 20Gi | 1137 | 3.5ms |
Vous pouvez également utiliser Fio pour confirmer que le stockage en blocs choisi respecte les critères de performance nécessaires au fonctionnement optimal d’etcd au sein de votre déploiement Milvus.
MinIO : outil de stockage objet de Milvus
MinIO est une solution de stockage objet haute performance, native Kubernetes, optimisée pour les charges de travail cloud-native. Milvus utilise MinIO pour stocker les fichiers d’instantanés des journaux, les fichiers d’index pour les données scalaires et vectorielles, ainsi que les résultats de requêtes intermédiaires.
Les performances d’un stockage objet comme MinIO sont principalement évaluées par le débit d’E/S plutôt que par les IOPS. Cette métrique a un impact significatif sur diverses opérations dans Milvus, telles que le chargement des collections, la construction des index et l’insertion de données. De nombreux facteurs influencent les performances de débit de MinIO, notamment la bande passante réseau, l’optimisation des performances du noyau Linux et les performances des disques individuels. Les performances des disques sont particulièrement cruciales.
Nous pouvons utiliser la commande dd pour mesurer les performances d’un disque unique. DD est un outil Unix qui copie les données d’un fichier à un autre bit par bit. Il fournit diverses options pour contrôler la taille de bloc de chaque lecture et écriture.
Dans l’exemple ci-dessous, lors du test d’un seul disque NVMe avec une taille de bloc de 16 Mo, l’option O_DIRECT pour 64 comptes génère une performance d’écriture dépassant 2 Go par seconde et par disque.
$ dd if=/dev/zero of=/mnt/drive/test bs=16M count=64 oflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.443096 s, 2.4 GB/s
Dans le même exemple, lors du test d’un seul disque NVMe avec une taille de bloc de 16 Mo, l’option O_DIRECT pour 64 comptes génère une performance de lecture dépassant 5 Go par seconde et par disque.
$ dd of=/dev/null if=/mnt/drive/test bs=16M count=64 iflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.187263 s, 5.7 GB/s
Plus les performances de lecture et d’écriture de votre disque sont élevées, meilleures sont les performances globales de débit de MinIO. Nous recommandons d’utiliser des disques de type SSD ou NVMe comme disques de stockage dans une configuration MinIO pour des résultats optimaux. Ces disques peuvent prendre en charge efficacement les exigences de haut débit des opérations de MinIO. Évitez d’utiliser des appliances SAN/NAS pour le stockage MinIO. De telles configurations introduisent souvent des problèmes de concurrence et des goulots d’étranglement de performance susceptibles de dégrader l’efficacité et la réactivité du système.
Pulsar/Kafka : outils de courtage de journaux de Milvus
Comme mentionné ci-dessus, Milvus utilise différents outils de courtage de journaux adaptés à des modes de déploiement spécifiques. Les configurations Milvus Cluster utilisent Pulsar ou Kafka, tandis que les versions autonomes de Milvus utilisent généralement RocksDB.
Pulsar et Kafka sont tous deux conçus pour prendre en charge le stockage persistant des messages et fournir un débit élevé aux consommateurs de messages. Leurs performances dépendent de manière critique du type de stockage disque utilisé, car ils s’appuient sur des opérations d’E/S disque séquentielles.
Pour Pulsar, des disques haute performance sont essentiels pour les fichiers journal de BookKeeper afin de garantir l’intégrité et la durabilité des données, les SSD à faible latence étant particulièrement bénéfiques à cette fin. Les Ledgers Pulsar et Kafka sont tous deux optimisés pour l’efficacité disque, en utilisant le cache du système de fichiers et en offrant de bonnes performances avec les HDD et les SSD. Cependant, pour les applications sensibles à la latence ou les déploiements à grande échelle, les SSD offrent des avantages significatifs en matière de performance.
Pour optimiser les performances, utilisez plusieurs périphériques de disque pour Pulsar et Kafka. Plus précisément, pour Pulsar, l’utilisation de disques séparés pour le journal et le stockage général permet aux bookies d’isoler la latence des opérations d’écriture de celle des opérations de lecture. Pour garantir une latence optimale, n’utilisez pas les mêmes disques pour stocker les données, les journaux applicatifs ou d’autres activités du système de fichiers de l’OS. Ces disques peuvent être configurés comme un volume unique à l’aide de RAID, ou chaque disque peut être formaté et monté comme son propre répertoire. Le stockage en réseau (NAS) doit être évité en raison de ses performances plus lentes, de ses latences plus élevées et plus variables, et de son potentiel en tant que point de défaillance unique.
Résumé
Notre exploration approfondie du système de stockage Milvus offre des informations complètes sur son architecture et ses composants, mettant en évidence leurs rôles dans la prise en charge de la gestion et de l’analyse de données à grande échelle. Nous avons disséqué les trois principaux composants de stockage de Milvus — le stockage des métadonnées, le stockage d’objets et le courtier de journaux — et fourni des stratégies pour évaluer et améliorer leurs performances.
Fendy FengFendy Feng is the Technical Marketing Writer at Zilliz. She has extensive experience developing and enhancing the impact of open-source projects in various global markets by producing high-quality, tailored content. Before joining Zilliz, Fendy worked as a Content Strategist at PingCAP, a fast-growing E-Series startup renowned for its open-source distributed SQL database.
Jay ZhuJay Zhu is the Senior Software Engineer and tech leader of the DevOps & Infrastructure team at Zilliz. He specializes in DevOps, cloud-native technologies, and Kubernetes projects. Additionally, Jay is actively involved in developing and maintaining various open-source projects, including Milvus, Milvus-helm, and Milvus-operator.
Continuer à lire
How Zilliz Saw the Future of Vector Databases—and Built for Production
An inside look at how Zilliz built vector databases for real-world use, focusing on scalability, stability, and running them reliably at scale.
Milvus/Zilliz + Surveillance: How Vector Databases Transform Multi-Camera Tracking
See how Milvus vector database enhances multi-camera tracking with similarity-based matching for better surveillance in retail, warehouses and transport hubs.
Building RAG Pipelines for Real-Time Data with Cloudera and Milvus
explore how Cloudera can be integrated with Milvus to effectively implement some of the key functionalities of RAG pipelines.