Showdown der binären Quantisierung

Das Speichern hochdimensionaler Vektoren in ihrer ursprünglichen Form kann speicherintensiv sein. Quantisierungstechniken komprimieren diese Vektoren in eine kompakte Darstellung und reduzieren so den Speicherbedarf drastisch. Die Suche erfolgt dann im komprimierten Raum, was den Rechenaufwand reduziert und die Suche insbesondere bei großen Datensätzen beschleunigt.

Elastic hat sich zum Ziel gesetzt, Lucene zu einer leistungsstarken Vektor-Engine zu machen. Wir haben Better Binary Quantization (BBQ) in Elasticsearch 8.16 auf Basis von Lucene eingeführt und in den Versionen 8.18 und 9.0 weiterentwickelt. BBQ basiert auf einem neuen Ansatz der Skalarquantisierung , der die float32-Dimensionen auf Bits reduziert und so eine Speicherreduzierung von ca. 95 % bei gleichzeitig hoher Ranking-Qualität ermöglicht.

OpenSearch hingegen verwendet mehrere Vektor-Engines: nmslib (jetzt veraltet), Lucene und FAISS. In einem früheren Blog haben wir Elasticsearch und OpenSearch für die Vektorsuche verglichen. Wir haben drei verschiedene Datensätze verwendet und unterschiedliche Kombinationen von Engines und Konfigurationen auf beiden Produkten getestet.

In diesem Blog geht es um die derzeit in beiden Produkten verfügbaren binären Quantisierungsalgorithmen. Wir haben Elasticsearch mit BBQ und OpenSearch mit der binären Quantisierung von FAISS unter Verwendung des openai_vector Rally-Tracks getestet.

Das Hauptziel bestand darin, die Leistung beider Lösungen bei gleichem Erinnerungsniveau zu bewerten. Was bedeutet Rückruf ? Die Rückrufquote ist eine Kennzahl, die misst, wie viele relevante Ergebnisse erfolgreich von einem Suchsystem abgerufen werden.

Bei dieser Auswertung ist insbesondere der Recall@k wichtig, wobei k die Anzahl der berücksichtigten Top-Ergebnisse darstellt. Recall@10, Recall@50 und Recall@100 messen daher, wie viele der wirklich relevanten Ergebnisse in den ersten 10, 50 bzw. 100 abgerufenen Elementen erscheinen. Die Rückrufquote wird auf einer Skala von 0 bis 1 (oder 0 % bis 100 % Präzision) ausgedrückt. Und das ist wichtig, weil wir über ungefähres KNN (ANN) und nicht über exaktes KNN sprechen, bei dem die Rückrufrate immer 1 (100 %) beträgt.

Für jeden Wert von k haben wir auch n angegeben, also die Anzahl der Kandidaten, die vor der endgültigen Rangfolge berücksichtigt wurden. Dies bedeutet, dass das System für Recall@10, Recall@50 und Recall@100 zunächst n Kandidaten mithilfe des binären Quantisierungsalgorithmus abruft und sie dann in eine Rangfolge bringt, um zu bestimmen, ob die obersten k Ergebnisse die erwarteten relevanten Elemente enthalten.

Durch die Steuerung von n können wir den Kompromiss zwischen Effizienz und Genauigkeit analysieren. Ein höherer n-Wert erhöht normalerweise die Rückrufquote, da mehr Kandidaten für die Rangfolge zur Verfügung stehen, erhöht aber auch die Latenz und verringert den Durchsatz. Umgekehrt beschleunigt ein niedrigerer n- Wert zwar die Abfrage, kann aber die Trefferquote verringern, wenn zu wenige relevante Kandidaten im anfänglichen Satz enthalten sind.

In diesem Vergleich zeigte Elasticsearch bei identischen Setups eine geringere Latenz und einen höheren Durchsatz als OpenSearch.

Methodik

Die vollständige Konfiguration sowie Terraform-Skripte, Kubernetes-Manifeste und der spezifische Rally-Track sind in diesem Repository unter openai_vector_bq verfügbar.

Wie bei vorherigen Benchmarks haben wir einen Kubernetes-Cluster verwendet, der aus Folgendem besteht:

• 1 Knotenpool für Elasticsearch 9.0 mit 3 e2-standard-32 Maschinen (128 GB RAM und 32 CPUs)

• 1 Knotenpool für OpenSearch 2.19 mit 3 e2-standard-32 Maschinen (128 GB RAM und 32 CPUs)

• 1 Knotenpool für Rally mit 2 e2-standard-4 Maschinen (16 GB RAM und 4 CPUs)

Wir haben einen Elasticsearch-Cluster Version 9.0 und einen OpenSearch-Cluster Version 2.19 eingerichtet.

Sowohl Elasticsearch als auch OpenSearch wurden mit genau demselben Setup getestet: Wir haben openai_vector Rally Track mit einigen Modifikationen verwendet, das 2,5 Millionen Dokumente aus dem NQ-Datensatz verwendet, angereichert mit Einbettungen, die mit dem Modell text-embedding-ada-002 von OpenAI generiert wurden.

Die Ergebnisse berichten über die gemessene Latenz und den Durchsatz bei verschiedenen Rückrufstufen (Recall@10, Recall@50 und Recall@100) unter Verwendung von 8 gleichzeitigen Clients zur Durchführung von Suchvorgängen. Wir haben einen einzelnen Shard und keine Replikate verwendet.

