Wie wir Elasticsearch simdvec entwickelten

Jede Vektorsuchanfrage in Elasticsearch, sei es ein Hierarchical Navigable Small World (HNSW) Traversal, ein Inverted File (IVF) Scan oder ein Reranking-Pass, reduziert sich auf dasselbe Problem: die Berechnung der Distanzen zwischen Vektoren, und zwar millionenfach pro Anfrage. Elasticsearch unterstützt eine breite Palette von Datentypen und Quantisierungsstrategien, von float32 über int8, bfloat16, binär und Better Binary Quantization (BBQ). Jede Option bringt unterschiedliche Kompromisse zwischen Speicher, Durchsatz und Abruf mit sich. Hinter all dem steht eine einzige Engine: simdvec.

Wir haben simdvec so entwickelt, dass jede Entfernungsberechnung so schnell erfolgt, wie es die Hardware erlaubt. In diesem Beitrag geht es darum, warum wir sie entwickelt haben, was in ihr steckt und wo sie die größte Wirkung erzielt.

Gebaut wie ein Rennwagen

Als Formel-1-Enthusiasten, mit einer Person, die bereits mit dem Formel-1-Team von Ferrari gearbeitet hat, sehen wir eine klare Parallele. Ein Formel-1-Wagen wird mit einem einzigen Ziel entwickelt: die beste Rundenzeit zu erzielen. Motorleistung, Aerodynamik und Fahrwerkskonstruktion spielen nur insofern eine Rolle, als dass sie zu diesem Ergebnis beitragen. Das Gleiche gilt für eine Vektordatenbank, in der Indexierungsdurchsatz, Abfragelatenz und Rückruf den Erfolg definieren.

Das Endergebnis ist zwar wichtig, aber um ein Höchstmaß an Leistung zu erreichen, muss jede Komponente ihr Bestes geben. Es reicht nicht, wenn sie einfach nur gut sind, sie müssen die Besten in ihrer Kategorie sein. Simdvec wurde mit dieser Denkweise entwickelt und konzentriert sich auf einen entscheidenden Teil des Systems: die Engine. Sie ist eine zweckgebundene, Single Instruction Multiple Data (SIMD) optimierte Kernel-Bibliothek, die von Hand optimierte, native C++ Distanzfunktionen bereitstellt, die von Java über die Panama Foreign Function Interface (FFI) aufgerufen werden. Sie unterstützt Bulk-Scoring, Prefetching von Cache-Linien sowie alle in Elasticsearch verwendeten Vektortypen und Layouts.

Das ist der Motor hinter jeder Abfrage.

Warum wir unser eigenes System entwickelt haben

Wir haben 2023 mit der Panama Vector API in Apache Lucene begonnen. Für float32-Punktprodukte war das zunächst ideal, doch die Anforderungen von Elasticsearch überstiegen schnell die Möglichkeiten des Systems. Elasticsearch unterstützt eine breite Palette quantisierter Vektortypen: int8, int4, bfloat16, Single-Bit und asymmetrisches BBQ. Jedes System verfügt über unterschiedliche SIMD-Strategien, Packungs- und Akkumulatoranforderungen. Über die Typabdeckung hinaus verlangen die Scoring-Pfade von Elasticsearch mehr als einen Durchsatz für einzelne Paare: HNSW muss mehrere Graphnachbarn in einem Durchgang bewerten, IVF benötigt eine Massenbewertung von Tausenden von Kandidaten mit Vorabruf und die auf Festplatten basierte Bewertung muss direkt auf dem mmap-Speicher arbeiten, ohne zu kopieren. Kein Angebot auf dem Markt deckte das gesamte Spektrum ab.

Also haben wir simdvec entwickelt: Von Hand optimierte, native C++-Kernel, die über FFI aus Java aufgerufen werden, mit Bulk-Scoring, Prefetching und Unterstützung für jeden von Elasticsearch verwendeten Vektortyp. Als Inhaber der Bibliothek kontrollieren wir den gesamten Stack. Wenn wir einen neuen Quantisierungstyp wie BBQ hinzufügen, wird ein optimierter SIMD-Kernel im gesamten System integriert. Wir warten nicht auf die Unterstützung durch eine Upstream-Bibliothek und gehen absolut keine Kompromisse bei der Leistung ein. Jede Vektorabfrage in Elasticsearch, ob HNSW, IVF, Reranking oder Hybrid, läuft auf dieser Engine, die auf den von uns tatsächlich verwendeten Operationen und Typen aufbaut.

Simdvec verfügt über separate native Bibliotheken für x86 und ARM, wobei jeweils mehrere ISA-Ebenen (Instruction Set Architecture) beim Starten ausgewählt werden. Der Call-Overhead von Java über FFI ist mit einstelligen Nanosekunden sehr gering.

Die Landschaft

Wir sind nicht die Einzigen, die SIMD-optimierte Vektordistanz-Kernel erstellen. Das Ökosystem ist vielfältig und wir wollten verstehen, wie simdvec funktioniert. Nicht um Projekte zu bewerten, sondern um Kontext zu liefern und zu erklären, wo die Elasticsearch-Engine angesiedelt ist. Wir haben drei Projekte als Referenzpunkte ausgewählt, die jeweils einen anderen Ansatz repräsentieren:

• jvector: Eine Java-Bibliothek für Approximate Nearest Neighbor (ANN), die die Panama Vector API für vektorisierte Entfernungsberechnungen verwendet, mit optionaler nativer C-Beschleunigung auf x86.

• FAISS: Ein weit verbreitetes Open-Source-Framework zur Vektorsuche mit von Hand optimierten AVX2/AVX-512-Kernel.

• NumKong (ehemals SimSIMD): Eine umfassende Suite von über 2.000 von Hand optimierten SIMD-Kernel über Distanzfunktionen, Matrixoperationen und georäumliche Berechnungen.

Jedes Projekt verfolgt einen anderen Zweck und geht unterschiedliche Kompromisse ein. Wir fügen daraus Referenznummern hinzu, um Kontext für die Leistung von simdvec bei den spezifischen Abläufen zu erhalten, die Elasticsearch benötigt.

Wie wir messen

Die simdvec- und jvector-Benchmarks wurden in Java mit JMH, dem Standard JVM-Microbenchmark-Harness, geschrieben, einschließlich FFI-Overhead. Für die NumKong-Benchmarks und die FAISS-Benchmarks haben wir mit Google Benchmark, dem Standard-C++-Mikrobenchmark-Framework, kleine C/C++-Harnesses geschrieben. Beide Frameworks melden Nanosekunden pro Operation mit Aufwärmung und Iterationskalibrierung. Wir haben anhand von Hardware-Leistungszählern überprüft, dass alle Bibliotheken auf beiden Plattformen SIMD verwenden. Der gesamte Benchmark-Code ist in den verlinkten GitHub-Repositories (und im Fall von simdvec im Elasticsearch-Repository) öffentlich verfügbar.

Software: JDK 25.0.2, JMH 1.37, GCC 14, Google Benchmark (neueste Version).

