Ein Überblick über das Milvus-Speichersystem und Techniken zur Bewertung und Optimierung seiner Leistung
Willkommen zu unserer Erkundung von Milvus, der Open-Source-Vektordatenbank, die für ihre beeindruckende horizontale Skalierbarkeit und blitzschnelle Leistung bekannt ist. Im Kern von Milvus liegt sein robustes Speichersystem, eine entscheidende Grundlage für zuverlässige Datenpersistenz und Speicherung. Dieses System umfasst mehrere wesentliche Komponenten: Metaspeicher, Log-Broker und Objektspeicher.
Dieser Leitfaden befasst sich mit der Architektur von Milvus, schlüsselt seine wichtigsten Speicherkomponenten auf und untersucht effektive Techniken zur Bewertung ihrer Leistung.
Ein Überblick über die Milvus-Architektur
Milvus verwendet eine verteilte Architektur, die die Trennung von Speicher und Rechenleistung gewährleistet und horizontale Skalierbarkeit für seine Rechenknoten unterstützt. Dieser Aufbau ist in vier zentrale Schichten gegliedert: die Zugriffsschicht, den Koordinatordienst, die Worker-Knoten und den Speicher, die jeweils unabhängig skalierbar und für die Notfallwiederherstellung optimiert sind.
Milvus Architecture Overview.png
Zugriffsschicht: Diese Frontend-Schicht besteht aus zustandslosen Proxys, die Benutzeranfragen verarbeiten und Antworten optimieren und als primäre Benutzeroberfläche des Systems dienen.
Koordinatorschicht: Als zentrale Kommandoeinheit des Systems verwaltet der Koordinatordienst die Aufgabenverteilung, Cluster-Topologie, Lastverteilung und Datenverwaltung über Worker-Knoten hinweg.
Worker-Knoten: Dies sind die Ausführungseinheiten, die Data-Manipulation-Language-(DML-)Befehle unter der Leitung des Koordinatordienstes verarbeiten.
Speicher: Diese für die Datenpersistenz grundlegende Schicht umfasst Metaspeicher, einen Log-Broker und Objektspeicher und gewährleistet Datenintegrität und Verfügbarkeit.
Milvus-Speicherkomponenten
Milvus verwendet drei Hauptspeicherkomponenten, um Datenintegrität und Verfügbarkeit zu gewährleisten: Metaspeicher, Objektspeicher und einen Log-Broker.
Metaspeicher
Der Metaspeicher in Milvus speichert Metadaten-Snapshots wie Collection-Schemata, Knotenstatus und Prüfpunkte für den Nachrichtenkonsum. Aufgrund des Bedarfs an hoher Verfügbarkeit, starker Konsistenz und Transaktionsunterstützung nutzt Milvus etcd als Metaspeicherlösung. Etcd ist ein robuster und verteilter Key-Value-Store, der für die verteilten Systeme innerhalb von Milvus entscheidend ist. Er übernimmt Aufgaben wie Dienstregistrierung und Integritätsprüfungen sowie die Aufbewahrung von Metadaten.
Objektspeicher
Der Objektspeicher in Milvus übernimmt die Speicherung von Log-Snapshot-Dateien, Indexdateien für skalare und Vektordaten sowie Zwischenergebnissen von Abfragen. Milvus integriert MinIO für den Objektspeicher aufgrund seiner hohen Leistung und Kompatibilität mit Kubernetes, was einen nahtlosen Betrieb in Cloud-Umgebungen wie AWS S3 und Azure Blob Storage erleichtert.
Log-Broker
Der Log-Broker in Milvus verwendet ein Pub-Sub-System mit Wiedergabefunktionen. Er ist wesentlich für die Persistenz von Streaming-Daten, die Ausführung zuverlässiger asynchroner Abfragen, Ereignisbenachrichtigungen und die Rückgabe von Abfrageergebnissen. Außerdem stellt er die Integrität inkrementeller Daten während der Wiederherstellung von Worker-Knoten nach Systemausfällen sicher. Je nach Bereitstellung verwendet Milvus unterschiedliche Log-Broker-Tools. Milvus-Cluster-Setups verwenden Pulsar oder Kafka, während eigenständige Milvus-Versionen typischerweise RocksDB verwenden.
Wie man die Leistung des Milvus-Speichers bewertet und optimiert
Die kontinuierliche Bewertung und Verbesserung der Speicherleistung ist entscheidend.
Etcd: Der Metadatenspeicher von Milvus
Etcd ist ein robuster, verteilter Key-Value-Store, der für verteilte Systeme entwickelt wurde. In Milvus ist etcd ein Metadatenspeicher, der wesentliche Daten wie Collection-Schemata, Knotenstatus und Prüfpunkte für den Nachrichtenkonsum speichert.
Die Schreiblatenz der Festplatte ist entscheidend für die Leistung von etcd; eine langsame Festplattengeschwindigkeit kann die Anforderungslatenz erheblich erhöhen und die Systemstabilität gefährden. Wir empfehlen, in Produktionsumgebungen für optimale Leistung mindestens 500 sequenzielle IOPS (Input/Output Operations per Second) dauerhaft bereitzustellen und sicherzustellen, dass 99% der fdatasync-Dauern unter zehn Millisekunden bleiben. Obwohl etcd in der Regel nur eine moderate Festplattenbandbreite benötigt, kann eine Erhöhung dieser Bandbreite die Wiederherstellungszeiten deutlich verkürzen. Daher empfehlen wir für Produktionsumgebungen eine grundlegende Festplattenbandbreite von mindestens 100MB/s.
Um zu überprüfen, ob Ihre Speicherlösung diese Kriterien erfüllt, sollten Sie Leistungsbewertungen mit Fio, einem Tool für Festplatten-Benchmarking, durchführen. Nachfolgend finden Sie eine Anleitung zur Verwendung von Fio zur Bewertung Ihrer Speicherleistung.
Stellen Sie zunächst sicher, dass Fio auf Ihrem System installiert ist. Führen Sie dann den folgenden Befehl aus und geben Sie das Verzeichnis, in dem Ihr Speicher eingehängt ist, als test-data-Verzeichnis an. Dieses Verzeichnis sollte sich unter Ihrem Speicher-Anbindungspunkt befinden.
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest
Prüfen Sie die Ergebnisse, um sicherzustellen, dass 99% der fdatasync-Dauer weniger als 10ms betragen und die Schreib-IOPS höher als 500 sind. Wenn diese Bedingungen erfüllt sind, arbeitet Ihr Speicher angemessen.
Nachfolgend finden Sie ein Beispiel für die Ausgabeergebnisse:
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]
Bei der Bereitstellung eines Milvus-Clusters in Cloud-Umgebungen ist die Auswahl des geeigneten Blockspeichertyps für etcd aufgrund seiner Empfindlichkeit gegenüber Festplattenleistung entscheidend. Cloud-Anbieter bieten verschiedene Blockspeicheroptionen an, jeweils mit unterschiedlichen Leistungsmerkmalen, die für verschiedene Workloads geeignet sind.
Nachfolgend finden Sie die empfohlenen Volume-Typen und Leistungskennzahlen verschiedener Cloud-Anbieter.
| Cloud-Anbieter | Volume-Typ | GRÖSSE | 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 |
Sie können auch Fio verwenden, um zu bestätigen, dass der gewählte Blockspeicher die Leistungsbenchmarks erfüllt, die für die optimale Funktion von etcd innerhalb Ihrer Milvus-Bereitstellung erforderlich sind.
MinIO: Milvus Object Storage Tool
MinIO ist eine leistungsstarke, Kubernetes-native Object-Storage-Lösung, die für Cloud-native Workloads optimiert ist. Milvus nutzt MinIO, um Snapshot-Dateien von Protokollen, Indexdateien für skalare und Vektordaten sowie Zwischenergebnisse von Abfragen zu speichern.
Die Leistung von Object Storage wie MinIO wird in erster Linie anhand des I/O-Durchsatzes und nicht anhand von IOPS gemessen. Diese Kennzahl wirkt sich erheblich auf verschiedene Vorgänge in Milvus aus, wie das Laden von Collections, das Erstellen von Indizes und das Einfügen von Daten. Viele Faktoren beeinflussen die Durchsatzleistung von MinIO, darunter Netzwerkbandbreite, Leistungsoptimierung des Linux-Kernels und die Leistung einzelner Laufwerke. Die Festplattenleistung ist besonders entscheidend.
Wir können den dd-Befehl verwenden, um die Leistung eines einzelnen Laufwerks zu messen. DD ist ein Unix-Tool, das Daten Bit für Bit von einer Datei in eine andere kopiert. Es bietet verschiedene Optionen zur Steuerung der Blockgröße jedes Lese- und Schreibvorgangs.
Im folgenden Beispiel erzeugt die Option O_DIRECT für 64 Durchläufe beim Testen eines einzelnen NVMe-Laufwerks mit einer Blockgröße von 16 MB eine Schreibleistung von über 2 GB pro Sekunde und Laufwerk.
$ 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
Im selben Beispiel erzeugt die Option O_DIRECT für 64 Durchläufe beim Testen eines einzelnen NVMe-Laufwerks mit einer Blockgröße von 16 MB eine Leseleistung von über 5 GB pro Sekunde und Laufwerk.
$ 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
Je höher die Lese- und Schreibleistung Ihres Laufwerks ist, desto besser ist die Gesamtdurchsatzleistung von MinIO. Wir empfehlen, SSD- oder NVMe-Laufwerke als Speichermedien in einer MinIO-Konfiguration zu verwenden, um optimale Ergebnisse zu erzielen. Diese Laufwerke können die hohen Durchsatzanforderungen der MinIO-Operationen effektiv unterstützen. Vermeiden Sie die Verwendung von SAN/NAS-Appliances für MinIO-Speicher. Solche Konfigurationen führen häufig zu Parallelitätsproblemen und Leistungsengpässen, die die Effizienz und Reaktionsfähigkeit des Systems beeinträchtigen können.
Pulsar/Kafka: Milvus Log Broker Tools
Wie oben erwähnt, verwendet Milvus verschiedene Log-Broker-Tools, die auf bestimmte Bereitstellungsmodi zugeschnitten sind. Milvus-Cluster-Konfigurationen verwenden Pulsar oder Kafka, während eigenständige Milvus-Versionen typischerweise RocksDB verwenden.
Sowohl Pulsar als auch Kafka sind darauf ausgelegt, persistente Nachrichtenspeicherung zu unterstützen und einen hohen Durchsatz für Nachrichtenkonsumenten bereitzustellen. Ihre Leistung hängt entscheidend von der Art des verwendeten Festplattenspeichers ab, da sie auf sequenziellen Festplatten-I/O-Operationen basieren.
Für Pulsar sind leistungsstarke Festplatten für die Journaldateien von BookKeeper unerlässlich, um Datenintegrität und Dauerhaftigkeit sicherzustellen, wobei SSDs mit niedriger Latenz für diesen Zweck sehr vorteilhaft sind. Sowohl Pulsar Ledgers als auch Kafka sind auf Festplatteneffizienz optimiert, nutzen den Dateisystem-Cache und erzielen gute Leistung mit HDDs und SSDs. Für latenzempfindliche Anwendungen oder groß angelegte Bereitstellungen bieten SSDs jedoch erhebliche Leistungsvorteile.
Verwenden Sie zur Leistungsoptimierung mehrere Festplattengeräte für Pulsar und Kafka. Insbesondere bei Pulsar ermöglicht die Verwendung separater Festplatten für das Journal und den allgemeinen Speicher den Bookies, die Latenz von Schreibvorgängen von Lesevorgängen zu isolieren. Um optimale Latenz zu gewährleisten, verwenden Sie nicht dieselben Laufwerke zum Speichern von Daten, Anwendungsprotokollen oder für andere OS-Dateisystemaktivitäten. Diese Laufwerke können mithilfe von RAID als einzelnes Volume konfiguriert werden, oder jedes Laufwerk kann formatiert und als eigenes Verzeichnis eingebunden werden. Network-attached Storage (NAS) sollte aufgrund seiner geringeren Leistung, höheren und stärker variierenden Latenzen sowie seines Potenzials als Single Point of Failure vermieden werden.
Zusammenfassung
Unsere eingehende Untersuchung des Milvus-Speichersystems bietet umfassende Einblicke in seine Architektur und Komponenten und hebt deren Rollen bei der Unterstützung von Datenmanagement und -analyse in großem Maßstab hervor. Wir haben die drei primären Speicherkomponenten von Milvus – Metaspeicher, Objektspeicher und Log-Broker – analysiert und Strategien zur Bewertung und Verbesserung ihrer Leistung bereitgestellt.
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.
Weiterlesen
Announcing the General Availability of Zilliz Cloud BYOC on Google Cloud Platform
Zilliz Cloud BYOC on GCP offers enterprise vector search with full data sovereignty and seamless integration.
Vector Databases vs. Graph Databases
Use a vector database for AI-powered similarity search; use a graph database for complex relationship-based queries and network analysis.
OpenAI o1: What Developers Need to Know
In this article, we will talk about the o1 series from a developer's perspective, exploring how these models can be implemented for sophisticated use cases.