Wir haben die folgenden Kombinationen von kn-rescore ausgeführt, zB 10-2000-2000 oder k:10, n:2000 und rescore:2000 würden die besten k (10) von n Kandidaten (2000) abrufen, indem ein Rescore auf 2000 Ergebnisse angewendet wird (was einem „Oversample-Faktor“ von 1 entspricht). Jede Suche wurde 10.000 Mal ausgeführt, mit 1.000 Suchvorgängen als Aufwärmphase:

Rückruf@10

• 10-40-40

• 10-50-50

• 10-100-100

• 10-200-200

• 10-500-500

• 10-750-750

• 10-1000-1000

• 10-1500-1500

• 10-2000-2000

Rückruf@50

• 50-150-150

• 50-200-200

• 50-250-250

• 50-500-500

• 50-750-750

• 50-1000-1000

• 50-1200-1200

• 50-1500-1500

• 50-2000-2000

Rückruf@100

• 100-200-200

• 100-250-250

• 100-300-300

• 100-500-500

• 100-750-750

• 100-1000-1000

• 100-1200-1200

• 100-1500-1500

• 100-2000-2000

Um den Benchmark zu replizieren, sind in den Kubernetes-Manifesten für Rally-Elasticsearch und Rally-Opensearch alle relevanten Variablen in einer ConfigMap externalisiert, die hier (ES) und hier (OS) verfügbar ist. Der Parameter search_ops kann angepasst werden, um jede Kombination aus k, n und Rescore zu testen.

OpenSearch Rally-Konfiguration

/k8s/rally-openai_vector-os-bq.yml

Opensearch-Indexkonfiguration

Die Variablen aus der ConfigMap werden dann auf die Indexkonfiguration angewendet, einige Parameter bleiben unverändert. Die 1-Bit-Quantisierung in OpenSearch wird durch Einstellen der Komprimierungsstufe auf „32x“ konfiguriert.

index-vectors-only-mapping-with-docid-mapping.json

Elasticsearch Rally-Konfiguration

/k8s/rally-openai_vector-es-bq.yml

Elasticsearch-Indexkonfiguration

index-vectors-only-mapping-with-docid-mapping.json

Ergebnisse

Es gibt mehrere Möglichkeiten, die Ergebnisse zu interpretieren. Sowohl für die Latenz als auch für den Durchsatz haben wir auf jeder Rückrufebene ein vereinfachtes und ein detailliertes Diagramm erstellt. Es ist leicht, Unterschiede zu erkennen, wenn wir bei jeder Metrik das Prinzip „höher ist besser“ berücksichtigen. Allerdings ist die Latenz ein negativer Faktor (je niedriger, desto besser), während der Durchsatz ein positiver Faktor ist. Für die vereinfachten Diagramme haben wir (Rückruf / Latenz) * 10000 (einfach „Geschwindigkeit“ genannt) und Rückruf * Durchsatz verwendet. Beide Messwerte bedeuten also, dass mehr Geschwindigkeit und mehr Durchsatz besser sind. Lasst uns loslegen.

Rückruf @ 10 - vereinfacht

Bei dieser Rückrufebene ist Elasticsearch BBQ bis zu 5-mal schneller (durchschnittlich 3,9-mal schneller) und hat im Durchschnitt einen 3,2-mal höheren Durchsatz als OpenSearch FAISS.

Rückruf @ 10 - Detailliert

Aufgabe

Latenz.Mittelwert

Durchsatz.Mittelwert

Durchschnittliche Rückrufzahl

Elasticsearch-9.0-BBQ

10-100-100

11,70

513,58

0,89

Elasticsearch-9.0-BBQ

10-1000-100

27,33

250,55

0,95

Elasticsearch-9.0-BBQ

10-1500-1500

35,93

197,26

0,95

Elasticsearch-9.0-BBQ

10-200-200

13.33

456,16

0,92

Elasticsearch-9.0-BBQ

10-2000-2000

44,27

161,40

0,95

Elasticsearch-9.0-BBQ

10-40-40

10,97

539,94

0,84

Elasticsearch-9.0-BBQ

10-50-50

11.00

535,73

0,85

Elasticsearch-9.0-BBQ

10-500-500

19,52

341,45

0,93

Elasticsearch-9.0-BBQ

10-750-750

22,94

295,19

0,94

OpenSearch-2.19-faiss

10-100-100

35,59

200,61

0,94

OpenSearch-2.19-faiss

10-1000-1000

156,81

58,30

0,96

OpenSearch-2.19-faiss

10-1500-1500

181,79

42,97

0,96

OpenSearch-2.19-faiss

10-200-200

47,91

155,16

0,95

OpenSearch-2.19-faiss

10-2000-2000

232,14

31,84

0,96

OpenSearch-2.19-faiss

10-40-40

27,55

249,25

0,92

OpenSearch-2.19-faiss

10-50-50

28,78

245,14

0,92

OpenSearch-2.19-faiss

10-500-500

79,44

97,06

0,96

OpenSearch-2.19-faiss

10-750-750

104,19

75,49

0,96

Rückruf @ 50 - vereinfacht

Bei diesem Rückrufniveau ist Elasticsearch BBQ bis zu 5x schneller (durchschnittlich 4,2x schneller) und hat durchschnittlich 3,9x mehr Durchsatz als OpenSearch FAISS.

Detaillierte Ergebnisse – Rückruf @ 50

Aufgabe

Latenzmittelwert

Durchsatzmittelwert

Durchschnittliche Rückrufrate

Elasticsearch-9.0-BBQ

50-1000-1000

25,71

246,44

0,95

Elasticsearch-9.0-BBQ

50-1200-1200

28,81

227,85

0,95

