Milvus-Referenzarchitekturen
Dieser Blog behandelt einige häufig gestellte Fragen zur Milvus-Ressourcenzuweisung basierend auf spezifischen Anwendungsfällen. Zu diesen Fragen gehören:
Wie viele CPU- und Speicherressourcen werden für Milvus benötigt, basierend auf einer bestimmten Anzahl von Benutzern oder Anfragen pro Sekunde (RPS)?
Wie viele CPU- und Speicherressourcen werden für Milvus benötigt, basierend auf unterschiedlichen Mischungen von READ und WRITE?
Verstehen Ihrer Workload-Eigenschaften
Der erste Schritt bei der Zuweisung von Ressourcen zu Milvus besteht darin, Ihre Workload-Eigenschaften zu verstehen. Diese Faktoren spielen eine entscheidende Rolle bei der Bestimmung der Rechenleistung und Speicheranforderungen von Milvus.
Nachfolgend finden Sie eine Beispielliste von Linux-Paket-basierten Referenzarchitekturen, wobei RPS Anfragen pro Sekunde bedeutet:
Bis zu 20 RPS oder 1.000 Benutzer API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS
Bis zu 40 RPS oder 2.000 Benutzer API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS
Bis zu 60 RPS oder 3.000 Benutzer API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
Bis zu 100 RPS oder 5.000 Benutzer API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS
Bis zu 200 RPS oder 10.000 Benutzer API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS
Bis zu 500 RPS oder 25.000 Benutzer API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS
Bis zu 1000 RPS oder 50.000 Benutzer API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS
Abschätzung der Ressourcenanforderungen
Um die Ressourcenanforderungen für Milvus abzuschätzen, müssen wir einige Annahmen treffen:
Lesevorgänge: Jede Webanfrage und jeder Git-Pull ist eine READ-Operation.
Schreibvorgänge: Jeder Git-Push wird als WRITE-Operation betrachtet.
Volumen und Verhältnis von Lese-/Schreibvorgängen: Es wird angenommen, dass Milvus dem Lese-/Schreibverhältnis der API-Aufrufe pro Benutzeranzahl entspricht.
Abfragen pro Sekunde (QPS): müssen der API-RPS-Anforderung (Anfragen pro Sekunde) pro Benutzeranzahl entsprechen.
Wir müssen außerdem die Datengröße pro Lese-/Schreibanforderung abschätzen. Wir nehmen einen gängigen GenAI-Anwendungsfall an:
Vektordimension: 1024 Gleitkommazahlen
Größe in Bytes pro Gleitkommazahl: 4 KB
Top_k (Anzahl der zurückgegebenen Vektoren): 10 Vektoren pro Suchanfrage
Größe einer Collection (Datenbanktabelle): 1 Million Vektoren pro Schreibanforderung
Datenbank-Indextyp: HNSW
Basierend auf diesen Annahmen können wir eine Überschlagsrechnung durchführen, um die Datengröße pro Lese- oder Schreibvorgang abzuschätzen. Nehmen wir an, die Vektordimension beträgt 1024 und jeder Vektor benötigt 1024 * 4 Bytes = 4 KB. Nehmen wir einen typischen top_k = 10 Vektoren pro Lesevorgang an. Mit diesen Annahmen:
Jede Milvus-READ-Operation verarbeitet etwa 40 KB Daten.
Jede Milvus-WRITE-Operation umfasst schätzungsweise 40 MB Daten.
Milvus bietet sowohl Insert- (Erstellen einer vollständig neuen Collection) als auch Upsert-Funktionalitäten (Ändern einiger Zeilen) (Weitere Informationen finden Sie im Blog Milvus insert, upsert, delete). Wir überschätzen jede WRITE-Operation als Insert einer ganzen Collection und nicht nur als Upserts einiger Zeilen.
Datenbanken müssen nicht nur die Datengröße, sondern auch die Such- und Einfügegeschwindigkeit berücksichtigen. Wir gehen davon aus, dass die Sammlung mit dem beliebten HNSW-Index indiziert ist, der eine Suchzeit in Big-O-Notation von O(log n) hat.
Mit diesen Annahmen folgt hier unsere Umrechnung von webbasierten Benutzern/RPS/Lesevorgängen/Schreibvorgängen in Architektur-Tiers für Vector Database QPS/Datengröße:
Bis zu 1.000 Benutzer = 20 QPS mit 1 Million Vektoren
Bis zu 2.000 Benutzer = 40 QPS mit 1 Million Vektoren
Bis zu 3.000 Benutzer = 60 QPS mit 1 Million Vektoren
Bis zu 5.000 Benutzer = 100 QPS mit 2 Millionen Vektoren
Bis zu 10.000 Benutzer = 200 QPS mit 4 Millionen Vektoren
Bis zu 25.000 Benutzer = 500 QPS mit 10 Millionen Vektoren
Bis zu 50.000 Benutzer = 1000 QPS mit 20 Millionen Vektoren
Lasttests und Benchmarking
Um die Genauigkeit unserer Ressourcenschätzungen sicherzustellen, haben wir die Architektur-Tiers auf VectorDBBench lastgetestet und gebenchmarkt. Wir haben die standardmäßigen Größen für Segment, Partition, Shard, Data Node, Query Node und Index Node für die Milvus-Architektur selbst angenommen.
Aufgrund der Autoscaling-Fähigkeiten von Milvus ist die Leistung linear zur Datengröße und den Cluster-Ressourcen! Unten finden Sie eine Tabelle mit den empfohlenen Ressourcengrößen für Milvus und Zilliz Cloud (das vollständig verwaltete Milvus) für unterschiedliche Datenkapazitäten und QPS-Anforderungen.
Die folgende Tabelle zeigt die Datenkapazität in Millionen von 1024-dimensionalen Vektoren. Milvus-Ressourcen werden in mehreren CPUs und GB Arbeitsspeicher angegeben. Zum Kostenvergleich zeigen wir Zilliz Cloud-Ressourcengrößen, angegeben in Compute Units (cu), entweder als Leistungs- oder Kapazitätstypen.
Tabelle der empfohlenen Milvus- und Zilliz-Ressourcengrößen pro Benutzer/RPS-Tiers
| Benutzer | Datenkapazität | QPS gebenchmarkt | RPS erforderlich | Milvus-Ressource | Zilliz-Ressource |
| 3,000 | 1m_1024d Vektoren | 1200 | 60 | 8CPU, 32G | 1cu-perf |
| 3,000 | 1m_1024d Vektoren | 2400 | 60 | 16CPU, 64G | 2cu-perf |
| 3,000 | 1m_1024d Vektoren | 3600 | 60 | 24CPU, 96G | 4cu-perf |
| 10,000 | 3.7m_1024d Vektoren | 360 | 200 | 16CPU, 64G | 2cu-cap |
| 10,000 | 3.7m_1024d Vektoren | 700 | 200 | 64CPU, 256G | 4cu-cap |
| 25,000 | 10m_1024d Vektoren | 600 | 500 | 196CPU, 768G | 12cu- cap |
| 250,000 | 100m_1024d Vektoren | 6000 | 5000 | 19200CPU, 76800G | 1200cu- cap |
Tabelle der empfohlenen Milvus- und Zilliz-Ressourcengrößen pro Anzahl von Benutzer/RPS-Tiers. Die Skalierung von Milvus ist linear in Bezug auf Datengröße und erforderliche QPS.
Aus der obigen Tabelle geht hervor, dass es ab einem bestimmten Schwellenwert für Datengröße und QPS kosteneffizienter sein könnte, Milvus aus der Zilliz Cloud statt On-Premises zu betreiben.
Fazit
Durch das Verständnis Ihrer Workload-Merkmale, die Schätzung der Ressourcenanforderungen auf Grundlage von Annahmen und die Nutzung von Lasttest- und Benchmarking-Tools wie VectorDBBench können Sie die erforderlichen Ressourcen für Ihre Milvus-Bereitstellung zuverlässig bereitstellen.
Eine ausführlichere Erläuterung finden Sie in unserem Cluster-Sizing Guide. Denken Sie daran: Wenn sich Ihre Workload weiterentwickelt, ist es unerlässlich, Ihre Ressourcenzuweisung regelmäßig zu überprüfen und anzupassen, um Spitzenleistung aufrechtzuerhalten.
Referenzen
HNSW: https://github.com/nmslib/hnswlib/blob/master/ALGO_PARAMS.md
Milvus-Architektur: https://docs.gitlab.com/ee/administration/reference_architectures/
Blog Milvus Packaging Dependencies: https://zilliz.com/blog/Milvus-server-docker-installation-and-packaging-dependencies
Blog Milvus Sizing Tool: https://medium.com/@zilliz_learn/demystifying-the-milvus-sizing-tool-2c0afe7fe963
Shards, Partitions, Segments: https://zilliz.com/blog/sharding-partitioning-segments-get-most-from-your-database
Zilliz Cloud CU-Typen: https://docs.zilliz.com/docs/cu-types-explained#evaluate-performance
VectorDBBench Tool für Benchmarking von Milvus, Zilliz Cloud und vielen anderen gängigen Vektordatenbanken
Weiterlesen
Zilliz Cloud Update: Smarter Autoscaling for Cost Savings, Stronger Compliance with Audit Logs, and More
What's new in Zilliz Cloud? Smarter autoscaling with scale-down, audit logs GA, enhanced SSO, and Milvus 2.6 in Private Preview.
Zilliz Cloud Introduces Advanced BYOC-I Solution for Ultimate Enterprise Data Sovereignty
Explore Zilliz Cloud BYOC-I, the solution that balances AI innovation with data control, enabling secure deployments in finance, healthcare, and education sectors.
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.