Datenbank: RediSearch 2.0 sucht im Flash-Speicher und weltweit
Die Search Engine für die Redis-Datenbank bietet Geo-Distribution und hat eine neue Indexarchitektur. Außerdem arbeitet sie mit Redis on Flash zusammen.
(Bild: Sergey Nivens/Shutterstock.com)
- Rainald Menge-Sonnentag
Redis Labs hat nach einer fünfmonatigen Previewphase RediSearch 2.0 veröffentlicht. Das Release bringt eine vollständig überarbeitete Architektur mit, die das Erstellen von Sekundärindizes und eine globale Verteilung vereinfacht. Außerdem lässt sie sich mit dem mehrschichtigen Speicherkonzept von Redis on Flash verwenden. Der Blogbeitrag verspricht eine Performancesteigerung um den Faktor 2,4 gegenüber RediSearch 1.x.
Weltweit verteilt
Bisher lag der Index von RediSearch im Keyspace, einem internen Verzeichnis, in dem Redis alle Schlüssel speichert. Das ändert sich in Version 2.0, damit die Suche auch in geografisch verteilten Datenbanken nach dem Prinzip der Active-Active Geo-Distribution funktioniert, die auf Conflict-free Replicated Types (CRDTS) setzt. Letztere vermeidet Konflikte, die durch Änderungen in verteilten Daten auftreten können.
Mit der neuen Architektur verfolgt RediSearch die Änderung der Hashes nach dem Replizieren der Daten, wodurch auch die Indizes der verteilten RediSearch-Instanzen schließlich konsistent sein sollen.
Die Herausnahme des Index aus dem Keyspace bedeutet für Entwickler, dass Aufrufe, die den Index-Key verwenden, nicht mehr funktionieren. Als Ersatz dient der neue Befehl FT._LIST, der alle Indizes der Datenbank auflistet. Außerdem benötigt jeder Index nun ein Präfix beziehungsweise einen Filter, um zu bestimmen, welche Dokumente RediSearch automatisch indizieren soll.
Auf der Suche: kalt, warm, heiß
Neu ist zudem, dass RediSearch sich mit Redis on Flash (RoF) verwenden lässt. Dabei speichert die Datenbank nicht den gesamten Datensatz im DRAM. Dort liegen stattdessen nur die Keys, das zugehörige Redis Dictionary sowie die wichtigsten Daten (Hot Values) im. Die weniger genutzten Datensätze (Warm Values) speichert die Datenbank dagegen auf lokalen SSDs.
(Bild: Redis Labs)
Flexibler Index
Eine wesentliche Architekturänderung betrifft den Index, dessen Schreibvorgang nun über HSET statt wie bisher über FT.ADD erfolgt. Dabei kehrt das System die Reihenfolge des Schreibens in die Datenbank und den Index um. RediSearch verfolgt die Hashes der geschriebenen Daten und schreibt Änderungen synchron in den eigenen Index.
(Bild: Redis Labs)
Durch die Synchronisierung des Index entfällt die Migration der Daten für Redis-Datenbanken. Dadurch soll sich das Suchmodul einfacher und im laufenden Betrieb an vorhandene Instanzen anbinden lassen.
Im Zuge der Umstellung auf die neue Architektur hat Redis Labs alle FT-Befehle auf die jeweilige Pendants in Redis gemapped: FT.ADD auf HSET, FT.DEL auf DEL, FT.GET auf HGETALL und schließlich FT.MGET auf HGETALL. Damit sollen entsprechende 1.x-Anwendungen mit RediSearch 2 ohne Änderungen weiter funktionieren.
Mehre Instanzen für Open Source
Die Open-Source-Variante von RediSearch 2 ist im Gegensatz zu Version 1.x nicht auf einen Shard begrenzt. Der RSCoordinator zum Verwalten einer verteilten Suche ist auf GitHub verfügbar. Das Modul steht unter der Redis Source Available License (RSAL), die Redis Labs im Zuge der Umstellungen der Lizenzpolitik Anfang 2019 eingeführt hatte.
Weitere Details lassen sich dem Redis-Blog und der offiziellen Pressemitteilung entnehmen. Im September 2020 hat Redis Labs einen Blogbeitrag zur Einführung in den Einsatz von RediSearch 2.0 veröffentlicht, und auf GitHub findet sich ein Tutorial.
(rme)