Elasticsearch-9.0-BBQ

50-150-150

13.43

362,90

0,90

Elasticsearch-9.0-BBQ

50-1500-1500

33,38

202,37

0,95

Elasticsearch-9.0-BBQ

50-200-200

12,99

406,30

0,91

Elasticsearch-9.0-BBQ

50-2000-2000

42,63

163,68

0,95

Elasticsearch-9.0-BBQ

50-250-250

14.41

373,21

0,92

Elasticsearch-9.0-BBQ

50-500-500

17.15

341,04

0,93

Elasticsearch-9.0-BBQ

50-750-750

31,25

248,60

0,94

OpenSearch-2.19-faiss

50-1000-1000

125,35

62,53

0,96

OpenSearch-2.19-faiss

50-1200-1200

143,87

54,75

0,96

OpenSearch-2.19-faiss

50-150-150

43,64

130,01

0,89

OpenSearch-2.19-faiss

50-1500-1500

169,45

46,35

0,96

OpenSearch-2.19-faiss

50-200-200

48,05

156,07

0,91

OpenSearch-2.19-faiss

50-2000-2000

216,73

36,38

0,96

OpenSearch-2.19-faiss

50-250-250

53,52

142,44

0,93

OpenSearch-2.19-faiss

50-500-500

78,98

97,82

0,95

OpenSearch-2.19-faiss

50-750-750

103,20

75,86

0,96

Rückruf @ 100

Bei dieser Rückrufebene ist Elasticsearch BBQ bis zu 5-mal schneller (durchschnittlich 4,6-mal schneller) und hat im Durchschnitt einen 3,9-mal höheren Durchsatz als OpenSearch FAISS.

Detaillierte Ergebnisse – Rückruf @ 100

Aufgabe

Latenz.Mittelwert

Durchsatz.Mittelwert

Durchschnittliche Rückrufzahl

Elasticsearch-9.0-BBQ

100-1000-1000

27,82

243,22

0,95

Elasticsearch-9.0-BBQ

100-1200-1200

31.14

224,04

0,95

Elasticsearch-9.0-BBQ

100-1500-1500

35,98

193,99

0,95

Elasticsearch-9.0-BBQ

100-200-200

14.18

403,86

0,88

Elasticsearch-9.0-BBQ

100-2000-2000

45,36

159,88

0,95

Elasticsearch-9.0-BBQ

100-250-250

14,77

433,06

0,90

Elasticsearch-9.0-BBQ

100-300-300

14,61

375,54

0,91

Elasticsearch-9.0-BBQ

100-500-500

18,88

340,37

0,93

Elasticsearch-9.0-BBQ

100-750-750

23,59

285,79

0,94

OpenSearch-2.19-faiss

100-1000-1000

142,90

58,48

0,95

OpenSearch-2.19-faiss

100-1200-1200

153,03

51,04

0,95

OpenSearch-2.19-faiss

100-1500-1500

181,79

43,20

0,96

OpenSearch-2.19-faiss

100-200-200

50,94

131,62

0,83

OpenSearch-2.19-faiss

100-2000-2000

232,53

33,67

0,96

OpenSearch-2.19-faiss

100-250-250

57,08

131,23

0,87

OpenSearch-2.19-faiss

100-300-300

62,76

120,10

0,89

OpenSearch-2.19-faiss

100-500-500

84,36

91,54

0,93

OpenSearch-2.19-faiss

100-750-750

111,33

69,95

0,94

Verbesserungen beim Grillen

BBQ hat seit seiner Erstveröffentlichung eine lange Entwicklung durchgemacht. Zu Vergleichszwecken haben wir bei Elasticsearch 8.16 neben dem aktuellen einen Benchmark-Lauf von 8.16 eingefügt und können sehen, wie sich Rückruf und Latenz seitdem verbessert haben.

In Elasticsearch 8.18 und 9.0 haben wir den Kernalgorithmus zur Quantisierung der Vektoren neu geschrieben. BBQ war in 8.16 zwar gut, aber die neuesten Versionen sind sogar noch besser. Sie können hier und hier darüber lesen. Kurz gesagt, jeder Vektor wird einzeln durch optimierte skalare Quantile quantisiert. Dadurch profitieren Benutzer von einer höheren Genauigkeit bei der Vektorsuche ohne Leistungseinbußen, wodurch die Vektorabfrage von Elasticsearch noch leistungsfähiger wird.

Fazit

In diesem Leistungsvergleich zwischen Elasticsearch BBQ und OpenSearch FAISS übertrifft Elasticsearch OpenSearch bei der Vektorsuche deutlich und erreicht über verschiedene Rückrufebenen hinweg durchschnittlich bis zu 5-mal schnellere Abfragegeschwindigkeiten und einen 3,9-mal höheren Durchsatz.

Zu den wichtigsten Ergebnissen gehören:

• Recall@10: Elasticsearch BBQ ist bis zu 5x schneller (durchschnittlich 3,9x schneller) und hat im Durchschnitt einen 3,2x höheren Durchsatz als OpenSearch FAISS.

• Recall@50: Elasticsearch BBQ ist bis zu 5x schneller (durchschnittlich 4,2x schneller) und hat im Durchschnitt einen 3,9x höheren Durchsatz als OpenSearch FAISS.

• Recall@100: Elasticsearch BBQ ist bis zu 5x schneller (durchschnittlich 4,6x schneller) und hat im Durchschnitt einen 3,9x höheren Durchsatz als OpenSearch FAISS.

