Kurzfassung
Für einfache Abfragen (z. B. „nach Name finden“) reicht die Datenbanksuche (LIKE, PostgreSQL FTS). Wenn Sie Volltextsuche, Fuzzy-Match, Filter (Facetten), Relevanz-Sortierung oder Millionen Dokumente brauchen – lohnt sich ein eigener Suchmotor wie Elasticsearch oder OpenSearch. Dafür sind Indexierung und zusätzliche Infrastruktur nötig.
Für wen ist das
- Entwickler von Katalogen, Shops, Panels mit erweiterter Suche
- Architekten von Systemen mit großen durchsuchbaren Datenmengen
- Alle, die eine Alternative zu LIKE / einfachem FTS in der DB suchen
Keyword (SEO)
elasticsearch suche, full-text search, elasticsearch wann einsetzen
Wann reicht die Datenbank?
- Einfache Suche – ein Feld, exakt oder Präfix (z. B.
WHERE name ILIKE 'Jan%') - PostgreSQL FTS – bis einige Hunderttausend Datensätze, sprachliches Stemming, Ranking; ohne Faceting und erweiterte Analytik
- Kleines Volumen – bis ca. 100–500k Dokumente reicht FTS in Postgres oft
Wann Elasticsearch / OpenSearch erwägen?
- Großes Volumen – Millionen Dokumente, schnelle Antworten (< 100 ms)
- Fuzzy-Suche – Tippfehler, „Jan Kowalski“ vs „Kowalski Jan“
- Facetten und Filter – Preis, Kategorie, Datum – ohne Verlangsamung der Abfrage
- Suche über mehrere Felder – Titel, Beschreibung, Tags mit verschiedenen Gewichten
- Highlighting – Ausschnitte in den Ergebnissen
- Aggregationen – Statistiken, „ähnliche“ Empfehlungen, Autocomplete (Vorschläge)
Elasticsearch vs OpenSearch
- Elasticsearch – ausgereiftes Ökosystem, Teil des Elastic Stack (Kibana, Beats). Ab 8.x Lizenz geändert – Bedingungen prüfen.
- OpenSearch – Fork von ES 7.10, Open Source (Apache 2.0), kompatibles API. Oft bei Lizenz-/Kostenbedenken gewählt.
Beide eignen sich für Full-Text-Suche; die Wahl hängt von Lizenz, Hosting (z. B. AWS OpenSearch) und Team-Kenntnissen ab.
Ablauf in Kürze
- Index – Daten werden analysiert (Tokenisierung, Stemming, Synonyme) und in suchoptimierter Struktur gespeichert.
- Abfrage – Nutzer gibt Phrase ein → Analyzer tokenisiert → Abfrage an Index (match, bool, filter) → Ranking → Ergebnisse.
- Synchronisation – Daten aus der Haupt-DB (Postgres, MySQL) müssen in den Index: bei Schreibvorgang (Event, Trigger) oder Batch-Job. Latenz hängt von der Strategie ab (Echtzeit vs periodisch).
Beispiel einfache Abfrage (Elasticsearch)
GET /products/_search
{
"query": {
"bool": {
"must": [
{ "multi_match": { "query": "laptop", "fields": ["name^2", "description"] } }
],
"filter": [
{ "term": { "category": "electronics" } },
{ "range": { "price": { "gte": 1000, "lte": 5000 } } }
]
}
},
"highlight": { "fields": { "name": {}, "description": {} } }
}
Alternativen
- PostgreSQL FTS –
to_tsvector,to_tsquery, GIN-Index; ohne zusätzliche Infrastruktur - Meilisearch, Typesense – leichter, einfache Einrichtung, gute Suchqualität bei mittleren Datenmengen
- Algolia – SaaS, starkes UX (Instant Search), Kosten bei großem Volumen
- CMS-Suche – z. B. Strapi, Contentful – oft ausreichend für Seiteninhalte
Checkliste vor der Einführung
- Anforderungen: Volumen, Fuzzy, Facetten, Sprachen
- Prüfen, ob FTS in der DB nicht reicht
- Wahl des Motors: Elasticsearch / OpenSearch / Meilisearch / SaaS
- Strategie für Indexierung und Sync mit Haupt-DB
- Hosting und Kosten (Self-Hosted vs Managed)
- Backup- und Index-Wiederherstellungsplan
FAQ
Ersetzt Elasticsearch die Datenbank?
Nein. In der Regel bleibt die DB (Postgres, MySQL) die Quelle der Wahrheit; Elasticsearch ist die Suchschicht. Sie replizieren Daten in den Index.
Wie oft den Index aktualisieren?
Situationsabhängig: kritische Daten (Preise, Verfügbarkeit) – bei jeder Änderung (event-getrieben). Weniger kritisch – alle paar Minuten oder Stunden (Batch). Latenz in der UI berücksichtigen („Ergebnisse können bis zu 5 Min. alt sein“).
Meilisearch statt Elasticsearch?
Ja, wenn Sie keine erweiterten Aggregationen und komplexen Mappings brauchen. Meilisearch ist einfacher zu betreiben und zu warten, gute Suchqualität out of the box.