Ein Vektor nach dem anderen

Die grundlegendste Funktion der Vektorsuche ist die Berechnung des Abstands zwischen zwei Vektoren. Jede HNSW-Nachbarbewertung, jede IVF-Kandidatenbewertung und jeder Reranking-Vergleich dreht sich um diese interne Schleife.

Wir haben den Durchsatz einzelner Datenpaare in 1024 Dimensionen auf beiden Plattformen gemessen, beginnend mit float32, dem Basistyp, bei dem das Ökosystem am wettbewerbsfähigsten ist. Wir vergleichen simdvec mit FAISS und jvector, wobei wir NumKong ausgeschlossen haben, da es float64-Akkumulatoren für float32 verwendet, was es je nach Plattform 3,2- bis 5,3-mal langsamer macht und numerische Präzision über Durchsatz gestellt wird. Um den Vergleich nicht zu verfälschen, testen wir NumKong stattdessen auf int8, wo es die gleiche Akkumulatorstrategie wie simdvec verwendet.

Auf x86 ist FAISS AVX-512 der schnellste Einzelpaar-Kernel mit 23 ns. Simdvec AVX-512 folgt mit 28 ns, eine Lücke, die den Overhead des FFI-Aufrufs widerspiegelt. Beide verwenden 512-Bit-FMA mit Multi-Akkumulator-Unrolling. Auf der AVX2-Ebene liegen die beiden sehr viel näher beieinander, nämlich 36 ns bzw. 39 ns, die beide durch die 256-Bit-Register- und Speicherladebreiten eingeschränkt sind. jvector landet bei 44 ns mit der Java Panama Vector API. Panama generiert guten SIMD-Code, aber von Hand optimierte C++-Intrinsics sind hier im Vorteil

Auf ARM liegt simdvec mit 70 ns deutlich vor jvector mit 110 ns und FAISS mit 156 ns. Simdvec verfügt über von Hand optimierte NEON-Kernel für aarch64. Jvector hat keinen nativen ARM-Code und basiert auf Panama. FAISS verlässt sich auf die automatische Vektorisierung des Compilers und nicht auf explizite NEON-Intrinsics, was den größeren Abstand erklärt. Dies spiegelt einen praktischen Vorteil des Besitzes der Kernel-Bibliothek wider: Als Elasticsearch zu Graviton erweitert wurde, fügten wir eigens entwickelte NEON-Kernel hinzu. Weder jvector noch FAISS haben nativem ARM-Code den gleichen Stellenwert eingeräumt.

Elasticsearch bewertet aber nicht nur float32. Int8-Quantisierung reduziert den Speicher um das Vierfache, bfloat16 um das Doppelte und BBQ um das 32-Fache. Jeder Typ benötigt seine eigene SIMD-Strategie und simdvec bietet von Hand optimierte, native Kernel für alle diese Typen.

Von den Bibliotheken, die wir verglichen haben, hat nur NumKong vergleichbare Kernel für int8. Wir haben das int8-Skalarprodukt, die quadrierte euklidische Distanz und den Kosinus bei 1024 Dimensionen gemessen.

Int8 Einzelpaar-Wertung (1024 Dimensionen, ns/vec op – je niedriger, desto besser)

Auf beiden Architekturen ist NumKong bei kleinen bis mittleren Dimensionen gleich schnell oder sogar schneller, wobei der Unterschied hauptsächlich auf den geringeren Call-Overhead zurückzuführen ist (direkter C-Call vs. Java FFI). Bei größeren Dimensionen holt simdvec auf, wobei die effizientere Kernel-Implementierung (die Cascade Unrolling verwendet) die Aufrufkosten amortisiert: Mit zunehmender Dimension schließt sich diese Lücke und kehrt sich schließlich um. Die Übergangsdimensionen liegen je nach Funktion und Architektur zwischen 768 und 1536.

Trotz des etwas höheren Aufwands von Java FFI befindet sich simdvec mit hochoptimierten C/C++-Bibliotheken auf Augenhöhe. Sie ist nicht nur die einzige Bibliothek mit optimierten Kernel für float32 und int8, sondern führt auch beim ARM und liegt auf x86 (für float32) nur leicht hinter FAISS zurück und auf beiden Architekturen sehr nahe an NumKong (für int8). Für bfloat16, int4, binär und BBQ gibt es zwar Alternativen, aber simdvec zeichnet sich durch von Hand optimierte SIMD aus, die auf das Datenlayout jedes Typs zugeschnitten ist.

Eine Produktionssuchmaschine bewertet jedoch nicht einen Vektor nach dem anderen, sondern Tausende pro Abfrage. Die nächste Frage ist, was in diesem Maßstab passiert.

Tausende auf einmal

Die Leistung eines einzelnen Paares stellt nur einen Teil des Gesamtbildes dar. In der Praxis ist entscheidend, wie sich Systeme unter Last verhalten. Eine einzelne HNSW-Abfrage kann Hunderte von Nachbarn im Graphen bewerten. Ein IVF-Scan kann Tausende von Einträgen in Posting-Listen bewerten. Ein Reranking-Durchlauf kann Zehntausende von Kandidaten bewerten. Der Durchsatz pro Paar ist wichtig, aber noch wichtiger ist, wie schnell Sie viele Vektoren bewerten können und wie gut die Leistung nachlässt, wenn das Working Set nicht mehr in die CPU-Caches passt.

Simdvec bietet Bulk-Scoring für jeden Datentyp. Dabei handelt es sich nicht nur um Schleifen über Single-Pair-Kerne, sondern auch um innere Schleifen mit mehreren Akkumulatoren, die den Abfragevektor einmal pro Dimensionsschritt laden und ihn auf mehrere Dokumentvektoren verteilen, mit explizitem Cache-Line-Prefetching für den nächsten Batch. Weder jvector noch FAISS bieten ein Äquivalent (zum jetzigen Zeitpunkt). Jvector hat keine Bulk-API, sodass der Aufrufer ein Paar nach dem anderen in einer Schleife bewertet. FAISS stellt fvec_inner_products_ny zur Verfügung, das zum Zeitpunkt der Erstellung dieses Artikels als Schleife über die Single-Pair-Distanzfunktion ohne Amortisierung der Abfrage oder Vorabruf implementiert ist.

Float32. Um die Wirkung auf Kernel-Ebene zu messen, bewerteten wir eine einzelne Abfrage gegen zunehmende Zahlen von 1024-Dimension-float32-Dokumentvektoren mit Random-Access-Mustern, die HNSW-ähnliche verstreute Graph-Nachbarschaftsabfragen simulieren. Die drei Datensatzgrößen von 32, 625 und 32.500 Vektoren werden so gewählt, dass der Arbeitssatz den L1-, L2- und L3-Cache übersteigt.