Diese Ergebnisse unterstreichen die Effizienz- und Leistungsvorteile von Elasticsearch BBQ, insbesondere in hochdimensionalen Vektorsuchszenarien. Die in Elasticsearch 8.16 eingeführte Better Binary Quantization (BBQ)-Technik bietet eine erhebliche Speicherreduzierung (~95 %) bei gleichzeitiger Beibehaltung einer hohen Ranking-Qualität und ist daher eine hervorragende Wahl für groß angelegte Vektorsuchanwendungen.

Bei Elastic arbeiten wir unermüdlich an Innovationen, um Apache Lucene und Elasticsearch zu verbessern und die beste Vektordatenbank für Such- und Abrufanwendungsfälle bereitzustellen, einschließlich RAG (Retrieval Augmented Generation). Unsere jüngsten Fortschritte haben die Leistung erheblich gesteigert und die Vektorsuche schneller und platzsparender gemacht als zuvor, aufbauend auf den Vorteilen von Lucene 10. Dieser Blog ist ein weiteres Beispiel für diese Innovation.

Die Vektorsuche revolutioniert die Art und Weise, wie wir Ähnlichkeitssuchen durchführen, insbesondere in Bereichen wie KI und Machine Learning. Mit der zunehmenden Verbreitung von Vektoreinbettungsmodellen wird die Fähigkeit, Millionen von hochdimensionalen Vektoren effizient zu durchsuchen, immer wichtiger.

Bei der Energieversorgung von Vektordatenbanken haben Elastic und OpenSearch bemerkenswert unterschiedliche Ansätze gewählt. Elastic investierte stark in die Optimierung von Apache Lucene mit Elasticsearch, um sie zur erstklassigen Wahl für Vektorsuchanwendungen zu machen. Im Gegensatz dazu erweiterte OpenSearch seinen Fokus, indem es andere Implementierungen der Vektorsuche integriert und über den Rahmen von Lucene hinausgeht. Unser Fokus auf Lucene ist strategisch und ermöglicht es uns, in unserer Version von Elasticsearch hochintegrierten Support bereitzustellen, was zu einem erweiterten Funktionsumfang führt, bei dem jede Komponente die Fähigkeiten der anderen ergänzt und erweitert.

Dieser Blog bietet einen detaillierten Vergleich zwischen Elasticsearch 8.14 und OpenSearch 2.14, wobei verschiedene Konfigurationen und Vektor-Engines berücksichtigt werden. In dieser Leistungsanalyse hat sich Elasticsearch als die überlegene Plattform für Vektorsuchen erwiesen, und kommende Features werden die Unterschiede noch deutlicher machen. Als es gegen OpenSearch antrat, schnitt es in jedem Benchmark-Track hervorragend ab und bot im Durchschnitt eine 2 bis 12 Mal schnellere Leistung. Dies geschah in Szenarien mit unterschiedlichen Vektormengen und Dimensionen, einschließlich so_vector (2 Mio. Vektoren, 768D), openai_vector (2,5 Mio. Vektoren, 1536D) und dense_vector (10 Mio. Vektoren, 96D), die alle in diesem Repository neben den Terraform-Skripten zum Bereitstellen der gesamten erforderlichen Infrastruktur in Google Cloud und Kubernetes-Manifesten für die Ausführung der Tests verfügbar sind.

Die in diesem Blog beschriebenen Ergebnisse ergänzen die Ergebnisse einer zuvor veröffentlichten und von Dritten validierten Studie, die zeigt, dass Elasticsearch bei den gängigsten Suchanalyseoperationen um 40%–140% schneller ist als OpenSearch: bei Textabfrage, Sortierung, Bereich, Datumshistogramm und Begriffsfilterung. Jetzt können wir ein weiteres Unterscheidungsmerkmal hinzufügen: die Vektorsuche.

Bis zu 12 Mal schneller einsatzbereit

Unsere gezielten Benchmarks über die vier Vektordatensätze hinweg umfassten sowohl approximative kNN- als auch exakte kNN-Suchen, wobei unterschiedliche Größen, Dimensionen und Konfigurationen berücksichtigt wurden, was insgesamt 40.189.820 nicht zwischengespeicherte Suchanfragen ergab. Das Ergebnis: Elasticsearch ist bei der Vektorsuche bis zu 12 Mal schneller als OpenSearch und benötigt daher weniger Rechenressourcen.

Abbildung 1: Gruppierte Aufgaben für ANN und exaktes kNN in verschiedenen Kombinationen in Elasticsearch und OpenSearch.

Die Gruppen wie knn-10-100 bezeichnen eine kNN-Suche mit und . Bei der HNSW-Vektorsuche bestimmt die Anzahl der nächsten Nachbarn, die für einen Abfragevektor abgerufen werden sollen. Es wird angegeben, wie viele ähnliche Vektoren als Ergebnis gefunden werden sollen. legt die Anzahl der Kandidatenvektoren fest, die in jedem Segment abgerufen werden sollen. Mehr Kandidaten können die Genauigkeit erhöhen, erfordern jedoch mehr Rechenressourcen.

Wir haben auch mit verschiedenen Quantisierungstechniken getestet und Engine-spezifische Optimierungen genutzt. Die detaillierten Ergebnisse für jeden Track und jede Aufgabe und Vektor-Engine sind unten verfügbar.

Exaktes kNN und approximatives kNN

Beim Umgang mit unterschiedlichen Daten und Anwendungsfällen variiert der richtige Ansatz für die Vektorsuche. In diesem Blog verwenden alle als knn-* angegebenen Aufgaben wie knn-10-100 approximatives kNN und script-score-* beziehen sich auf exaktes kNN, aber was ist der Unterschied zwischen ihnen und warum ist das wichtig?

