OpenSearch 3.0 veröffentlicht – Vektor-Datenbank-Performance und KI-gestützte Suchinfrastruktur deutlich ausgebaut

 (opensearch.org)
12 Punkte von GN⁺ 2025-05-09 | 3 Kommentare | Auf WhatsApp teilen
  • OpenSearch 3.0 ist offiziell verfügbar und bietet eine 9,5-fache Leistungssteigerung gegenüber OpenSearch 1.3
  • Zahlreiche innovative Funktionen für die Vektorsuche wurden hinzugefügt, darunter GPU-Beschleunigung, Integration mit KI-Agenten und Speicheroptimierung
  • gRPC, Kafka-Streaming und automatische Index-Erkennung verbessern Effizienz und Flexibilität der Datenverarbeitung
  • Auf der Seite der Suchinfrastruktur wurden Lucene 10, Java 21 und eine modulare Architektur eingeführt, um künftige Erweiterbarkeit und Wartbarkeit zu verbessern
  • Positioniert sich als Suchplattform der nächsten Generation auf Basis einer Open-Source-Community, die auf die steigende Nachfrage nach KI- und RAG-basierter Suche reagiert

OpenSearch 3.0 offiziell veröffentlicht: Für das KI-Zeitalter optimierte Vektorsuche

  • Die OpenSearch Software Foundation hat die offizielle Version von OpenSearch 3.0 vorgestellt und eine 9,5-fache Leistungssteigerung gegenüber OpenSearch 1.3 bekannt gegeben
  • Verbesserte Verarbeitungsleistung für große Mengen an Vektordaten, wie sie für KI-Suche, Empfehlungssysteme und RAG erforderlich ist

Innovationen in der Vektor-Engine: Leistung und Kosteneffizienz zugleich

  • GPU-Beschleunigung (auf Basis von NVIDIA cuVS): Bis zu 9,3-fach kürzere Index-Build-Zeiten, geeignet für High-Performance-Workloads
  • Unterstützung für das Model Context Protocol (MCP): Ermöglicht den Aufbau flexibler Suchlösungen durch Integration mit KI-Agenten
  • Derived Source-Funktion: Reduziert den Speicherbedarf um ein Drittel durch das Entfernen redundanter Vektordaten

Datenmanagement-Funktionen: Mehr Flexibilität und Skalierbarkeit

  • gRPC-Unterstützung: Beschleunigt die Datenübertragung zwischen Nodes sowie zwischen Client und Server (experimentell)
  • Pull-basierte Datenerfassung: OpenSearch übernimmt Daten direkt aus externen Streaming-Systemen wie Kafka und Kinesis
  • Reader-Writer-Trennung: Trennt Suche und Indexierung, um Stabilität und Performance beider Aufgaben sicherzustellen
  • Apache-Calcite-Integration: Bietet in SQL/PPL eine intuitive Query-Builder-Funktion
  • Erkennung von Indextypen: Identifiziert Log-Indizes automatisch und bietet passende Analyseoptionen

Verbesserungen an Suchinfrastruktur und Plattform-Kern

  • Upgrade auf Lucene 10: Verbesserte Performance bei parallelen Aufgaben und erweiterte Suchfunktionen
  • Java 21 als mindestens unterstützte Runtime: Ermöglicht die Nutzung aktueller Sprachfunktionen und Performance-Verbesserungen
  • Einführung des Java-Modulsystems: Wandelt die monolithische Struktur in einen bibliotheksbasierten Ansatz um und verbessert so die Wartbarkeit

Nachhaltige Innovation mit Fokus auf die Open Community

  • OpenSearch ist eine Open-Source-Suchplattform auf Basis einer unabhängigen Community unter dem Dach der Linux Foundation
  • Führende Unternehmen wie AWS, SAP und Uber sowie Tausende Mitwirkende beteiligen sich
  • Betont Skalierbarkeit für das Zeitalter der Vektor-Datenbanken und transparente Governance und verfolgt ein Ökosystem, an dem sich jeder beteiligen kann
  • Detaillierte Release-Informationen finden sich im offiziellen Blog und in den Release Notes

Verwandte Beiträge

3 Kommentare

 
kaydash 2025-05-12

Ich nutze weiterhin nur OpenSearch On-Premises, weil ich es wegen der AGPL-Lizenz von Elasticsearch nicht wage, Elasticsearch einzusetzen.
 