Wenn die Daten in den Cache passen, ist simdvec auf beiden Plattformen am schnellsten, aber die Margen sind moderat, da die Kernel-Arithmetik dominiert. Die tatsächliche Trennung zeigt sich, wenn der Arbeitssatz über L3 hinauswächst. Auf x86 erzielt simdvec 95 ns pro Vektor, während FAISS 165 ns und jvector 412 ns benötigt. Auf ARM ist das Muster dasselbe: simdvec bleibt bei 162 ns, während FAISS auf 347 ns und jvector auf 476 ns ansteigt. Das Prefetching und die Abfrage-Amortisierung in simdvec verbergen die Speicherlatenz auf eine Weise, die eine einfache Schleife über Einzelpaar-Kernel nicht erreichen kann, und der Vorteil erweitert sich genau dort, wo reale Suchworkloads tief im Hauptspeicher arbeiten.

Int8. Das gleiche Muster gilt für quantisierte Datentypen. Wir haben die Bulk-Bewertung von int8-Punktprodukten in 1024 Dimensionen mit Datensatzgrößen gemessen, die so gewählt wurden, dass sie die gleichen L1-, L2- und L3-Cache-Grenzen überschritten, und die Bulk-Bewertung von simdvec mit der Single-Pair-Bewertung von NumKong in einer Schleife verglichen.

Auf x86 ist simdvec zwischen 1,2-mal und 1,9-mal schneller, was auf die Kombination aus explizitem Prefetching und Batch-Verarbeitung zurückzuführen ist. Auf ARM ist simdvec bei allen Datensätzen erneut im Vorteil (1,7- bis 1,9-mal schneller). Der Vorteil liegt in der Batch-Verarbeitung von vier Vektoren auf einmal, die über ein verschachteltes Zugriffsmuster Parallelisierung auf Speicherebene bietet. In beiden Fällen ist das auffälligste Ergebnis, was bei der größten Datensatzgröße passiert, wo es am wichtigsten ist.

Die Ergebnisse für quadrierten Abstand und Kosinus zeigen ein ähnliches Muster, mit Beschleunigungen von 1,4x bis 1,8x für ARM und von 1,3x bis 3,0x für x86 (mehr dazu hier).

Wo Speicher eine Rolle spielt

Vektorindizes in der Produktion passen normalerweise nicht in den CPU-Cache. Ein 10M-Vektor-Int8-Index bei 1024 Dimensionen entspricht 10 GB. Die Bewertung von Kandidaten bedeutet das Streamen von Daten aus dem DRAM, und genau hier macht die Architektur für die Massenbewertung den Unterschied.

Wir verwendeten Hardware-Leistungszähler, um zu messen, was während der Massenbewertung innerhalb der CPU passiert, und stellten fest, dass das Verbergen der Speicherlatenz zwei grundlegend verschiedene Strategien erfordert: eine pro Architektur.

Auf x86 eliminiert explizites Prefetching Cache-Fehler. Der Bulk-Kernel verarbeitet Vektoren sequenziell – einen nach dem anderen vollständig berechnet – während er gleichzeitig Prefetch-Anweisungen für den nächsten Batch ausgibt. Künftige Daten werden in den L1-Cache geladen, bevor die CPU sie benötigt.

Auf ARM funktionierte derselbe sequentielle Ansatz nicht so gut, selbst mit Prefetching. Stattdessen verschachtelt der Bulk-Kernel Ladungen von vier Vektoren an jeder Schrittposition, wodurch die Out-of-Order-Engine vier unabhängige Speicherstreams erhält. Die CPU holt Daten nicht schneller, sondern wartet vielmehr weniger, weil sie während der Bearbeitung von Speicheranfragen immer etwas anderes zu berechnen hat. Eine detaillierte Analyse finden Sie in diesem GitHub-Issue.

Die Zahlen erzählen zwei unterschiedliche Geschichten:

1. Auf x86 verwandelt Prefetching 139K Cache-Fehler in 19K und die Anweisungen pro Zyklus (IPC) werden mehr als verdoppelt. Der Massenvorteil wächst mit der Größe der Datensätze, von 1,2-mal in L2 bis 2,8-mal jenseits von L3, weil das Prefetching zunehmend teurere DRAM-Roundtrips verbirgt.

2. Bei ARM ändern sich Cache-Fehler kaum. Was sich ändert, ist die Auslastung: Backend-Verzögerungen sinken um 40 %, da das verschachtelte Zugriffsmuster die Pipeline füttert. Dieser Vorteil bleibt konstant bei 1,8-mal, unabhängig von der Größe der Datensätze, da die Parallelität auf Speicherebene gilt, unabhängig davon, ob Daten aus dem Cache oder dem DRAM stammen.

Zwei Architekturen, zwei Strategien, ein Ergebnis: Im Produktionsmaßstab beschäftigt simdvec die CPU-Pipeline durchgehend, selbst wenn die Vektoren über den Hauptspeicher verteilt sind.

Was das für Elasticsearch-Nutzer bedeutet

Diese Fähigkeiten auf Kernel-Ebene verstärken sich gegenseitig. Eine einzelne Vektorsuchabfrage kann Millionen von Distanzoperationen berechnen: HNSW-Graph-Durchläufe, Kandidatenbewertung, Neusortierung. Bei Tausenden gleichzeitiger Abfragen lassen sich Nanosekunden pro Operation direkt in Abfragelatenz und Cluster-Durchsatz umrechnen. Egal ob Sie float32, int8, bfloat16 oder BBQ verwenden, egal ob sich Ihr Index im Arbeitsspeicher oder auf der Festplatte befindet, simdvec ist die zugrunde liegende Engine, wobei jede dieser Operationen über dieselbe Engine läuft, die bis auf die letzte Nanosekunde genau abgestimmt ist.

Die wichtigste Erkenntnis ist, dass die Leistung der Vektorsuche im Produktionsmaßstab nicht primär durch den reinen SIMD-Durchsatz bestimmt wird. Entscheidend ist, wie effizient das System die Speicherlatenz verbirgt und gleichzeitig die Rechenleistung über Millionen kleiner Operationen hinweg aufrechterhält.

Die simdvec-Kernel werden mit fast jeder Elasticsearch-Version verbessert. Wenn neue Quantisierungstypen und Hardwareplattformen entstehen, erhalten sie von Anfang an optimierte Kernel. Und die bestehenden Typen werden immer schneller, während wir die bereits ausgelieferten Implementierungen optimieren.

Warum das wichtig ist

Die meisten typischen analytischen Workflows laufen letztendlich auf die Gruppierung von Daten hinaus. Ob es nun um die Berechnung der durchschnittlichen Bytes pro Host, das Zählen von Ereignissen pro Nutzer oder das Aggregieren von Metriken über Dimensionen hinweg geht, die Kernoperation ist immer dieselbe – Schlüssel werden Gruppen zugeordnet und laufende Aggregate aktualisiert.

In kleinem Maßstab funktioniert fast jede vernünftige Hashtabelle einwandfrei. Bei großer Skalierung (Hunderte Millionen Dokumente und Millionen verschiedener Gruppen) beginnen Details eine Rolle zu spielen. Auslastungsfaktoren, Sondierungsstrategie, Speicherlayout und Cache-Verhalten können den Unterschied zwischen linearer Leistung und einer Flut von Cache-Fehlern ausmachen.