Im Wesentlichen ist bei der Verarbeitung umfangreicherer Datensätze die Methode des Approximativen K-Nearest-Neighbor (ANN) aufgrund ihrer überlegenen Skalierbarkeit die bevorzugte Methode. Für bescheidenere Datensätze, die möglicherweise einen Filterprozess erfordern, ist die exakte kNN-Methode ideal.

Exaktes kNN verwendet eine Brute-Force-Methode, die den Abstand zwischen einem Vektor und jedem anderen Vektor im Datensatz berechnet. Anschließend werden diese Abstände in eine Rangfolge gebracht, um die nächsten Nachbarn zu finden. Diese Methode gewährleistet zwar eine exakte Übereinstimmung, leidet aber bei großen, hochdimensionalen Datensätzen unter Problemen der Skalierbarkeit. Es gibt jedoch viele Fälle, in denen exaktes kNN benötigt wird:

• Neubewertung: In Szenarien mit lexikalischen oder semantischen Suchen, gefolgt von einer vektorbasierten Neubewertung, ist exaktes kNN unerlässlich. In einer Produktsuchmaschine können erste Suchergebnisse auf der Grundlage von Textabfragen (z. B. Schlüsselwörtern, Kategorien) gefiltert werden. Anschließend werden Vektoren, die mit den gefilterten Elementen verknüpft sind, für eine genauere Ähnlichkeitsbewertung verwendet.

• Personalisierung: Bei einer großen Anzahl von Nutzern, die jeweils durch eine relativ kleine Anzahl (z. B. 1 Million) unterschiedlicher Vektoren repräsentiert werden, wird die Sortierung des Indexes nach nutzerspezifischen Metadaten (z. B. user_id) und die Brute-Force-Bewertung mit Vektoren effizient. Dieser Ansatz ermöglicht personalisierte Empfehlungen oder die Bereitstellung von Inhalten basierend auf präzisen Vektorvergleichen, die auf die individuellen Nutzerpräferenzen zugeschnitten sind.

Exaktes kNN stellt sicher, dass das endgültige Ranking und die Empfehlungen basierend auf der Vektorähnlichkeit präzise und auf die Nutzerpräferenzen zugeschnitten sind.

Approximatives kNN (oder ANN) verwendet hingegen Methoden, um die Datensuche schneller und effizienter als exaktes kNN zu gestalten, insbesondere in großen, hochdimensionalen Datensätzen. Anstelle eines Brute-Force-Ansatzes, der den genauen kürzesten Abstand zwischen einer Abfrage und allen Punkten misst, was zu Berechnungs- und Skalierungsproblemen führt, verwendet ANN bestimmte Techniken, um die Indizes und Dimensionen durchsuchbarer Vektoren im Datensatz effizient neu zu strukturieren. Dies kann zwar zu einer leichten Ungenauigkeit führen, erhöht jedoch die Geschwindigkeit des Suchvorgangs erheblich und macht ihn zu einer effektiven Alternative für den Umgang mit großen Datensätzen.

In diesem Blog verwenden alle als knn-* bezeichneten Aufgaben wie knn-10-100 approximatives kNN und script-score-* beziehen sich auf exaktes kNN.

Testmethodik

Während Elasticsearch und OpenSearch hinsichtlich der API für BM25-Suchvorgänge ähnlich sind, da letzteres ein Fork von ersterem ist, trifft dies auf die Vektorsuche, die nach dem Fork eingeführt wurde, nicht zu. OpenSearch verfolgte einen anderen Ansatz als Elasticsearch in Bezug auf Algorithmen, indem es neben lucene zwei weitere Engines – nmslib und faiss – einführte, die jeweils über spezifische Konfigurationen und Einschränkungen verfügen (z. B. erlaubt nmslib in OpenSearch keine Filter, ein wesentliches Feature für viele Anwendungsfälle).

Alle drei Engines verwenden den Hierarchical Navigable Small World (HNSW)-Algorithmus, der effizient für die approximative Suche nach dem nächsten Nachbarn und besonders leistungsfähig beim Umgang mit hochdimensionalen Daten ist. Es ist wichtig zu beachten, dass faiss auch einen zweiten Algorithmus, ivf, unterstützt, aber da dafür ein Vortraining am Datensatz erforderlich ist, werden wir uns ausschließlich auf HNSW konzentrieren. Die Kernidee von HNSW besteht darin, die Daten in mehreren Schichten verbundener Graphen zu organisieren, wobei jede Schicht eine andere Granularität des Datensatzes darstellt. Das Suchen beginnt auf der obersten Ebene mit der gröbsten Ansicht und schreitet zu immer feineren Schichten fort, bis es die unterste Ebene erreicht.

Beide Suchmaschinen wurden unter identischen Bedingungen in einer kontrollierten Umgebung getestet, um faire Testbedingungen zu gewährleisten. Die angewandte Methode ähnelt diesem zuvor veröffentlichten Leistungsvergleich, mit dedizierten Node-Pools für Elasticsearch, OpenSearch und Rally. Das Terraform-Skript ist (neben allen Quellen) verfügbar, um einen Kubernetes-Cluster mit Folgendem bereitzustellen:

• 1 Node-Pool für Elasticsearch mit 3 e2-standard-32-Maschinen (128 GB RAM und 32 CPUs)

• 1 Node-Pool für OpenSearch mit 3 e2-standard-32-Maschinen (128 GB RAM und 32 CPUs)