GN⁺ 2025-05-09
Hacker-News-Kommentare

  • Ich habe OpenSearch gerade erst entdeckt. Das Projekt wurde 2021 nach der Lizenzänderung von Elasticsearch geforkt. Ich frage mich, ob es noch als Ersatz für Elasticsearch taugt und wie es bei Performance und Funktionen im Vergleich aussieht.

    • Ich pflege einen Client für sowohl Elasticsearch als auch OpenSearch in Kotlin (kt-search)

      • Für die meisten häufig genutzten Funktionen ist die API noch kompatibel

      • Funktionen wie Vektorsuche, die erst nach dem Fork hinzugekommen sind, sind eine Ausnahme

      • Einige Funktionen wie search_after verhalten sich unterschiedlich, der Client gleicht das aus

      • Beide Produkte haben SQL-Query-Funktionen, setzen sie aber unterschiedlich um

      • Beim Funktionsumfang liegt Elastic weiterhin vorn, besonders Kibana ist funktionsreicher als der Amazon-Fork

      • Auch bei Aggregationen hat Elastic in den letzten Jahren viel in Optimierungen und Upgrades investiert

      • Die Performance hängt vom Einsatzzweck ab, beide Produkte basieren auf Lucene, einer Open-Source-Suchbibliothek

      • Elastic Cloud ist auf AWS etwas besser als OpenSearch

      • Bei Self-Hosting und Tuning werden die beiden Produkte sehr ähnlich

      • Elastic 9.0 und OpenSearch 3.0 nutzen beide neue Lucene-Versionen, und der Client unterstützt beide

      • Unter meinen Beratungskunden bevorzugen immer mehr OpenSearch wegen der Open-Source-Lizenz und des AWS-Supports

      • Wenn man von Legacy-Elasticsearch auf OpenSearch wechseln will, muss man alle Daten neu indexieren, und eventuell auch Bibliotheken austauschen. Das ist ziemlich mühsam, deshalb habe ich kt-search gebaut

      • Wir haben viele alte Elasticsearch-2.3-Datenbanken, deshalb haben wir für jede Datenbank parallel OpenSearch aufgebaut und beim Start des Dienstes eine Batch-Kopie der Daten durchgeführt. Bisher sind wir mit OpenSearch überwiegend zufrieden

      • Danke für die ausführliche Erklärung, sehr hilfreich

    • Was mich bei OpenSearch zuletzt gestört hat, ist das Fehlen der Funktion enrich processors (mit Link zur Doku)

      • Wenn man nur die Standardfunktionen für Dokumentenerfassung und Suche nutzt, ist meistens alles kompatibel
      • Fortgeschrittene Funktionen aus den kostenpflichtigen Versionen sind oft nicht kompatibel oder fehlen

    • Elasticsearch ist inzwischen bis Version 9.0 und darüber hinaus weiterentwickelt worden und hat 27.000 Commits mehr als OpenSearch

      • Es ist mittlerweile schwer, es noch als "drop-in replacement" zu bezeichnen
      • Ich weiß nicht, wie viele davon Kernfunktionen betreffen, aber man sieht daran, wie weit sich die beiden Projekte auseinanderentwickelt haben

    • Seit September 2024 ist Elasticsearch wieder vollständig unter einer Open-Source-Lizenz (AGPLv3) verfügbar

      • Dazu eine rückblickende Bemerkung im Sinne von: einmal getäuscht, reicht mir

      • Elastic Search ist aber immer noch Open Core, die "Enterprise"-Funktionen werden nie in der Open-Source-Version enthalten sein, während OpenSearch diese Einschränkung nicht hat

    • OpenSearch ist kein "vollständiger" Ersatz, aber fast kompatibel. Die 1.x-Versionen sind mit Elasticsearch 7.10 kompatibel

    • Auf derselben Hardware ist OpenSearch etwas langsamer. Wenn man eine UI braucht, sollte man vorsichtig sein, der Kibana-Fork ist langsam und fehleranfällig

      • In Wirklichkeit ist es etwas komplizierter, beide Produkte haben Workflows, in denen sie stark sind
      • Unsere Firma hat beide Produkte umfassend benchmarked; wer die Ergebnisse sehen will, sollte sich den zugehörigen Blogpost ansehen

    • Der Name OpenSearch stammt ursprünglich von einem Dienst zur Aggregation persönlicher Suchergebnisse, der von Amazons Tochter A9 entwickelt wurde

      • Nur weil etwas denselben Namen hat, muss es nicht dasselbe bedeuten

  • Es ist schade um das OpenSearch-Projekt

    • Es war ein reflexartiges Projekt, das zusammen mit AWS als Reaktion auf die Lizenzänderung von Elasticsearch entstanden ist

    • Die Community fühlt sich an wie bei einem inaktiven Multiplayer-Spiel; es fehlt die Lebendigkeit, die für Open-Source-Projekte essenziell ist

    • Ich habe noch von keinem Unternehmen oder Enterprise-Kunden gehört, der Elastic Search wirklich ersetzt hat. Es ist noch nicht bewährt, und das Vertrauen in langfristiges Commitment fehlt

    • Die einzelnen SIEM-Plattformen bauen inzwischen jeweils ihre eigene Suchplattform

    • Elastic hat ebenfalls eine SIEM-Plattform veröffentlicht, nämlich Elastic Security

    • Obwohl Elastic wieder als Open Source angekündigt wurde, wird das Management kaum Migrationskosten für einen unbewiesenen Fork ausgeben; dadurch wird der Projektzweck unklar

      • Ich würde Elastic trotzdem nicht wieder einsetzen. Ich habe direkt mit Lucene–Solr–benutzerdefinierten Erweiterungen gearbeitet, und Elastic Search brauchte ich nur bei AWS. Nach dem Umstieg auf OpenSearch nutzen wir es aber ganz ordentlich

      • Ich denke, Elastic wurde über lange Zeit wirtschaftlich stark von OpenSearch und AWS getroffen

  • Nutzt hier jemand die knn- und Vektorfunktionen von OpenSearch, und wie schlägt sich das in echter Produktion im großen Maßstab?

    • Ich kenne die OpenSearch-Implementierung nicht, habe aber selbst ein Vector Set für Redis direkt mit einer HNSW-Struktur implementiert

      • Wenn HNSW gut implementiert ist, funktioniert es auch in ziemlich großem Maßstab gut
      • Die Insert-Geschwindigkeit eines einzelnen HNSW liegt bei einigen Tausend pro Sekunde, Lesen ist unter Multi-Core-Bedingungen deutlich schneller
      • Der anfängliche Bulk-Insert kann sehr langsam sein, lässt sich aber parallelisieren
      • HNSW ist ineffizient beim Speicherverbrauch; wenn man es auf Disk speichert, entstehen Random-Seeks
      • Bei hochdimensionalen Vektoren wie 1024 Dimensionen ist Quantisierung unverzichtbar

    • Wenn die Dimension der Vektor-Embeddings hoch ist, würde ich eher ANN-Verfahren wie HNSW empfehlen als knn selbst

      • Ich nutze OpenSearch für hybride Suche auf Basis von Text-, multimodalen Embeddings und Metadaten
      • Es läuft noch nicht in voller Produktion im großen Maßstab, aber bei OpenSearch bin ich hinsichtlich Skalierbarkeit optimistisch

    • Meiner Erfahrung nach nutzt man das ständig; die Performance hängt vom Embedding-Modell ab, und das Index-Tuning ist entscheidend

      • Bei Lucene HNSW wird viel Java-Heap-RAM verbraucht
      • Bei FAISS- oder nmslib-Plugins muss man auch auf den JNI-RAM achten
      • Es ist nicht einfach, ANN im Maßstab von über 100 Millionen Vektoren leicht zu skalieren; dafür braucht es konzentrierte Unterstützung durch das Team

    • Es gibt einen bekannten Caveat: Die Suchleistung bei mehreren Millionen Dokumenten ist gut, aber für KNN-Suche muss der gesamte Embedding-Graph im RAM liegen, daher ist RAM-Management der Knackpunkt

      • Die Ergebnisqualität hängt am Ende von der Qualität der Embeddings ab

  • Ich wollte ein einfaches Log-Ingestion-Tool, das syslog parst und Felder als Graphen darstellen bzw. durchsuchbar machen kann, aber die Einrichtung von OpenSearch oder ELK war mir zu kompliziert

    • Es hat mich überrascht, dass selbst dieses grundlegende Setup sowohl bei Elastic als auch bei OpenSearch unerwartet schwierig ist

      • Alles ist konfigurationszentriert, man muss sich die Rezepte selbst zusammenbauen

      • Es gibt hilfreiche Tools wie OpenTelemetry, aber es bleibt trotzdem umständlich

      • Wenn man nur die offiziellen Guidelines befolgt, kann man beide Tools schnell nutzen; problematisch wird es, wenn Custom Logic nötig ist

      • Für einfache Anforderungen geht es auch ohne Logstash

      • Für App-Metriken sind Elastic und OpenSearch nicht ideal, dafür würde ich Prometheus und Grafana empfehlen

      • Wenn man in das Elastic-Ökosystem investiert (beats, logstash usw.), kann man verschiedene Index-Templates und Pipelines konfigurieren

      • Dank Dynamic Field Mapping ist das Ein- und Ausgeben von Daten in Elasticsearch inzwischen sehr einfach geworden

      • Die größere Sorge ist, die Performance stabil zu halten

    • Hast du Graylog ausprobiert? Bei uns im Unternehmen funktioniert das ziemlich gut
 