Elasticsearch unterstützt diese Workloads seit Jahren und wir suchen stets nach Möglichkeiten, die Kernalgorithmen zu modernisieren. Daher haben wir einen neueren, von Schweizer Tabellen inspirierten Ansatz evaluiert und ihn auf die Art und Weise angewendet, wie ES|QL Statistiken berechnet.

Was genau sind Schweizer Tabellen?

Schweizer Tabellen sind eine Familie moderner Hash-Tabellen, die von Googles SwissTable popularisiert und später in Abseil und anderen Bibliotheken übernommen wurden.

Traditionelle Hash-Tabellen verbringen viel Zeit damit, Zeiger zu verfolgen oder Schlüssel zu laden, nur um festzustellen, dass sie nicht übereinstimmen. Das definierende Feature von Schweizer Tabellen ist die Fähigkeit, die meisten Anfragen mit einer winzigen, im Cache befindlichen Array-Struktur abzulehnen, die getrennt von Schlüsseln und Werten gespeichert wird und als Kontrollbytes bezeichnet wird, um den Speicherverkehr drastisch zu reduzieren.

Jedes Kontrollbyte repräsentiert einen einzelnen Slot und kodiert in unserem Fall zwei Dinge: ob der Slot leer ist und einen kurzen Fingerabdruck, der aus dem Hash abgeleitet wird. Diese Steuerbytes sind zusammenhängend im Speicher angeordnet, typischerweise in Gruppen von 16, was sie ideal für die SIMD-Verarbeitung (Single Instruction, Multiple Data).

Anstatt einen Slot nach dem anderen zu testen, scannen Schweizer Tabellen einen gesamten Kontrollbyte-Block mithilfe von Vektorinstruktionen. In einer einzigen Operation vergleicht die CPU den Fingerabdruck des eingehenden Schlüssels mit 16 Slots und filtert leere Einträge heraus. Nur bei den wenigen Kandidaten, die diesen Schnelltest überstehen, ist das Laden und Vergleichen der tatsächlichen Schlüssel erforderlich.

Dieses Design tauscht eine kleine Menge zusätzlicher Metadaten gegen eine viel bessere Cache-Lokalität und weitaus weniger zufällige Ladevorgänge ein. Wenn die Tabelle wächst und die Sondenketten länger werden, werden diese Eigenschaften immer wertvoller.

SIMD im Mittelpunkt

Der eigentliche Star der Show ist SIMD.

Die Steuerbytes sind nicht nur kompakt, sondern auch explizit für die Verarbeitung mit Vektorbefehlen konzipiert. Ein einzelner SIMD-Vergleich kann 16 Fingerabdrücke gleichzeitig überprüfen und verwandelt, was normalerweise eine Schleife wäre, in eine Handvoll breiter Operationen. Zum Beispiel:

In der Praxis bedeutet das:

• Weniger Zweige.

• Kürzere Testketten.

• Weniger Ladevorgänge aus Schlüssel- und Wertspeicher.

• Viel bessere Nutzung der Ausführungseinheiten der CPU.

Die meisten Suchvorgänge kommen nie über den Control-Byte-Scan hinaus. Wenn sie das tun, ist die verbleibende Arbeit zielgerichtet und vorhersehbar. Das ist genau die Art von Arbeitslast, für die moderne CPUs gut geeignet sind.

SIMD unter der Haube

Für Leser, die gerne einen Blick hinter die Kulissen werfen, hier eine Erklärung, was beim Einfügen eines neuen Schlüssels in die Tabelle passiert. Wir verwenden die Panama Vector API mit 128-Bit-Vektoren und bearbeiten somit 16 Kontrollbytes parallel.

Der folgende Ausschnitt zeigt den Code, der auf einem Intel Rocket Lake mit AVX-512 generiert wurde. Obwohl die Anweisungen diese Umgebung widerspiegeln, hängt das Design nicht von AVX-512 ab. Die gleichen hochstufigen Vektoroperationen werden auf anderen Plattformen mit gleichwertigen Befehlen (zum Beispiel AVX2, SSE oder NEON) ausgesendet.

Jede Anweisung hat eine klare Rolle im Einfügeprozess:

• vmovdqu: Lädt 16 aufeinanderfolgende Steuerbytes in das 128-Bit-xmm0-Register.

• vpbroadcastb: Repliziert den 7-Bit-Fingerabdruck des neuen Schlüssels über alle Spuren des xmm1-Registers.

• vpcmpeqb: Vergleicht jedes Steuerbyte mit dem gesendeten Fingerabdruck und erstellt eine Maske mit möglichen Übereinstimmungen.

• kmovq + test: Verschiebt die Maske in ein allgemeines Register und überprüft schnell, ob ein Match existiert.

Schließlich entschieden wir uns dafür, Gruppen von jeweils 16 Kontrollbytes zu untersuchen, da Benchmarks zeigten, dass eine Erweiterung auf 32 oder 64 Bytes mit breiteren Registern keinen messbaren Leistungsvorteil brachte.

Integration in ES|QL

Die Einführung des Hashing im Schweizer Stil in Elasticsearch war nicht einfach ein direkter Ersatz. ES|QL stellt hohe Anforderungen an die Speicherverwaltung, die Sicherheit und die Integration mit dem Rest der Compute Engine.

Wir haben die neue Hash-Tabelle eng in die Speicherverwaltung von Elasticsearch integriert, einschließlich des Seitenrecyclers und der Abrechnung von Schutzschaltern, um sicherzustellen, dass die Zuweisungen sichtbar und begrenzt bleiben. Die Aggregationen von Elasticsearch werden dicht gespeichert und durch eine Gruppen-ID indexiert, wodurch das Speicherlayout kompakt und schnell für Iterationen bleibt und zudem bestimmte Leistungsoptimierungen durch zufälligen Zugriff ermöglicht werden.

Bei Byte-Schlüsseln mit variabler Länge wird der vollständige Hash zusammen mit der Gruppen-ID zwischengespeichert. Dadurch wird die Neuberechnung teurer Hash-Codes während der Sondierung vermieden und die Cache-Lokalität verbessert, indem zusammengehörige Metadaten nahe beieinander gehalten werden. Während des Rehashings können wir uns auf den zwischengespeicherten Hash und die Kontroll-Bytes verlassen, ohne die Werte selbst zu inspizieren, wodurch die Kosten für die Größenänderung niedrig gehalten werden.

Eine wichtige Vereinfachung in unserer Implementierung besteht darin, dass Einträge niemals gelöscht werden. Dadurch werden Tombstones (Markierungen zur Identifizierung zuvor belegter Steckplätze) überflüssig, und leere Steckplätze bleiben wirklich leer, was das Verhalten der Sonde weiter verbessert und Kontroll-Byte-Scans effizient macht.

Das Ergebnis ist ein Design, das sich nahtlos in das Ausführungsmodell von Elasticsearch einfügt und gleichzeitig die Leistungsmerkmale beibehält, die Schweizer Tabellen so attraktiv machen.