• 1 Node-Pool für Rally mit 2 t2a-standard-16 Maschinen (64 GB RAM und 16 CPUs)

Jeder „Track“ (oder Test) wurde 10 Mal für jede Konfiguration ausgeführt, die unterschiedliche Engines, Konfigurationen und Vektortypen umfasste. Die Tracks haben Aufgaben, die sich je nach Track zwischen 1.000 und 10.000 Mal wiederholen. Wenn eine der Aufgaben in einem Track z. B. aufgrund einer Netzwerk-Zeitüberschreitung fehlschlug, wurden alle Aufgaben verworfen, sodass alle Ergebnisse Tracks darstellen, die ohne Probleme gestartet und beendet wurden. Alle Testergebnisse sind statistisch validiert, um sicherzustellen, dass Verbesserungen nicht zufällig sind.

Detaillierte Ergebnisse

Warum das 99. Perzentil und nicht die durchschnittliche Latenz vergleichen? Betrachten Sie ein hypothetisches Beispiel für die durchschnittlichen Hauspreise in einem bestimmten Viertel. Der Durchschnittspreis mag auf eine teure Gegend hindeuten, aber bei näherer Betrachtung stellt sich womöglich heraus, dass die meisten Häuser viel niedriger bewertet sind und nur einige wenige Luxusimmobilien den Durchschnittswert in die Höhe treiben. Dies verdeutlicht, dass der Durchschnittspreis das gesamte Spektrum der Hauswerte in der Gegend nicht unbedingt genau wiedergibt. Man kann das mit der Untersuchung von Reaktionszeiten vergleichen, bei denen der Durchschnittswert möglicherweise kritische Probleme verbirgt.

Aufgaben

• Approximatives kNN mit k:10, n:50

• Approximatives kNN mit k:10, n:100

• Approximatives kNN mit k:100, n:1000

• Approximatives kNN mit k:10, n:50 und Keyword-Filtern

• Approximatives kNN mit k:10, n:100 und Keyword-Filtern

• Approximatives kNN mit k:100, n:1000 und Keyword-Filtern

• Approximatives kNN mit k:10, n:100 in Verbindung mit Indizierung

• Exaktes kNN (Skriptergebnis)

Vektor-Engines

• lucene in Elasticsearch und OpenSearch, beide in Version 9.10

• faiss in OpenSearch

• nmslib in OpenSearch

Vektortypen

• hnsw in Elasticsearch und OpenSearch

• int8_hnsw in Elasticsearch (HNSW mit automatischer 8-Bit-Quantisierung: Link)

• sq_fp16 hnsw in OpenSearch (HNSW mit automatischer 16-Bit-Quantisierung: Link)

Vorkonfigurierte und gleichzeitige Segmentsuche

Wie Sie wahrscheinlich wissen, ist Lucene eine hochleistungsfähige Text-Suchmaschinen-Bibliothek, die in Java geschrieben wurde und als Rückgrat für viele Suchplattformen wie Elasticsearch, OpenSearch und Solr dient. Im Kern organisiert Lucene Daten in Segmente, die im Wesentlichen in sich geschlossene Indizes sind, mit denen Lucene Suchvorgänge effizienter ausführen kann. Wenn Sie also eine auf Lucene basierende Suchmaschine mit einer Suche beauftragen, wird Ihre Suche in diesen Segmenten entweder sequentiell oder parallel ausgeführt.

OpenSearch hat die gleichzeitige Segmentsuche als optionales Flag eingeführt und verwendet sie standardmäßig nicht. Sie müssen sie mit einer speziellen Indexeinstellung index.search.concurrent_segment_search.enabled, wie hier beschrieben, aktivieren und es gibt einige Einschränkungen.

Elasticsearch hingegen sucht standardmäßig gleichzeitig in Segmenten, daher berücksichtigen die Vergleiche, die wir in diesem Blog anstellen, neben den verschiedenen Vektor-Engines und Vektortypen auch die unterschiedlichen Konfigurationen:

• Elasticsearch ootb: Elasticsearch sofort einsatzbereit, mit gleichzeitiger Segmentsuche;

• OpenSearch ootb: ohne aktivierte gleichzeitige Segmentsuche;

• OpenSearch css: mit aktivierter gleichzeitiger Segmentsuche

Kommen wir nun zu einigen detaillierten Ergebnissen für jeden getesteten Vektordatensatz:

2,5 Millionen Vektoren, 1536 Dimensionen (openai_vector)

Beginnen wir mit dem einfachsten, aber hinsichtlich der Dimensionen auch größten Track, openai_vector – er verwendet den NQ-Datensatz, der mit Einbettungen angereichert ist, die mit dem Modell „text-embedding-ada-002“ von OpenAI generiert wurden. Dieser Track ist der einfachste, da er nur approximatives kNN testet und nur 5 Aufgaben hat. Er testet sowohl im Standalone-Modus (ohne Indizierung) als auch parallel zur Indizierung und verwendet sowohl einen einzelnen Client als auch 8 gleichzeitige Clients.

Aufgaben

• standalone-search-knn-10-100-multiple-clients: Suche in 2,5 Millionen Vektoren mit 8 Clients gleichzeitig, k:10 und n:100

• standalone-search-knn-100-1000-multiple-clients: Suche in 2,5 Millionen Vektoren mit 8 Clients gleichzeitig, k:100 und n:1000

• standalone-search-knn-10-100-single-client: Suche in 2,5 Millionen Vektoren mit einem einzigen Client, k:10 und n:100