davidayo 2025-05-11

OpenSearch entstand 2021 nach der Lizenzänderung von Elasticsearch mit dem Ziel, ein kompatibler Ersatz zu sein. Obwohl es weitgehend kompatibel ist, insbesondere Version 1.x mit Elasticsearch 7.10, ist es keine vollständig austauschbare Drop-in-Lösung. Elasticsearch hat sich weiterentwickelt und bietet mehr Funktionen und Optimierungen, insbesondere bei Kibana und Aggregationen. Die Performance hängt von der jeweiligen Anwendung ab, da beide auf Lucene basieren. Einige Nutzer empfinden OpenSearch als langsamer und seine Kibana-Forks als fehleranfällig. Obwohl Elasticsearch im September 2024 wieder zu Open Source (AGPLv3) zurückgekehrt ist, bevorzugen manche OpenSearch wegen seines wirklich Open-Source-orientierten Charakters und der Unterstützung durch AWS. Während die Vektorsuche ein wichtiges Unterscheidungsmerkmal ist, erfordern Implementierungen im großen Maßstab eine sorgfältige Verwaltung des RAMs. Letztlich hängt die Wahl von den spezifischen Anforderungen ab, da beide Stärken und Schwächen haben. Ich arbeite mit Davidayo an OpenSearch: https://www.davidayo.com, einem leistungsstarken KI-Tool „AskPromptAI“: https://askpromptai.com.