Wie ist die Performance?

Bei kleinen Kardinalitäten schneiden die Schweizer Tabellen in etwa gleich gut ab wie die bestehende Implementierung. Das ist zu erwarten: Bei kleinen Tabellen spielen Cache-Effekte eine geringere Rolle und es gibt wenig Optimierungsbedarf.

Mit zunehmender Kardinalität ändert sich das Bild schnell.

Die obige Heatmap zeigt die Zeitverbesserungsfaktoren für verschiedene Schlüsselgrößen (8, 32, 64 und 128 Byte) über Kardinalitäten von 1.000 bis 10.000.000 Gruppen hinweg. Mit zunehmender Kardinalität steigt der Verbesserungsfaktor stetig an und erreicht bei Gleichverteilungen Werte von bis zu 2–3x.

Dieser Trend entspricht genau dem, was die Konstruktion vorhersagt. Höhere Kardinalität führt zu längeren Prüfketten in traditionellen Hash-Tabellen, während die meisten Suchvorgänge nach wie vor in SIMD-freundlichen Kontroll-Byte-Blöcken gelöst werden.

Das Cache-Verhalten erzählt die Geschichte

Um die Beschleunigungen besser zu verstehen, haben wir denselben JMH-benchmarks unter Linux perf ausgeführt und Cache- sowie TLB-Statistiken erfasst.

Im Vergleich zur ursprünglichen Implementierung benötigt die Schweizer Version insgesamt etwa 60 % weniger Cache-Zugriffe. Die Last-Level-Cache-Ladevorgänge sinken um mehr als das Vierfache, und LLC-Ladefehler gehen um mehr als das Sechsfache zurück. Da LLC-Fehlzugriffe oft direkt in Hauptspeicherzugriffe übersetzt werden, erklärt diese Reduzierung allein einen großen Teil der End-to-End-Verbesserung.

Näher an der CPU beobachten wir weniger L1-Datencache-Fehler und fast 6x weniger TLB-Datenfehler, was auf eine engere räumliche Lokalität und besser vorhersagbare Speicherzugriffsmuster hindeutet.

Dies ist der praktische Nutzen von SIMD-freundlichen Kontrollbytes. Anstatt Schlüssel und Werte immer wieder von verstreuten Speicherplätzen zu laden, werden die meisten Suchvorgänge durch das Durchsuchen einer kompakten, im Cache befindlichen Struktur gelöst. Weniger berührter Speicher bedeutet weniger Fehltritte, und weniger Fehltritte bedeuten schnellere Abfragen.

Fazit

Indem wir einen Hashtabellenentwurf im Schweizer Stil verwendeten und uns stark auf SIMD-freundliche Sondierungen konzentrierten, erreichten wir 2–3-fache Beschleunigungen für ES|QL-Statistik-Workloads mit hoher Kardinalität sowie eine stabilere und vorhersehbarere Leistung.

Diese Arbeit zeigt, wie moderne CPU-fähige Datenstrukturen erhebliche Verbesserungen ermöglichen können, selbst bei bekannten Problemen wie Hash-Tabellen. Hier gibt es mehr Raum für Erkundungen, wie etwa zusätzliche Spezialisierungen von primitiven Typen und die Verwendung in anderen Pfaden mit hoher Kardinalität, wie Joins, die alle Teil der umfassenderen und fortlaufenden Bemühungen sind, die internen Abläufe von Elasticsearch kontinuierlich zu modernisieren.

Wenn Sie an den Details interessiert sind oder die Arbeit verfolgen möchten, schauen Sie sich diesen Pull Request und den Meta-Issue-Fortschritt auf Github an.

Viel Spaß beim Hashing!

Zusammenfassung

Zunächst einmal ein kurzer Überblick. Elasticsearch hat sich als leistungsstarke Vektordatenbank etabliert und bietet eine Vielzahl von Funktionen sowie eine hohe Leistungsfähigkeit für die Ähnlichkeitssuche im großen Maßstab. Mit Funktionen wie Skalarquantisierung, Better Binary Quantization (BBQ), SIMD- Vektoroperationen und speichereffizienteren Algorithmen wie DiskBBQ bietet es bereits effiziente und flexible Optionen für die Verwaltung von Vektor-Workloads.

Durch die Integration von NVIDIA cuVS als aufrufbares Modul für Vektorsuchaufgaben wollen wir signifikante Verbesserungen bei der Vektorindizierungsleistung und -effizienz erzielen, um große Vektor-Workloads besser zu unterstützen.

Die Herausforderung

Eine der größten Herausforderungen beim Aufbau einer leistungsstarken Vektordatenbank ist die Konstruktion des Vektorindexes – des HNSW-Graphen. Die Indexbildung wird schnell von Millionen oder sogar Milliarden arithmetischer Operationen dominiert, da jeder Vektor mit vielen anderen verglichen wird. Darüber hinaus können Index-Lebenszyklusoperationen wie Komprimierung und Zusammenführungen den gesamten Rechenaufwand für die Indizierung weiter erhöhen. Da Datenmengen und die damit verbundenen Vektoreinbettungen exponentiell wachsen, sind beschleunigte Rechen-GPUs, die für massive Parallelität und mathematische Berechnungen mit hohem Durchsatz ausgelegt sind, ideal für die Bewältigung dieser Arbeitslasten geeignet.

Öffnen Sie das Elasticsearch-GPU-Plugin.

NVIDIA cuVS ist eine Open-Source-CUDA-X-Bibliothek für GPU-beschleunigte Vektorsuche und Datenclustering, die schnelles Indexieren und Einbetten für KI- und Empfehlungs-Workloads ermöglicht.

Elasticsearch nutzt cuVS über cuvs-java, eine Open-Source-Bibliothek, die von der Community entwickelt und von NVIDIA gepflegt wird. Die cuvs-java Bibliothek ist leichtgewichtig und baut auf der cuVS C API auf, indem sie Panama Foreign Function verwendet, um cuVS-Funktionen auf idiomatische Java-Art bereitzustellen und dabei modern und leistungsstark zu bleiben.

Die cuvs-java-Bibliothek ist in ein neues Elasticsearch-Plugin integriert; daher kann die Vektorindizierung auf der GPU auf demselben Elasticsearch-Knoten und -Prozess erfolgen, ohne dass externer Code oder Hardware bereitgestellt werden muss. Während des Indexaufbaus nutzt Elasticsearch die GPU, um den Vektorindexierungsprozess zu beschleunigen, sofern die cuVS-Bibliothek installiert und eine GPU vorhanden und konfiguriert ist. Die Vektoren werden der GPU übergeben, die daraus einen CAGRA-Graphen erstellt. Dieser Graph wird dann in das HNSW-Format umgewandelt, wodurch er sofort für die Vektorsuche auf der CPU verfügbar ist. Das endgültige Format des erstellten Graphen ist identisch mit dem, das auf der CPU erstellt würde; dadurch kann Elasticsearch GPUs für die Vektorindizierung mit hohem Durchsatz nutzen, wenn die zugrunde liegende Hardware dies unterstützt, während gleichzeitig CPU-Leistung für andere Aufgaben (gleichzeitige Suche, Datenverarbeitung usw.) frei bleibt.

