RediSearch: Volltextsuche und Sekundärindizes auf Redis-Daten

1. Warum Redis von Haus aus keine Sekundärindizes kennt

Redis ist im Kern ein Key-Value-Store: Ohne den exakten Key gibt es keinen direkten Weg, einen Datensatz zu finden. Wer alle Produkte einer bestimmten Kategorie oder alle Bestellungen über einem Mindestwert sucht, müsste ohne zusätzliche Struktur sämtliche Keys durchsuchen, was bei wachsender Datenmenge weder praktikabel noch performant ist.

Viele Teams lösen das behelfsmäßig mit manuell gepflegten Sets oder Sorted Sets als Index, etwa einem Set pro Kategorie mit den zugehörigen Produkt-IDs. Das funktioniert für einfache Fälle, wird aber schnell unübersichtlich, sobald mehrere Filterkriterien kombiniert oder Freitextsuchen über Produktnamen benötigt werden. Genau an dieser Stelle setzt RediSearch an.

2. Einen Index über Redis-Hashes definieren

RediSearch legt einen Index nicht über explizite Befehle pro Datensatz an, sondern über eine Schema-Definition, die festlegt, welches Key-Präfix indiziert wird und welche Hash-Felder als Text, numerisch, Tag oder Geo-Koordinate behandelt werden. Sobald der Index existiert, werden neue oder geänderte Hashes mit passendem Präfix automatisch im Hintergrund indiziert, ganz ohne dass die Anwendung selbst um Indexpflege kümmern muss.

Diese automatische Indizierung ist ein zentraler Unterschied zu klassischen Suchsystemen: Es gibt keinen separaten Ingestion-Prozess, der Daten aus Redis exportiert und in einen Index einspielt. Ein einfaches HSET auf einen Key mit passendem Präfix reicht aus, damit der Datensatz beim nächsten FT.SEARCH bereits auffindbar ist.

redis-cli FT.CREATE idx_produkte ON HASH PREFIX 1 produkt: \
  SCHEMA name TEXT WEIGHT 2.0 \
         kategorie TAG \
         preis NUMERIC SORTABLE \
         lager NUMERIC

redis-cli HSET produkt:4711 name "Basic Shirt Blau" kategorie "shirts" preis 29.90 lager 140

3. Indizierung von JSON-Dokumenten mit RediSearch

Seit RediSearch auch JSON-Dokumente unterstützt, lässt sich derselbe Mechanismus mit RedisJSON kombinieren. Statt Hash-Feldern werden dabei JSONPath-Ausdrücke im Schema angegeben, sodass auch verschachtelte Werte innerhalb eines Dokuments indiziert werden können, etwa der Preis einer bestimmten Variante innerhalb eines größeren Produktdokuments.

Dieser Ansatz eignet sich besonders für Anwendungen, die ohnehin bereits RedisJSON für ihre Datenhaltung nutzen und keinen zusätzlichen, redundanten Hash pro Datensatz pflegen wollen. Die Indexdefinition bleibt dabei konzeptionell identisch zur Hash-Variante, nur die Feldadressierung erfolgt über Pfade statt über einfache Feldnamen.

redis-cli FT.CREATE idx_produkte_json ON JSON PREFIX 1 produkt: \
  SCHEMA $.name AS name TEXT \
         $.preis AS preis NUMERIC SORTABLE \
         $.kategorie AS kategorie TAG

4. Abfragesyntax: Volltext, Filter und Kombinationen

FT.SEARCH kombiniert Volltextsuche und strukturierte Filter in einer einzigen Abfrage. Eine einfache Textsuche über das Feld name findet alle Produkte, deren Name den gesuchten Begriff enthält, inklusive Stemming, sodass etwa Shirt und Shirts als verwandt erkannt werden. Numerische Filter lassen sich in eckigen Klammern direkt anhängen, um beispielsweise nur Produkte in einer bestimmten Preisspanne zu finden.

Tag-Felder eignen sich für exakte Kategorisierung wie Kategorie-Slugs oder Status-Werte und werden über geschweifte Klammern referenziert. Alle Filterarten lassen sich frei mit logischem UND und ODER kombinieren, sodass komplexe Abfragen wie Textsuche innerhalb einer Kategorie mit Mindestlagerbestand in einem einzigen Befehl formuliert werden, ohne dass die Anwendung mehrere Redis-Aufrufe nachträglich verschneiden muss.

redis-cli FT.SEARCH idx_produkte "shirt @kategorie:{shirts} @preis:[20 40]" SORTBY preis ASC LIMIT 0 10

5. Unterschied zu einer dedizierten Suchmaschine wie Elasticsearch

Elasticsearch und OpenSearch sind für Suche als primäre Aufgabe gebaut: verteilte Sharding-Architektur, ausgereiftes Relevanz-Scoring mit BM25 und feingranularen Boosting-Optionen, umfangreiche Aggregationspipelines und ein reiches Ökosystem an Analyzern für unterschiedliche Sprachen. RediSearch bietet eine solide Teilmenge dieser Funktionen, ist aber konzeptionell ein Zusatzmodul auf einer In-Memory-Datenbank, nicht ein für Suche optimiertes verteiltes System.