• standalone-search-knn-100-1000-single-client: Suche in 2,5 Millionen Vektoren mit einem einzigen Client, k:100 und n:1000

• parallel-documents-indexing-search-knn-10-100: Suche in 2,5 Millionen Vektoren bei gleichzeitigem Indexieren von weiteren 100.000 Dokumenten, k:10 und n:100

Die durchschnittliche p99-Leistung ist unten aufgeführt:

Hier haben wir beobachtet, dass Elasticsearch zwischen 3 und 8 Mal schneller ist als OpenSearch, wenn es neben dem Indexieren auch eine Vektorsuche (d. h. Lesen und Schreiben) mit :10 und :100 durchführt, und ohne Indizierung für denselben k- und n-Wert 2 bis 3 Mal schneller ist. Bei :100 und :1000 (standalone-search-knn-100-1000-single-client und standalone-search-knn-100-1000-multiple-clients) ist Elasticsearch im Durchschnitt 2 bis 7 Mal schneller als OpenSearch.

Die detaillierten Ergebnisse zeigen die exakten Tickets und Vektor-Engines im Vergleich:

Recall

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0,969485

0,995138

Elasticsearch-8.14.0@lucene-int8_hnsw

0,781445

0,784817

OpenSearch-2.14.0@lucene-hnsw

0,96519

0,995422

OpenSearch-2.14.0@faiss

0,984154

0,98049

OpenSearch-2.14.0@faiss-sq_fp16

0,980012

0,97721

OpenSearch-2.14.0@nmslib

0,982532

0,99832

10 Millionen Vektoren, 96 Dimensionen (dense_vector)

In dense_vector mit 10 Millionen Vektoren und 96 Dimensionen. Dies basiert auf dem Bilddatensatz DEEP1B von Yandex. Der Datensatz wird aus den ersten 10 Millionen Vektoren der „Beispieldaten“-Datei mit dem Namen learn.350M.fbin erstellt. Die Suchvorgänge verwenden Vektoren aus der Abfrage der Datei „Abfragedaten“public.10K.fbin.

Sowohl Elasticsearch als auch OpenSearch funktionieren bei diesen Daten sehr gut, insbesondere nach einer erzwungenen Zusammenführung, die normalerweise bei schreibgeschützten Indizes durchgeführt wird und der Defragmentierung des Index ähnelt, um eine einzige „Tabelle“ zu haben, in der gesucht werden kann.

Aufgaben

Jede Aufgabe wird mit 100 Anfragen aufgewärmt und dann werden 1000 Anfragen gemessen

• knn-search-10-100: Suche in 10 Millionen Vektoren, k:10 und n:100

• knn-search-100-1000: Suche in 10 Millionen Vektoren, k:100 und n:1000

• knn-search-10-100-force-merge: Suche in 10 Millionen Vektoren nach einer erzwungenen Zusammenführung, k:10 und n:100

• knn-search-100-1000-force-merge: Suche in 10 Millionen Vektoren nach einer erzwungenen Zusammenführung, k:100 und n:1000

• knn-search-100-1000-concurrent-with-indexing: Suche in 10 Millionen Vektoren bei gleichzeitiger Aktualisierung von 5 % des Datensatzes, k:100 und n:1000

• script-score-query: Exakte kNN-Suchen in 2000 spezifischen Vektoren.

Sowohl Elasticsearch als auch OpenSearch haben sich bei der ANN-Suche gut bewährt. Wenn der Index in knn-search-100-1000-force-merge und knn-search-10-100-force-merge zusammengeführt wird (d. h. nur ein Segment hat), schneidet OpenSearch bei der Verwendung von nmslib und faiss besser ab als die anderen, obwohl sie alle um die 15 ms und dicht beieinander liegen.

Wenn der Index in knn-search-10-100 und knn-search-100-1000 jedoch mehrere Segmente hat (eine typische Situation, in der ein Index Aktualisierungen seiner Dokumente erhält), hält Elasticsearch die Latenz bei etwa ~7 ms und ~16 ms, während alle anderen OpenSearch-Engines langsamer sind.

Auch wenn der Index gleichzeitig gesucht und beschrieben wird (knn-search-100-1000-concurrent-with-indexing), hält Elasticsearch die Latenz unter 15 ms (bei 13,8 ms) und ist damit fast 4 Mal schneller als OpenSearch im Standardmodus (49,3 ms) und auch dann noch schneller, wenn die gleichzeitige Segmentsuche aktiviert ist (17,9 ms). Dies ist aber zu nah, um von Bedeutung zu sein.

Bei exaktem kNN ist der Unterschied viel größer: Elasticsearch ist 6 Mal schneller als OpenSearch (~260 ms gegenüber ~1600 ms).

Recall

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0,969843

0,996577

Elasticsearch-8.14.0@lucene-int8_hnsw

0,775458

0,840254

OpenSearch-2.14.0@lucene-hnsw

0,971333

0,996747

OpenSearch-2.14.0@faiss

0,9704

0,914755

OpenSearch-2.14.0@faiss-sq_fp16

0,968025

0,913862

OpenSearch-2.14.0@nmslib

0,9674

0,910303

2 Millionen Vektoren, 768 Dimensionen (so_vector)

Dieser Track,so_vector, stammt aus einem Bündel von StackOverflow-Beiträgen, die am 21. April 2022 heruntergeladen wurden. Er enthält nur Fragedokumente – alle Dokumente mit Antworten wurden entfernt. Jeder Fragentitel wurde mithilfe des Satztransformatormodells multi-qa-mpnet-base-cos-v1 in einen Vektor kodiert. Dieser Datensatz enthält die ersten 2 Millionen Fragen.