Beschleunigung des Indexaufbaus

Im Rahmen der Integration der GPU-Beschleunigung in Elasticsearch wurden mehrere Verbesserungen an cuvs-java vorgenommen, die sich auf einen effizienten Dateneingang/-ausgang und Funktionsaufruf konzentrieren. Eine wichtige Verbesserung ist die Verwendung von cuVSMatrix zur transparenten Modellierung von Vektoren, unabhängig davon, ob sie sich auf dem Java-Heap, außerhalb des Heaps oder im GPU-Speicher befinden. Dadurch können Daten effizient zwischen Arbeitsspeicher und GPU übertragen werden, wodurch unnötige Kopien von potenziell Milliarden von Vektoren vermieden werden.

Dank dieser zugrundeliegenden Zero-Copy-Abstraktion können sowohl die Übertragung in den GPU-Speicher als auch der Abruf des Graphen direkt erfolgen. Beim Indizieren werden die Vektoren zunächst im Speicher auf dem Java-Heap zwischengespeichert und dann an die GPU gesendet, um den CAGRA-Graphen zu erstellen. Der Graph wird anschließend von der GPU abgerufen, in das HNSW-Format konvertiert und auf der Festplatte gespeichert.

Beim Zusammenführen sind die Vektoren bereits auf der Festplatte gespeichert, wodurch der Java-Heap vollständig umgangen wird. Indexdateien sind speicherabgebildet und die Daten werden direkt in den GPU-Speicher übertragen. Das Design unterstützt zudem problemlos unterschiedliche Bitbreiten, z. B. float32 oder int8, und lässt sich natürlich auf andere Quantisierungsschemata erweitern.

Trommelwirbel ... wie gut funktioniert es?

Bevor wir zu den Zahlen kommen, ist ein bisschen Kontext hilfreich. Die Segmentzusammenführung in Elasticsearch läuft in der Regel automatisch im Hintergrund während der Indizierung, was ein isoliertes Benchmarking schwierig macht. Um reproduzierbare Ergebnisse zu erzielen, haben wir in einem kontrollierten Experiment die Segmentzusammenführung explizit mit der Funktion Force-Merge ausgelöst. Da Force-Merge die gleichen zugrunde liegenden Zusammenführungsoperationen wie das Zusammenführen im Hintergrund durchführt, dient seine Leistung als nützlicher Indikator für erwartete Verbesserungen, auch wenn die genauen Gewinne in realen Indexierungs-Workloads abweichen können.

Schauen wir uns nun die Zahlen an.

Unsere ersten Benchmark-Ergebnisse sind sehr vielversprechend. Wir haben den Benchmark auf einer AWS g6.4xlarge Instanz mit lokal angeschlossenem NVMe-Speicher ausgeführt. Ein einzelner Knoten von Elasticsearch wurde so konfiguriert, dass er die standardmäßige, optimale Anzahl von Indizierungs-Threads (8 – einer für jeden physischen Kern) verwendet und Merge Throttling deaktiviert (was bei schnellen NVMe-Festplatten weniger relevant ist).

Für den Datensatz verwendeten wir 2,6 Millionen Vektoren mit 1.536 Dimensionen aus der OpenAI Rally-Vektorstrecke, kodiert als Base64-Zeichenfolgen und indexiert als float32 hnsw. In allen Szenarien erreichen die konstruierten Graphen Recall-Werte von bis zu 95 %. Hier sind unsere Ergebnisse:

• Indizierungsdurchsatz: Durch die Verlagerung der Graphenkonstruktion auf die GPU während des Speicherpuffer-Flushs steigern wir den Durchsatz um das 12-fache.

• Force-Merge: Nach Abschluss der Indizierung beschleunigt die GPU weiterhin die Segmentzusammenführung und beschleunigt die Force-Merge-Phase um das ~7-fache.

• CPU-Auslastung: Durch die Auslagerung der Graph-Konstruktion auf die GPU werden sowohl die durchschnittliche als auch die maximale CPU-Auslastung deutlich reduziert. Die folgenden Graphen veranschaulichen die CPU-Auslastung während der Indizierung und Zusammenführung und zeigen, wie viel geringer sie ist, wenn diese Vorgänge auf der GPU ausgeführt werden. Eine geringere CPU-Auslastung während der GPU-Indexierung setzt CPU-Zyklen frei, die zur Verbesserung der Suchleistung umgeleitet werden können.

• Recall: Die Genauigkeit bleibt zwischen CPU- und GPU-Läufen praktisch gleich, wobei der mit der GPU erstellte Graph einen geringfügig höheren Recall erreicht.

Vergleich anhand einer weiteren Dimension: Preis

Beim vorherigen Vergleich wurde absichtlich identische Hardware verwendet; der einzige Unterschied bestand darin, ob die GPU während der Indizierung verwendet wurde. Diese Konfiguration ist nützlich, um die Auswirkungen der reinen Rechenleistung zu isolieren, aber wir können den Vergleich auch aus einer Kostenperspektive betrachten.

Bei etwa demselben Stundenpreis wie die GPU-beschleunigte Konfiguration kann man ein CPU-reines Setup mit etwa doppelt so vielen vergleichbaren CPU- und Speicherressourcen bereitstellen: 32 vCPUs (AMD EPYC) und 64 GB RAM, wodurch die Anzahl der Indexierungs-Threads auf 16 verdoppelt werden kann.

Um den Vergleich fair und konsistent zu halten, haben wir dieses reine CPU Experiment auf einer AWS g6.8xlarge Instanz ausgeführt, wobei die GPU explizit deaktiviert war. Dadurch konnten wir alle anderen Hardwareeigenschaften konstant halten und gleichzeitig den Kosten-Leistungs-Kompromiss zwischen GPU-Beschleunigung und reiner CPU-Indexierung evaluieren.

Die leistungsstärkere CPU-Instanz zeigt erwartungsgemäß eine verbesserte Performance im Vergleich zu den Benchmarks im obigen Abschnitt. Wenn wir jedoch diese leistungsstärkere CPU-Instanz mit den ursprünglichen GPU-beschleunigten Ergebnissen vergleichen, liefert die GPU immer noch erhebliche Leistungssteigerungen: ~5-fache Verbesserung des Indizierungsdurchsatzes und ~6-fache Verbesserung beim Force Merge, während gleichzeitig Graphen erstellt werden, die Recall-Werte von bis zu 95 % erreichen.

Fazit

In End-to-End-Szenarien bietet die GPU-Beschleunigung mit NVIDIA cuVS eine nahezu 12-fache Verbesserung des Indexierungsdurchsatzes und eine 7-fache Verringerung der Force-Merge-Latenz bei deutlich geringerer CPU-Auslastung. Dies zeigt, dass Vektorindizierungs- und Merge-Workloads erheblich von der GPU-Beschleunigung profitieren. Im Kostenvergleich bietet die GPU-Beschleunigung weiterhin deutliche Leistungssteigerungen, mit einem etwa 5-fach höheren Indexierungsdurchsatz und 6-fach schnelleren Force-Merge-Operationen.