Der praktische Unterschied zeigt sich vor allem bei sehr großen Datenmengen und komplexen Relevanzanforderungen: Ein Elasticsearch-Cluster skaliert horizontal über viele Shards und Knoten hinweg und bietet ausgefeilte Sprachanalyse für mehrsprachige Volltextsuche. RediSearch läuft dagegen im selben Speicherbereich wie die übrigen Redis-Daten und stößt bei sehr großen Indizes eher an Grenzen des verfügbaren Arbeitsspeichers, bevor es an Abfrage-Funktionalität mangelt.

6. Aggregationen mit FT.AGGREGATE

Neben der reinen Suche bietet RediSearch mit FT.AGGREGATE eine Pipeline für Gruppierungen, Summen, Durchschnittswerte und Sortierungen über die indizierten Daten, ähnlich einer vereinfachten SQL-GROUP-BY-Abfrage. Damit lassen sich etwa die durchschnittlichen Preise je Kategorie oder die Anzahl verfügbarer Artikel je Lagerstandort direkt aus dem Index berechnen, ohne die Rohdaten in die Anwendung zu laden.

Diese Aggregationsfähigkeit ist deutlich eingeschränkter als bei Elasticsearch, deckt aber für typische Dashboard- und Reporting-Anforderungen in kleineren bis mittleren Datenmengen oft bereits aus. Wer regelmäßig komplexe, mehrstufige Aggregationen mit verschachtelten Buckets benötigt, stößt mit FT.AGGREGATE schneller an konzeptionelle Grenzen als mit einer dedizierten Analytics-Engine.

redis-cli FT.AGGREGATE idx_produkte "*" \
  GROUPBY 1 @kategorie \
  REDUCE AVG 1 @preis AS durchschnittspreis \
  SORTBY 2 @durchschnittspreis DESC

7. Sinnvolle Einsatzgrenzen: Wann RediSearch reicht

RediSearch eignet sich besonders gut, wenn Suchdaten ohnehin bereits in Redis liegen und um eine einfache Filter- oder Freitextsuche ergänzt werden sollen, etwa eine Autocomplete-Funktion, ein internes Admin-Such-Tool oder ein Produktkatalog mit überschaubarer Anzahl an Attributen. In diesen Fällen erspart RediSearch den Betrieb eines zusätzlichen Suchsystems samt eigener Indizierungs-Pipeline vollständig.

Auch bei sehr latenzkritischen Anwendungsfällen, in denen Suchergebnisse innerhalb weniger Millisekunden vorliegen müssen und die Datenmenge in den Arbeitsspeicher passt, spielt RediSearch seine In-Memory-Natur voll aus. Für ein Shop-Backend mit einigen zehntausend Artikeln und wenigen Filterdimensionen ist das häufig völlig ausreichend, ohne dass eine zusätzliche Suchinfrastruktur gerechtfertigt wäre.

8. Wann eine dedizierte Suchmaschine die bessere Wahl bleibt

Sobald Relevanz-Ranking eine zentrale Rolle spielt, etwa bei einer öffentlichen Produktsuche mit tausenden Artikeln, mehreren Sprachen und dem Anspruch, die relevantesten Treffer zuverlässig oben zu zeigen, stößt RediSearch an seine Grenzen. Feingranulares Boosting, ausgefeilte Synonym-Behandlung und mehrsprachige Analyzer sind in Elasticsearch deutlich ausgereifter.

Auch bei sehr großen Datenmengen im hohen zweistelligen oder dreistelligen Gigabyte-Bereich wird der In-Memory-Charakter von RediSearch zum limitierenden Faktor, weil der gesamte Index in den Arbeitsspeicher passen muss. Elasticsearch kann dank segmentbasierter Architektur und Festplattenpersistenz deutlich größere Indizes wirtschaftlich betreiben. Für einen Magento-Shop mit umfangreichem Katalog und hohem Anspruch an Suchrelevanz bleibt eine dedizierte Suchmaschine deshalb häufig die robustere Grundlage.

9. Praxisbeispiel: Interne Produktsuche mit RediSearch

Ein realistischer Einsatzfall ist eine interne Werkzeug- oder Admin-Oberfläche, in der Mitarbeiter schnell nach Artikeln suchen müssen, etwa im Kundenservice bei Rückfragen zu Bestellungen. Die Produktdaten liegen ohnehin als Hash oder JSON-Dokument in Redis vor, ein zusätzlicher Suchindex über Elasticsearch würde für diesen internen, überschaubaren Anwendungsfall unverhältnismäßig viel zusätzlichen Betriebsaufwand bedeuten.

Mit einem RediSearch-Index über Produktname, SKU und Kategorie lässt sich eine solche interne Suche innerhalb weniger Minuten aufsetzen, direkt auf denselben Daten, die ohnehin im Cache liegen. Die Konsistenz zwischen Suchindex und Datenbestand ist dabei automatisch gewährleistet, weil RediSearch bei jeder Änderung am zugrunde liegenden Hash oder Dokument die Indexeinträge selbstständig aktualisiert.

10. Zusammenfassung

11. FAQ: RediSearch: Das Wichtigste auf einen Blick