For "Single tenant LAION 100M" below, we refer to the "Laion 100m" (Klicken Sie, um S3 URI zu kopieren) Dataset (100M * 768 float dense vectors).
For "Multitenant Cohere 10M" Dataset below, we refer to the "Cohere Large" (Klicken Sie, um S3 URI zu kopieren) Dataset (10M * 768 float dense vectors). All data are randomly splitted across 1000 tenants.
Kosten Pareto-Linien
Pareto-Kostenlinien zeigen, wie viel nachhaltige QPS jede Cloud-Vektor-Datenbank bei gegebenen Betriebsausgaben liefern kann. Sie kombinieren gemessene Suchergebnisse mit öffentlichen Preismodellen.
Arbeitsbelastung
Einzelmieter LAION 100M
Kostenbasis
Query only
Kostenzeitraum
cost.filters.priceOrder
Kosten vs. QPS ParetoQuery only - niedriger ist besser - USD / hour
Anmerkungen:Alle Tests werden in AWS us-west-2 durchgeführt. Alle hier aufgeführten Kosten basieren auf den Gebühren des jeweiligen Produkts in dieser Region.
CloudInsert Fall
In diesem Fall wird der Write-to-Serve-Lebenszyklus gemessen: wie lange es dauert, bis die Massendaten eingefügt sind, wann sie zuverlässig durchsucht werden können und wann die Indizierung im Hintergrund vollständig abgeschlossen ist.
Anmerkungen:Wie genau wir "eingefügt", "durchsuchbar" und "vollständig indiziert" definiert haben, können Sie im Quellcode von VectorDBBench für jeden Client nachlesen. Für die grundlegende Intuition:
CloudPayloadSearchCase & MultitenantSearchCase
In diesem Fall wird das Abfrageverhalten gemessen, nachdem die Cloud-Daten bereits geladen und durchsuchbar sind. Er vergleicht die gleichzeitige Spitzen-QPS, die P99-Latenz und den Rückruf unter verschiedenen Antwort-Payloads, Skalar-Filter-Selektivität und Tenancy-Modi, sodass das Diagramm sowohl den Durchsatz als auch die Ergebnisqualität zeigt, anstatt nur die Geschwindigkeit zu belohnen.
Modus
Einzelmieter LAION 100M
Filter
ungefiltert
Nutzlast
ids only
Latenzzeit
Maximale Gleichzeitigkeit P99-Latenzzeit
Kosten anzeigen
topK = 100
Vektorsuch-Latenzzeit und QPSungefiltert - ids only - Maximale Gleichzeitigkeit P99
ProduktMaximale Gleichzeitigkeit P99 LatenzzeitMaximale Gleichzeitigkeit QPSRückruf@10Abfragekosten @ max QPS
Zilliz Cloud Kapazität 32CU
2,000 Bytes/Abfrage
158 ms
786.1
Rückruf@10 0.9728
n/a
Turbopuffer
2,000 Bytes/Abfrage
2.34 s
395.7
Rückruf@10 0.9321
n/a
Zilliz Cloud Kapazität 12CU
2,000 Bytes/Abfrage
299 ms
376
Rückruf@10 0.9723
n/a
Turbopuffer Pinned
2,000 Bytes/Abfrage
3.30 s
68.2
Rückruf@10 0.9321
n/a
Zilliz Wolke gestaffelt 4CU
2,000 Bytes/Abfrage
5.57 s
49.2
Rückruf@10 0.9510
n/a
Pinecone Serverless
2,000 Bytes/Abfrage
4.85 s
4.6
Rückruf@10 0.9609
n/a
CloudColdLatency-Fall
In diesem Fall wird die erste Abfrage nach einer kalten Leerlaufphase mit dem erwärmten stationären Abfragepfad verglichen. Er isoliert das Kaltstartverhalten vom normalen Suchdurchsatz, so dass das Diagramm zeigt, ob ein Produkt nach Inaktivität einen wesentlichen Aufwärmverlust aufweist.
Modus
ungefiltert
Cold / Warm Latencyungefiltert
Zilliz Cloud Kapazität 12CU
55 / 54 ms
Turbopuffer Pinned
64 / 45 ms
Zilliz Wolke gestaffelt 4CU
122 / 57 ms
Pinecone Serverless
271 / 60 ms
Turbopuffer
2048 / 322 ms
Kalt/Warm-Verhältnisniedriger ist besser
Zilliz Cloud Kapazität 12CU
1.01×
Turbopuffer Pinned
1.42×
Zilliz Wolke gestaffelt 4CU
2.16×
Pinecone Serverless
4.52×
Turbopuffer
6.36×
Anmerkungen:
Wir weisen darauf hin, dass bei einigen Produkten das Verhältnis zwischen kalter und warmer Latenzzeit im 99. Perzentil zwar dramatischer sein kann, dies aber in der Regel auf ein Problem mit dem Netzwerk bei späteren Abfragen hinweist und nicht vollständig reproduziert werden kann. Daher bleiben wir bei der getreueren Definition der Cold/Warm-Latenz, d. h. der ersten Abfrage in jeder Runde.
Der Zeitpunkt, zu dem eine Produktsammlung kalt wird, ist ziemlich unklar, da die meisten Produkte keine öffentlichen APIs anbieten, die solche Informationen liefern. Um reale Produktionsumgebungen zu simulieren, stellen wir beim Cold-Latency-Benchmarking sicher, dass die Sammlungen mindestens 24 Stunden nach den letzten Operationen an den Produkten so kalt wie möglich werden.