Die GPU-beschleunigte Vektorindizierung ist derzeit für die Tech Preview in Elasticsearch 9.3 geplant, deren Veröffentlichung für Anfang 2026 vorgesehen ist.

Mehr dazu in Kürze.

Im Rahmen unserer Mission, keine Effizienz zu vernachlässigen, erkunden wir Beschleunigungsmöglichkeiten mit diesen merkwürdigen Computerchips, von denen Sie vielleicht schon gehört haben – NVIDIA-GPUs! (Im Ernst, nicht wahr?)

Wenn wir uns so sehr auf die Leistung konzentrieren, müssen wir mehrere Problembereiche untersuchen: Wie lassen sich exponentiell mehr Daten indizieren, wie lassen sich daraus Erkenntnisse gewinnen und wie geht das, wenn Ihre ML-Modelle beteiligt sind? Wenn Sie über GPUs verfügen, sollten Sie in der Lage sein, jeden noch so kleinen Vorteil auszuschöpfen.

In diesem Beitrag tauchen wir in unsere Zusammenarbeit mit dem NVIDIA-Vektorsuchteam ein, während wir die GPU-beschleunigte Vektorsuche in Elasticsearch erkunden. Diese Arbeit ebnet den Weg für Anwendungsfälle, in denen Entwickler eine Mischung aus GPUs und CPUs für reale, auf Elasticsearch basierende Apps verwenden können. Spannende Zeiten!

Elasticsearch-GPUs

Wir freuen uns, mitteilen zu können, dass das Elasticsearch-Entwicklungsteam dabei hilft, die Open-Source-CuVS-Java-API-Erfahrung für Entwickler aufzubauen, die Bindungen für Vektorsuchalgorithmen bereitstellt. Diese Arbeit nutzt unsere bisherigen Erfahrungen mit Panama FFI. Elasticsearch und Apache Lucene verwenden die NVIDIA cuVS-API, um den Graphen während der Indizierung zu erstellen. Okay, wir springen vor; spulen wir ein bisschen zurück.

NVIDIA cuVS, eine Open-Source-C++-Bibliothek, ist das Herzstück dieser Zusammenarbeit. Ziel ist es, die Vektorsuche durch GPU-Beschleunigung zu verbessern, indem ein höherer Durchsatz, geringere Latenz und schnellere Indexerstellungszeiten erreicht werden. Aber Elasticsearch und Apache Lucene sind in Java geschrieben. Wie soll das funktionieren?

Geben Sie lucene-cuvs und die Zusammenarbeit zwischen Elastic, NVIDIA und SearchScale ein, um es in das Lucene-Ökosystem zu integrieren und die GPU-beschleunigte Vektorsuche in Elasticsearch zu erkunden. In der aktuellen Version von NVIDIA cuVS 25.02 haben wir eine Java-API für cuVS hinzugefügt. Die neue API ist experimentell und wird weiterentwickelt, ist aber derzeit zur Verwendung verfügbar. Es stellt sich möglicherweise die Frage: Sind Funktionsaufrufe von Java zu nativen Funktionen nicht langsam? Nicht mehr! Wir verwenden für die Bindungen das neue Panama FFI (Foreign Function Interface), das für Java-zu-native-Downcalls nur einen minimalen Overhead verursacht.

Wir verwenden Panama FFI bereits seit einiger Zeit in Elasticsearch und Lucene . Es ist fantastisch! Aber ... es gibt immer ein „Aber“, nicht wahr? FFI hat Verfügbarkeitsprobleme bei allen Java-Versionen. Wir haben dies überwunden, indem wir die cuVS-API für Java 21 kompiliert und die Implementierung in einem Multi-Release-JAR für Java 22 gekapselt haben. Dies ermöglicht die Verwendung von cuVS Java direkt in Lucene und Elasticsearch.

Ok, jetzt, da wir die cuVS Java-API haben, was brauchen wir noch?

Eine Geschichte von zwei Algorithmen für die CPU

Elasticsearch unterstützt den HNSW-Algorithmus für die skalierbare ungefähre KNN-Suche. Um jedoch das Beste aus der GPU herauszuholen, verwenden wir einen anderen Algorithmus, CAGRA [CUDA ANN GRAph], der speziell für die hohen Parallelitätsgrade der GPU entwickelt wurde.

Bevor wir uns damit befassen, wie wir Unterstützung für CAGRA hinzufügen möchten, schauen wir uns an, wie Elasticsearch und Lucene über ein „Codec-Format“ auf Indexdaten zugreifen. Dieses besteht aus

1. die Darstellung auf der Festplatte,

2. die Schnittstellen zum Lesen und Schreiben von Daten,

3. und die Mechanismen zum Umgang mit der segmentbasierten Architektur von Lucene.

Wir implementieren ein neues KNN -Vektorformat (k-nearest neighbors), das intern die cuVS Java-API zum Indizieren und Suchen auf der GPU verwendet. Von hier aus „verknüpfen“ wir diesen Codec-Typ über die Zuordnungen von Elasticsearch mit einem Feldtyp im Index. Daher funktionieren Ihre vorhandenen KNN-Abfragen weiterhin, unabhängig davon, ob der zugrunde liegende Index ein CAGRA- oder HNSW-Diagramm verwendet. Natürlich werden dabei viele Details außer Acht gelassen, die wir in einem zukünftigen Blog behandeln möchten. Im Folgenden finden Sie die High-Level-Architektur für eine GPU-beschleunigte Elasticsearch.

Dieses neue Codec-Format ist standardmäßig auf CAGRA eingestellt. Es unterstützt jedoch auch die Konvertierung eines CAGRA-Diagramms in ein HNSW-Diagramm für die Suche auf der CPU.

Indizierung und Suche auf der GPU: Treffen einiger „Kernentscheidungen“

Mit der zustandslosen Architektur für Elasticsearch Serverless, die Indizierung und Suche trennt, gibt es nun eine klare Abgrenzung der Verantwortlichkeiten. Wir wählen das beste Hardwareprofil aus, um jede dieser unabhängigen Aufgaben zu erfüllen.

Wir gehen davon aus, dass Benutzer zwei Hauptbereitstellungsstrategien in Betracht ziehen:

1. Indizierung und Suche auf der GPU: Erstellen Sie während der Indizierung ein CAGRA-Diagramm und verwenden Sie es während der Suche – ideal, wenn eine Suche mit extrem geringer Latenz erforderlich ist.

2. Index auf GPU und Suche auf CPU: Erstellen Sie während der Indizierung ein CAGRA-Diagramm und konvertieren Sie es in ein HNSW-Diagramm. Im Index wird der HNSW-Graph gespeichert, der später auf der CPU zur Suche verwendet werden kann.

