Datensatz Anmerkung:

  1. 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).
  2. 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.
Pareto-Kostenlinien zeigen, wie viel nachhaltige QPS jede Cloud-Vektor-Datenbank bei gegebenen Betriebsausgaben liefern kann. Sie kombinieren gemessene Suchergebnisse mit öffentlichen Preismodellen.
Arbeitsbelastung
Kostenbasis

Kostenzeitraum
Price order
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.

Kontinuierliche Datenerfassung und Aktualität der Suchergebnisse

Link zu diesem Abschnitt kopieren
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.
Kosten anzeigen
DatensatzLAION 100M
EingefügtDurchsuchbarVollständig indexiertKosten schreiben
Zilliz Cloud Capacity 12CU
Losgröße = 1,000
2.9 hr
0 ms
7.0 min
$9.12
Losgröße = 5,000
3.1 hr
0 ms
1.8 min
$9.25
Losgröße = 10,000
3.2 hr
0 ms
1.9 min
$9.5
Zilliz Cloud Tiered 4CU
Losgröße = 1,000
4.1 hr
0 ms
10.3 min
$6.3
Losgröße = 5,000
4.1 hr
0 ms
9.6 min
$6.29
Losgröße = 10,000
4.1 hr
0 ms
10.9 min
$6.34
Turbopuffer
Losgröße = 1,000
53.5 hr
0 ms
3.4 min
$304
Losgröße = 5,000
1.9 hr
6.6 hr
2.4 min
$302
Losgröße = 10,000
1.8 hr
6.4 hr
2.0 min
$302
Pinecone Serverless
Losgröße = 1,000
111.7 hr
0 ms
42 ms
$1,180
Losgröße = 5,000
71.4 hr
0 ms
1 ms
$1,180
Losgröße = 10,000
72.4 hr
0 ms
127 ms
$1,180
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:

Einzel- und Mandantenübergreifende Suche mit Nutzdaten

Link zu diesem Abschnitt kopieren
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
Filter
Nutzlast
Latenzzeit
Kosten anzeigen
topK = 100
Vektorsuch-Latenzzeit und QPSungefiltert - ids only - Maximale Gleichzeitigkeit P99
ProduktMaximale Gleichzeitigkeit P99 LatenzzeitMaximale Gleichzeitigkeit QPSRückruf@10
Zilliz Cloud Kapazität 32CU
2,000 Bytes/Abfrage
158 ms
786.1
Rückruf@10 0.9728
Turbopuffer
2,000 Bytes/Abfrage
2.34 s
395.7
Rückruf@10 0.9321
Zilliz Cloud Kapazität 12CU
2,000 Bytes/Abfrage
299 ms
376
Rückruf@10 0.9723
Turbopuffer Pinned
2,000 Bytes/Abfrage
3.30 s
68.2
Rückruf@10 0.9321
Zilliz Wolke gestaffelt 4CU
2,000 Bytes/Abfrage
5.57 s
49.2
Rückruf@10 0.9510
Pinecone Serverless
2,000 Bytes/Abfrage
4.85 s
4.6
Rückruf@10 0.9609
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
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:
  1. 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.
  2. 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.