Im Gegensatz zum vorherigen Track enthält jedes Dokument hier neben Vektoren auch andere Felder, um Test-Features wie approximativer kNN mit Filterung und Hybridsuche zu unterstützen. nmslib für OpenSearch fehlt in diesem Test auffallend, da es keine Filter unterstützt.

Aufgaben

Jede Aufgabe wird mit 100 Anfragen aufgewärmt und dann werden 100 Anfragen gemessen. Beachten Sie, dass die Aufgaben der Einfachheit halber gruppiert wurden, da der Test 16 Suchtypen mal 2 verschiedene k-Werte mal 3 verschiedene n-Werte enthält.

• kNN-10-50: Suche in 2 Millionen Vektoren ohne Filter, k:10 und n:50

• knn-10-50-filtered: Suche in 2 Millionen Vektoren mit Filtern, k:10 und n:50

• knn-10-50-after-force-merge: Suche in 2 Millionen Vektoren mit Filtern und nach einer erzwungenen Zusammenführung, k:10 und n:50

• knn-10-100: Suche in 2 Millionen Vektoren ohne Filter, k:10 und n:100

• knn-10-100-filtered: Suche in 2 Millionen Vektoren mit Filtern, k:10 und n:100

• knn-10-100-after-force-merge: Suche in 2 Millionen Vektoren mit Filtern und nach einer erzwungenen Zusammenführung, k:10 und n:100

• knn-100-1000: Suche in 2 Millionen Vektoren ohne Filter, k:100 und n:1000

• knn-100-1000-filtered: Suche in 2 Millionen Vektoren mit Filtern, k:100 und n:1000

• knn-100-1000-after-force-merge: Suche in 2 Millionen Vektoren mit Filtern und nach einer erzwungenen Zusammenführung, k:100 und n:1000

• exact-knn: Exakte KNN-Suche mit und ohne Filter.

Elasticsearch ist in diesem Test durchweg schneller als OpenSearch, nur in zwei Fällen ist OpenSearch schneller, jedoch nicht viel (knn-10-100 und knn-100-1000). Aufgaben mit knn-10-50, knn-10-100 und knn-100-1000 in Kombination mit Filtern zeigen einen Unterschied von bis zu dem Siebenfachen (112 ms vs. 803 ms).

Die Leistung beider Lösungen scheint sich nach einem „force-merge“ verständlicherweise anzugleichen, wie knn-10-50-after-force-merge, knn-10-100-after-force-merge und knn-100-1000-after-force-merge zeigen. Bei diesen Aufgaben ist faiss schneller.

Die Leistung beim exakten kNN ist erneut sehr unterschiedlich, wobei Elasticsearch diesmal 13 Mal schneller ist als OpenSearch (~385 ms vs. ~5262 ms).

Recall

knn-recall-10-100

knn-recall-100-1000

knn-recall-10-50

Elasticsearch-8.14.0@lucene-hnsw

1

1

1

Elasticsearch-8.14.0@lucene-int8_hnsw

1

0,986667

1

OpenSearch-2.14.0@lucene-hnsw

1

1

1

OpenSearch-2.14.0@faiss

1

1

1

OpenSearch-2.14.0@faiss-sq_fp16

1

1

1

OpenSearch-2.14.0@nmslib

0,9674

0,910303

0,976394

Elasticsearch und Lucene als klare Sieger

Bei Elastic entwickeln wir Apache Lucene und Elasticsearch ständig weiter, um sicherzustellen, dass wir die führende Vektordatenbank für Such- und Abrufanwendungsfälle bereitstellen können, einschließlich RAG (Retrieval-Augmented Generation). Unsere jüngsten Fortschritte haben die Leistung drastisch gesteigert und, aufbauend auf den Vorteilen von Lucene 9.10, die Vektorsuche noch schneller und platzsparender gemacht. In diesem Blog wurde eine Studie vorgestellt, die zeigt, dass Elasticsearch beim Vergleich aktueller Versionen bis zu 12 Mal schneller ist als OpenSearch.

Es ist erwähnenswert, dass beide Produkte dieselbe Version von Lucene verwenden (Versionshinweise zu Elasticsearch 8.14 und zu OpenSearch 2.14).

Das Innovationstempo bei Elastic wird nicht nur für unsere On-Prem- und Elastic Cloud-Kunden, sondern auch für diejenigen, die unsere zustandslose Plattform nutzen, noch mehr bieten. Features wie die Unterstützung der skalaren Quantisierung auf int4 werden mit strengen Tests angeboten, um sicherzustellen, dass Kunden diese Techniken ohne signifikanten Rückgang der Abrufe nutzen können, ähnlich wie bei unseren Tests für int8.

Die Effizienz der Vektorsuche wird aufgrund der Verbreitung von KI- und Machine Learning-Anwendungen allmählich zu einem unverzichtbaren Feature in modernen Suchmaschinen. Für Unternehmen, die nach einer leistungsstarken Suchmaschine suchen, die in der Lage ist, mit den Anforderungen an großvolumige, hochkomplexe Vektordaten Schritt zu halten, ist Elasticsearch die definitive Antwort.

Egal, ob Sie eine etablierte Plattform erweitern oder neue Projekte initiieren – die Integration von Elasticsearch für Vektorsuchen ist ein strategischer Schritt, der greifbare, langfristige Vorteile bringen wird. Mit seinem nachgewiesenen Leistungsvorteil ist Elasticsearch bereit, die nächste Welle von Innovationen im Bereich des Suchens zu unterstützen.