Dieser Inhalt wurde automatisch aus dem Ukrainischen übersetzt.
Stellen Sie sich vor, Sie haben eine Million Dokumente. Sie möchten alle finden, in denen das Wort „Kaffee“ vorkommt, aber nur die, in denen es im Kontext von „Zubereitung“ und nicht von „Laden“ verwendet wird. Und das alles in 50 Millisekunden.
Eine relationale Datenbank wird hier versagen. Sie kann WHERE body LIKE '%Kaffee%' - aber das ist ein vollständiger Brute-Force-Vergleich von Zeichenfolgen, ohne Sprachverständnis, ohne Ranking, ohne Fehlerresistenz. Bei einer Million Datensätze dauert das Sekunden. Bei einer Milliarde - Minuten.
Deshalb gibt es Suchmaschinen - spezialisierte Systeme, die um eine Idee herum aufgebaut sind: die Suche in großen Textmengen schnell, flexibel und intelligent zu gestalten.
Elasticsearch: De-facto-Standard
Elasticsearch ist eine verteilte Suchmaschine und Analyseplattform, die auf Apache Lucene basiert. Lucene ist eine Java-Bibliothek, die seit 1999 existiert und klassische Informationssuchalgorithmen implementiert. Elasticsearch wurde 2010 als benutzerfreundliche HTTP-Hülle über Lucene mit Clusterunterstützung eingeführt.
Wie es im Inneren funktioniert
Im Kern steht das Konzept des invertierten Indexes. Anstatt für jedes Dokument seinen Text zu speichern und danach zu suchen, erstellt das System ein Wörterbuch: „welches Wort - in welchen Dokumenten kommt es vor“. Das ist ähnlich wie ein Stichwortverzeichnis in einem Buch.
"Kaffee" → [doc_3, doc_7, doc_42, doc_100] "Zubereitung" → [doc_7, doc_15, doc_42]
Bei der Anfrage „Zubereitung von Kaffee“ findet das System den Schnitt der Mengen in Millisekunden - unabhängig von der Größe der Sammlung.
Darüber hinaus fügt Elasticsearch hinzu:
- Analyzer - Textverarbeitungs-Pipelines: Tokenisierung, Stoppwortentfernung, Stemming (Reduzierung auf den Stamm), Transliteration.
- Scoring - Der BM25-Algorithmus (früher TF-IDF) weist jedem Ergebnis eine numerische Relevanzbewertung zu.
- Shards und Replikate - Der Index wird in Teile (Shards) unterteilt, die über die Knoten des Clusters verteilt werden. Replikate sorgen für Fehlertoleranz.
- REST API - Alle Interaktionen erfolgen über JSON über HTTP. Keine spezifischen Client-Protokolle.
Was Elasticsearch gut kann
Volltextsuche - das ist offensichtlich. Aber darüber hinaus:
Aggregation - Echtzeitanalytik. „Wie viele Bestellungen gab es in jeder Stadt in den letzten 7 Tagen, auf Stunden aufgeschlüsselt?“ - eine Anfrage, sofortige Antwort.
Geo-Suche - „Finde alle Cafés im Umkreis von 2 km von den Koordinaten“. Elasticsearch unterstützt geospatial Indizes nativ.
Vektor-Suche (kNN) - Ab Version 8.x ermöglicht die Unterstützung von dichten Vektoren die Implementierung von semantischer Suche auf Basis von Embeddings. Das heißt, Dokumente nach Inhalt zu finden, nicht nach exakter Wortübereinstimmung.
Observability-Stack (ELK) - Elasticsearch + Logstash + Kibana. Eine klassische Kombination zur Sammlung und Analyse von Logs. Tausende von Unternehmen setzen es zur Überwachung ihrer Infrastruktur ein.
Die dunkle Seite: Lizenzdrama
Im Jahr 2021 änderte Elastic NV die Lizenz von Elasticsearch und Kibana von Apache 2.0 auf SSPL (Server Side Public License) und Elastic License 2.0. Beide Lizenzen verbieten es, Elasticsearch als Cloud-Service ohne kommerzielle Vereinbarung mit Elastic anzubieten.
Der Grund: Amazon Web Services startete Amazon Elasticsearch Service (später in OpenSearch umbenannt) und verdiente tatsächlich Geld mit fremdem Open-Source-Code, ohne einen Beitrag zurückzuleisten. Elastic beschloss, dieses Schlupfloch zu schließen.
Die Open-Source-Community nahm dies gemischt auf. SSPL wird von den meisten Definitionen von Open Source, einschließlich OSI, abgelehnt. Für viele bedeutete dies: Elasticsearch ist nicht mehr wirklich offen.
OpenSearch: Fork von Amazon
Als Reaktion auf die Lizenzänderung forkte AWS im Jahr 2021 Elasticsearch 7.10 (die letzte Version unter Apache 2.0) und schuf OpenSearch. Gleichzeitig wurde Kibana geforkt → OpenSearch Dashboards.
OpenSearch bleibt unter der Apache License 2.0. Amazon bietet es weiterhin als verwalteten Service an - Amazon OpenSearch Service.
Was unterscheidet OpenSearch von Elasticsearch?
Zum Zeitpunkt des Forks - praktisch nichts. Die APIs waren zu 95 % kompatibel. Mit der Zeit haben sie sich auseinanderentwickelt:
Wann OpenSearch wählen?
- Wenn Sie bereits bei AWS sind und einen verwalteten Service nutzen
- Wenn Lizenzreinheit wichtig ist (Apache 2.0)
- Wenn Sie integrierte Sicherheitsfunktionen kostenlos benötigen
- Wenn Ihr Team nicht von einem kommerziellen Unternehmen abhängig sein möchte
Alternativen: wann Elasticsearch zu viel ist
Elasticsearch ist leistungsstark, aber auch schwer. Ein minimaler Cluster besteht aus mindestens 3 Knoten, mehreren Gigabyte RAM, komplexer Konfiguration. Für kleine und mittlere Projekte ist das oft übertrieben.
Typesense
Typesense ist eine moderne Suchmaschine, die in C++ geschrieben wurde und auf Einfachheit und Geschwindigkeit ausgerichtet ist.
Schlüsselfunktionen:
- Sofortige Einrichtung: eine Binärdatei, Konfiguration mit 5 Zeilen
- Typo-Toleranz out of the box - „Café“ findet „Café“, „café“, „кафэ“
- Vektor-Suche und hybride Suche (Text + Vektoren)
- Integrierte Unterstützung für facettierte Suche
- Lizenz: GPL-3.0 (self-hosted), es gibt einen Cloud-SaaS
Typesense eignet sich hervorragend für die Produktsuche, Artikel, Dokumentation.
Einschränkungen: nicht geeignet für Log-Analytik, keine Aggregationen auf Elasticsearch-Niveau, kleinere Ökosystem.
Meilisearch
Meilisearch ist eine Open-Source (MIT) Suchmaschine in Rust, mit Fokus auf Developer Experience.
# Start in 10 Sekunden
docker run -p 7700:7700 getmeili/meilisearch
curl -X POST 'http://localhost:7700/indexes/movies/documents' \
-d '[{"id": 1, "title": "Star Wars"}]'
Funktionen:
- Extrem einfacher REST API
- Instant Search out of the box
- Filter, Facetten, Sortierung
- Mehrsprachige Unterstützung
- Vektor-Suche (ab Version 1.3)
Einschränkungen: weniger skalierbar als Elasticsearch, nicht geeignet für Petabyte-Daten, eingeschränkte analytische Möglichkeiten.
Solr
Apache Solr ist der „ältere Bruder“ von Elasticsearch. Ebenfalls auf Lucene basierend, erschien es 2004. Lange Zeit war es der Branchenstandard.
Heute hat Solr in Bezug auf API-Benutzerfreundlichkeit, Dokumentation und cloud-native Funktionen gegenüber Elasticsearch nachgelassen. Aber es gibt Nischen, in denen Solr gewinnt: klassischer Unternehmenssuche, sehr komplexe Faceting-Szenarien, Integration mit Hadoop.
PostgreSQL Volltextsuche
Ja, Ihre Lieblingsrelationale Datenbank kann Volltextsuche. Und sie ist nicht schlecht.
SELECT title, ts_rank(search_vector, query) AS rank
FROM articles, to_tsquery('ukrainian', 'suche & motor') query
WHERE search_vector @@ query
ORDER BY rank DESC;
PostgreSQL unterstützt Wörterbücher für verschiedene Sprachen (einschließlich ukrainisch über uk_hunspell), GIN/GiST-Indizes für schnelle Suchen und Ranking nach Relevanz.
Wann ist das ausreichend: bis zu mehreren Millionen Dokumenten, wenn keine Typo-Toleranz und komplexe Aggregationen benötigt werden, wenn Sie die Infrastruktur minimieren möchten.
Wann ist es nicht ausreichend: große Volumina, fuzzy search benötigt, Synonyme, komplexes Ranking, Echtzeitanalytik.
SQLite FTS5
Für ganz kleine Projekte oder mobile Anwendungen - FTS5 Modul von SQLite. Volltextsuche ohne externe Abhängigkeiten.
Qdrant, Weaviate, Pinecone - Vektordatenbanken
Dies ist eine eigene Klasse von Systemen, die mit der Entwicklung von LLM an Popularität gewinnen. Anstelle der Suche nach Schlüsselwörtern - Suche nach semantischer Ähnlichkeit über Vektoren (Embeddings).
- Qdrant (Rust, MIT) - schnell, produktionsbereit, self-hosted oder cloudbasiert.
- Weaviate (Go, BSD-3) - hybrider Suchansatz + integrierte Integration mit OpenAI/Cohere.
- Pinecone - cloudbasierter SaaS, am einfachsten einzurichten.
Diese Systeme ersetzen Elasticsearch nicht - sie ergänzen es. Ein hybrider Ansatz (BM25 + Vektor-Suche) liefert oft die besten Ergebnisse.
Vergleichstabelle
Wählen Sie Elasticsearch, wenn:
- Log-Analytik benötigt wird (ELK-Stack)
- Skalierung - Dutzende Millionen Dokumente und mehr
- Komplexe Aggregationen und Kibana-Dashboards benötigt werden
- Das Team bereit ist, Zeit in die Konfiguration zu investieren
Wählen Sie OpenSearch, wenn:
- Sie bei AWS sind oder die Apache 2.0-Lizenz wichtig ist
- Sie die gleiche Funktionalität wie Elasticsearch benötigen
Wählen Sie Typesense oder Meilisearch, wenn:
- Startup oder mittleres Projekt
- Priorität - schneller Start und Developer Experience
- Typo-Toleranz ohne feine Konfiguration benötigt wird
Bleiben Sie bei PostgreSQL FTS, wenn:
- Weniger als eine Million Dokumente
- Keine zusätzliche Infrastruktur wünschen
- Die grundlegende Suchqualität ausreichend ist
Reale Anwendungsfälle aus der Praxis
GitHub verwendet Elasticsearch für die Code- und Repository-Suche - Milliarden von Dokumenten, Subsekundenantwort.
Wikipedia - Elasticsearch für die Artikelsuche. Etwa 60 Millionen Seiten, 300+ Sprachen.
Netflix - ELK-Stack zur Log-Analyse. Petabytes an Daten.
Shopify - Elasticsearch für die Produktsuche in Millionen von Geschäften.
Gleichzeitig gedeihen Tausende kleinerer Produkte hervorragend auf Meilisearch oder Typesense - und benötigen nicht die Komplexität von Elasticsearch.
Elasticsearch ist das Photoshop unter den Suchmaschinen: äußerst leistungsstark, aber mit einer steilen Lernkurve und ernsthaften Systemanforderungen. OpenSearch ist sein lizenzreiniger Zwilling.
Aber die Jahre 2024–2026 zeigen: Der Wettbewerb ist lebendig. Typesense und Meilisearch gewinnen Publikum im mittleren Segment. Vektordatenbanken eröffnen eine neue Dimension der semantischen Suche. PostgreSQL mit pgvector schleicht sich leise von unten heran.
Die richtige Wahl ist nicht „die leistungsstärkste Lösung“, sondern „die einfachste Lösung, die Ihr Problem löst“. Manchmal ist das Elasticsearch. Manchmal ist es LIKE '%suche%' in PostgreSQL.
Das Wichtigste ist, zu verstehen, was Sie bauen, und nicht mit Kanonen auf Spatzen zu schießen.
Gefällt dir?Reagieren
🧵
Dieser Beitrag hat noch keine Ergänzungen vom Autor.