Diese Flexibilität ermöglicht verschiedene Bereitstellungsmodelle und bietet einen Kompromiss zwischen Kosten und Leistung. Beispielsweise könnte ein Indexierungsdienst mithilfe der GPU Diagramme effizient und zeitnah erstellen und zusammenführen, während für die Suche eine CPU mit geringerer Leistung verwendet wird.

Hier ist also der Plan für die GPU-beschleunigte Vektorsuche in Elasticsearch

Wir freuen uns darauf, den Benutzern Leistungssteigerungen und Flexibilität bei Bereitstellungsstrategien zu bieten und verschiedene Regler zum Ausgleich von Kosten und Leistung bereitzustellen. Hier ist die NVIDIA GTC 2025-Sitzung, in der diese Arbeit ausführlich vorgestellt wurde.

Wir möchten den Entwicklungsteams von NVIDIA und SearchScale für ihre fantastische Zusammenarbeit danken. In einem kommenden Blog werden wir die Implementierungsdetails und die Leistungsanalyse genauer untersuchen. Halten Sie Ihre Neugierhüte fest 🎩!

Lucene und die Gemeinschaft

Ein Projekt ist nur so stark wie die Gemeinschaft, die es unterstützt. Trotz seiner mehr als 20-jährigen Entwicklungsgeschichte ist das Lucene-Projekt nach wie vor lebendig und floriert dank seiner leidenschaftlichen und aktiven Mitwirkenden.

Im Jahr 2024 verzeichnete das Lucene-Projekt mehr als 2.000 Commits von 98 verschiedenen Mitwirkenden und fast 800 Pull Requests. Die Zahl der Mitwirkenden wächst stetig, neue Committer und PMC-Mitglieder schließen sich dem Projekt an und tragen zu seinem Erfolg bei.

Lucene 10

Im Jahr 2024 erschien die erste größere Version seit fast 3 Jahren – Lucene 10 – mit mehr als 2.000 Commits von 185 verschiedenen Mitwirkenden. Während das Entwicklungsmodell von Lucene es ermöglicht, viele Verbesserungen und Funktionen in kleineren Releases bereitzustellen, bietet ein Major-Release die Möglichkeit, größere Funktionen und Modernisierungen einzuführen. Beispielsweise benötigt Lucene 10 mindestens Java 21. Durch die Erhöhung der minimalen Java-Version wird sichergestellt, dass Lucene weiterhin von den Verbesserungen moderner Java-Versionen profitieren kann.

Der Hauptfokus von Lucene 10 liegt auf der besseren Ausnutzung der Hardware, auf der es läuft. Werfen wir einen kurzen Blick auf einige der wichtigsten Punkte:

• Mehr Suchparallelität – während die Suchausführung bereits segmentübergreifend parallelisiert ist, gehen wir jetzt noch einen Schritt weiter und parallelisieren innerhalb der Segmente. Dadurch wird die Darstellung auf der Festplatte von der Ausführungsleistung entkoppelt, sodass selbst einzelne Segmente von der Anzahl der Kerne auf modernen Systemen profitieren können.

• Verbesserte I/O-Parallelität – das einfache synchrone I/O-Modell, das Lucene verwendet, wurde um eine Vorabrufphase erweitert. Dadurch wird dem Betriebssystem mitgeteilt, dass ein Bereich einer Indexdatei in naher Zukunft benötigt wird, ohne den aufrufenden Thread zu blockieren.

• Bessere CPU- und Speichereffizienz durch Sparse-Indexierung – Lucene 10 führt die Unterstützung für Sparse-Indexierung ein, die in anderen Datenspeichern auch als Primärschlüssel-Indexierung oder Zonenindexierung bezeichnet wird.

Weitere Informationen zu Lucene 10 finden Sie im entsprechenden Artikel zu Lucene 10.

Lucene Forschung und Innovation

Im Jahr 2024 erlebte Lucene einen Aufschwung in Forschung und Innovation, insbesondere in den Bereichen maschinelles Lernen Integration, Vektorsuche und Optimierung für große Datensätze, mit Referenzen aus 10 separaten Forschungsarbeiten und Veröffentlichungen. Zu den wichtigsten Forschungsbereichen und Entwicklungen gehören:

• Vektorsuche und Einbettungsunterstützung – Lucene bietet eine leistungsstarke und skalierbare Lösung für die vektorbasierte Suche und ermöglicht so die semantische Suche in großem Umfang. Durch die Nutzung der robusten Indexierungs- und Suchinfrastruktur von Lucene können Anwender die Vorteile der traditionellen Textsuche mit den fortschrittlichen Möglichkeiten der modernen Vektorsuche kombinieren. Dadurch wird Lucene zu einer umfassenden Lösung für eine breite Palette von Such- und Informationsabrufaufgaben.

• Hybride Suchmodelle – Die Forschung hat sich auch mit hybriden Suchtechniken befasst, bei denen Lucene die traditionelle schlüsselwortbasierte Suche mit der modernen vektorbasierten Suche kombiniert. Durch die Verknüpfung von termbasierten Indizes mit dichten Vektordarstellungen kann Lucene genauere und kontextbezogenere Suchergebnisse liefern und so die Lücke zwischen der Präzision traditioneller Suchmaschinen und der Flexibilität der semantischen Suche schließen.

Die laufenden Forschungsarbeiten im Jahr 2024 demonstrieren die Anpassungsfähigkeit von Lucene an die sich wandelnden Bedürfnisse moderner Suchtechnologien, insbesondere im Kontext von KI, semantischer Suche und Big-Data-Anwendungen. Das Projekt entwickelt sich stetig weiter und ist zu einer leistungsstarken, flexiblen und effizienten Plattform für sowohl traditionelle als auch innovative Suchanwendungen geworden.

Lucene-Veröffentlichungen 2024

Auch wenn es kein exaktes Abbild darstellt, unterstreicht die schiere Anzahl der Veröffentlichungen doch das anhaltende Engagement und die Energie der Community. Diese Aktualisierungen beinhalten wesentliche Verbesserungen der Vektorsuchleistung und -effizienz, Unterstützung für madvise, Optimierungen für die Dekodierung von Postinglisten, weitere Geschwindigkeitsverbesserungen durch SIMD und vieles mehr.

Hier ist die vollständige Liste der Veröffentlichungen:

• 10.1.0 (2024-12-20)

• 9.12.1 (13.12.2024)

• 10.0.0 (14.10.2024)

• 9.12.0 (2024-09-28)

• 8.11.4 (2024-09-24)

• 9.11.1 (2024-06-27)

• 9.11.0 (2024-06-06)

• 9.10.0 (2024-02-20)

• 8.11.3 (2024-02-08)

• 9.9.2 (2024-01-29)

Weitere Informationen und Versionshinweise finden Sie auf der Lucene Core- Seite. Zusätzlich gibt es entsprechende PyLucene- Versionen.

Zusammenfassung

Mit zunehmender Reife floriert Lucene dank seiner engagierten und dynamischen Community weiterhin. Wie wir gesehen haben, war 2024 ein unglaublich produktives Jahr, und wir freuen uns nun auf die spannenden Entwicklungen, die 2025 bringen wird.