Redis Geo-Commands fuer standortbasierte Abfragen

1. Was Redis Geo-Commands wirklich sind

Die Redis Geo-Commands sind kein eigener Datentyp, sondern eine duenne Befehlsschicht ueber der bereits vorhandenen Sorted-Set-Struktur. Wenn ein Team zum ersten Mal von GEOADD hoert, entsteht oft der Eindruck, Redis fuehre intern eine neue Speicherform fuer Geodaten ein. Tatsaechlich nutzt Redis fuer alle Geo-Commands dieselbe Skip-List-basierte Sorted-Set-Implementierung, die auch fuer Ranglisten oder Zeitreihen zum Einsatz kommt. Der Clou liegt in der Kodierung des Scores, nicht in einer neuen Datenstruktur.

Diese Entscheidung der Redis-Entwickler hat einen praktischen Grund: Wer bereits mit Sorted Sets arbeitet, kennt bereits das Komplexitaetsverhalten, die Persistenzsemantik und die Replikationslogik der Geo-Commands, denn es ist exakt dieselbe wie bei ZADD und ZRANGE. Ein GEOADD-Aufruf ist letztlich ein ZADD-Aufruf mit einem berechneten Score. Diese Transparenz erlaubt es, Geo-Commands ohne separate Lernkurve in bestehende Redis-Architekturen zu integrieren.

In der Praxis werden Geo-Commands vor allem fuer drei Aufgaben eingesetzt: Umkreissuchen wie Filialfinder, Distanzberechnungen zwischen zwei Punkten und das Ranking von Standorten nach Naehe. Alle drei Aufgaben lassen sich mit wenigen Befehlen loesen, ohne dass ein separates Geodaten-System wie PostGIS aufgebaut werden muss. Genau das macht Redis Geo-Commands fuer viele Anwendungsfaelle attraktiv, bei denen Geschwindigkeit wichtiger ist als geodaetische Praezision im Zentimeterbereich.

2. Geohashing intern: Koordinaten als Sorted-Set-Score

Der Kern der Redis Geo-Commands ist ein 52-Bit-Interleaved-Geohash, der aus Laengengrad und Breitengrad berechnet wird. Beide Koordinaten werden zunaechst jeweils auf 26 Bit normiert und dann bitweise ineinander verschachtelt, sodass ein einziger Integer-Wert sowohl die horizontale als auch die vertikale Position kodiert. Dieser 52-Bit-Wert wird als Score im Sorted Set gespeichert, waehrend das Member der Name des Standorts ist, zum Beispiel eine Filial-ID.

Der Grund fuer das Interleaving ist geometrisch: Punkte, die raeumlich nah beieinander liegen, erhalten durch die Verschachtelung auch numerisch aehnliche Geohash-Werte. Das bedeutet, dass ein Bereich auf der Karte einem zusammenhaengenden Wertebereich im Sorted Set entspricht, mit Ausnahme der bekannten Randfaelle an den Grenzen der Geohash-Zellen. Genau diese Eigenschaft nutzen die Redis Geo-Commands aus, um Umkreissuchen effizient auf Bereichsabfragen im Sorted Set zurueckzufuehren, statt jeden Punkt einzeln durchzugehen.

Wichtig fuer das Verstaendnis: Die Praezision des Redis-Geohash liegt bei etwa 0,6 Meter auf der niedrigsten Ebene, was fuer nahezu alle Anwendungsfaelle mehr als ausreicht. Da der Score ein regulaerer Double-Wert im Sorted Set ist, koennen alle Sorted-Set-Befehle wie ZSCORE oder ZRANGEBYSCORE direkt auf Geo-Daten angewendet werden, auch wenn das in der Praxis selten noetig ist, weil die dedizierten Geo-Commands bereits die passende Abstraktion bieten.

# Connect to Redis and inspect the underlying data type
redis-cli> GEOADD stores:berlin 13.404954 52.520008 "store:mitte"
(integer) 1

# The geo index is a plain sorted set under the hood
redis-cli> TYPE stores:berlin
zset

# The raw score is the 52-bit interleaved geohash as a double
redis-cli> ZSCORE stores:berlin "store:mitte"
"3673983950505224"

# Standard sorted set commands still work on geo data
redis-cli> ZCARD stores:berlin
(integer) 1

3. GEOADD in der Praxis: Standorte eintragen

Der Befehl GEOADD nimmt einen Key sowie beliebig viele Tripel aus Laengengrad, Breitengrad und Member-Namen entgegen. Wichtig ist die Reihenfolge: Redis erwartet zuerst die Longitude, dann die Latitude, entgegengesetzt zur in vielen Kartendiensten ueblichen Lat-Lng-Notation. Dieser Reihenfolge-Fehler ist einer der haeufigsten Stolpersteine bei der ersten Nutzung der Redis Geo-Commands und fuehrt zu Standorten, die auf der Karte um mehrere hundert Kilometer verschoben erscheinen.

Seit Redis 6.2 unterstuetzt GEOADD zusaetzliche Optionen wie NX, XX und CH, die aus den regulaeren ZADD-Optionen uebernommen wurden. Mit NX werden nur neue Mitglieder hinzugefuegt, bestehende Standorte bleiben unveraendert. Mit XX werden ausschliesslich vorhandene Mitglieder aktualisiert. Diese Optionen sind besonders wertvoll, wenn ein Batch-Import bestehende Filialdaten nicht versehentlich ueberschreiben soll, waehrend gleichzeitig neue Standorte ergaenzt werden.

# Add multiple store locations in a single GEOADD call
redis-cli> GEOADD stores:berlin \
  13.404954 52.520008 "store:mitte" \
  13.331249 52.506342 "store:tiergarten" \
  13.454972 52.487537 "store:kreuzberg"
(integer) 3

# NX: only add new members, never overwrite existing coordinates
redis-cli> GEOADD stores:berlin NX 13.404954 52.520008 "store:mitte"
(integer) 0

# XX: only update coordinates of members that already exist
redis-cli> GEOADD stores:berlin XX 13.405100 52.520200 "store:mitte"
(integer) 0

4. GEOSEARCH: die moderne Umkreissuche

GEOSEARCH ist seit Redis 6.2 der empfohlene Befehl fuer Umkreissuchen und ersetzt die aelteren, inzwischen als deprecated markierten Befehle GEORADIUS und GEORADIUSBYMEMBER. Der entscheidende Vorteil von GEOSEARCH liegt in der Flexibilitaet der Suchform: Statt ausschliesslich kreisfoermige Radien zu unterstuetzen, erlaubt GEOSEARCH auch rechteckige Suchboxen ueber die BYBOX-Option, was bei kartenbasierten Anwendungen mit sichtbarem Kartenausschnitt oft die natuerlichere Suchform ist.

Der Suchmittelpunkt kann entweder ueber FROMLONLAT als explizite Koordinate oder ueber FROMMEMBER als Referenz auf ein bereits gespeichertes Mitglied angegeben werden. Letzteres ist besonders praktisch fuer Anfragen wie "zeige mir alle Filialen in der Naehe von Filiale X", ohne dass die Koordinaten der Referenzfiliale zuvor separat abgefragt werden muessen. Die Ergebnisse lassen sich mit ASC oder DESC nach Distanz sortieren und ueber COUNT auf eine maximale Anzahl begrenzen, was fuer paginierte Trefferlisten unverzichtbar ist.

# Radius search: find stores within 5 km of a coordinate, sorted by distance
redis-cli> GEOSEARCH stores:berlin FROMLONLAT 13.4050 52.5200 \
  BYRADIUS 5 km ASC WITHCOORD WITHDIST COUNT 10

1) 1) "store:mitte"
   2) "0.0134"
   3) 1) "13.40495389699935150"
      2) "52.52000850996238098"
2) 1) "store:tiergarten"
   2) "4.8213"
   3) 1) "13.33124905824661255"
      2) "52.50634169416604663"

# Box search: rectangular viewport instead of a circular radius
redis-cli> GEOSEARCH stores:berlin FROMLONLAT 13.4050 52.5200 \
  BYBOX 10 10 km ASC WITHDIST

# Search relative to an existing member instead of raw coordinates
redis-cli> GEOSEARCH stores:berlin FROMMEMBER "store:mitte" \
  BYRADIUS 3 km ASC

5. Store-Locator-Beispiel Schritt fuer Schritt

Ein klassischer Anwendungsfall fuer Redis Geo-Commands ist der Store Locator eines Onlineshops, der neben dem reinen E-Commerce auch stationaere Filialen betreibt. Der Ablauf ist immer gleich: Beim Import der Filialdaten werden alle Standorte einmalig per GEOADD in ein Sorted Set geschrieben, meist als Teil eines nightly Batch-Jobs oder direkt beim Anlegen einer neuen Filiale im Backend. Die Nutzer-Anfrage "Filialen in meiner Naehe" liefert dann Browser-Koordinaten, die direkt an GEOSEARCH weitergereicht werden.

Der praktische Charme liegt in der Antwortzeit: Da die Umkreissuche auf dem bereits im Sorted Set indexierten Geohash-Bereich arbeitet, liegt die Latenz selbst bei zehntausenden Filialen im niedrigen Millisekundenbereich. Fuer eine mittelgrosse Handelskette mit einigen hundert bis wenigen tausend Standorten ist eine dedizierte Geodatenbank oft ueberdimensioniert, wenn Redis ohnehin bereits als Cache-Layer im Einsatz ist. Die Geo-Commands lassen sich dann ohne zusaetzliche Infrastruktur direkt integrieren.

Fuer die Anzeige auf der Karte kombiniert man GEOSEARCH typischerweise mit WITHCOORD, um die Koordinaten direkt mitzuliefern, und WITHDIST, um die Entfernung zum Nutzer anzuzeigen. Ergaenzend speichert man in einem separaten Hash pro Filial-ID die Detaildaten wie Oeffnungszeiten und Adresse, sodass das Sorted Set schlank bleibt und ausschliesslich fuer die geografische Suche zustaendig ist. Diese Trennung von Geo-Index und Detaildaten ist ein bewaehrtes Muster fuer produktive Store-Locator-Systeme.

6. GEODIST, GEOPOS und GEOHASH als Werkzeuge

Neben GEOADD und GEOSEARCH bieten die Redis Geo-Commands drei ergaenzende Befehle fuer haeufige Detailaufgaben. GEODIST berechnet die Entfernung zwischen zwei bereits gespeicherten Mitgliedern und akzeptiert eine Einheit als optionalen Parameter, m, km, mi oder ft. Das ist nuetzlich, wenn zwei Filialen direkt verglichen werden sollen, ohne den Umweg ueber eine vollstaendige Umkreissuche zu gehen.

GEOPOS liefert die urspruenglichen Koordinaten eines oder mehrerer Mitglieder zurueck und dekodiert dabei intern den Geohash-Score wieder in Longitude und Latitude. Da bei der Kodierung eine geringe Rundung entsteht, weichen die zurueckgegebenen Koordinaten minimal von den urspruenglich eingegebenen Werten ab, typischerweise im Bereich weniger Zentimeter. GEOHASH schliesslich gibt den Standard-Geohash-String im 11-Zeichen-Format zurueck, wie er auch von externen Diensten wie geohash.org verwendet wird, was den Datenaustausch mit anderen Systemen erleichtert.

# Distance between two members, in kilometers
redis-cli> GEODIST stores:berlin "store:mitte" "store:kreuzberg" km
"6.2871"

# Decode stored geohash scores back into coordinates
redis-cli> GEOPOS stores:berlin "store:mitte" "store:kreuzberg"
1) 1) "13.40495389699935150"
   2) "52.52000850996238098"
2) 1) "13.45497101545333862"
   2) "52.48753627091235755"

# Standard 11-character geohash string for interop with external systems
redis-cli> GEOHASH stores:berlin "store:mitte"
1) "u33dc1v0j00"

7. Performance und Komplexitaet der Geo-Commands

Die Komplexitaet von GEOADD entspricht der von ZADD: O(log N) pro hinzugefuegtem Element, da die zugrunde liegende Skip-List die Einfuegeposition in logarithmischer Zeit findet. GEOSEARCH ist etwas aufwendiger, weil Redis intern mehrere Geohash-Zellen berechnet, die den gesuchten Radius oder die Box abdecken, und dann fuer jede Zelle einen Bereichsscan im Sorted Set durchfuehrt. Die Gesamtkomplexitaet liegt bei O(N plus log(M)), wobei N die Anzahl der zurueckgegebenen Elemente und M die Gesamtzahl der Mitglieder im Set ist.

In der Praxis bleibt diese Komplexitaet fuer typische Store-Locator-Groessen irrelevant, da selbst bei mehreren zehntausend Standorten die Anzahl der tatsaechlich im Suchradius liegenden Treffer meist im zweistelligen Bereich bleibt. Kritischer wird es erst bei sehr grossflaechigen Suchen mit hoher Punktdichte, etwa bei der Suche nach allen Fahrzeugen einer grossen Flotte im Umkreis einer Grossstadt. Fuer solche Faelle empfiehlt sich, den COUNT-Parameter konsequent zu setzen, um die Ergebnismenge und damit die Antwortzeit vorhersagbar zu begrenzen.

8. Grenzen und Fallstricke bei Geo-Commands

Redis Geo-Commands sind kein Ersatz fuer ein vollwertiges GIS-System. Es gibt keine Unterstuetzung fuer Polygone, keine Routenberechnung und keine Beruecksichtigung von Strassennetzen, alle Distanzen sind reine Luftlinienentfernungen nach der Haversine-Formel. Wer echte Fahrzeiten oder komplexe geografische Formen wie Liefergebiete benoetigt, muss auf spezialisierte Systeme wie PostGIS oder externe Routing-APIs zurueckgreifen.

Ein weiterer Fallstrick betrifft den Wertebereich: Redis akzeptiert Koordinaten nur innerhalb von minus 85,05112878 bis 85,05112878 Grad Breite, eine Einschraenkung, die aus der Mercator-Projektion stammt, auf der das interne Geohashing basiert. Standorte nahe den Polen lassen sich damit nicht abbilden, was in der Praxis fuer die allermeisten Anwendungsfaelle jedoch irrelevant ist. Ausserdem gibt es keinen nativen Loeschbefehl fuer einzelne Geo-Mitglieder, stattdessen nutzt man ZREM auf demselben Key, da es sich technisch um ein Sorted Set handelt.

9. Geo-Commands im Vergleich zu Alternativen

Die Entscheidung zwischen Redis Geo-Commands und einer dedizierten Geodatenbank haengt vom Anforderungsprofil ab. Die folgende Gegenueberstellung zeigt die zentralen Unterschiede fuer typische Entscheidungssituationen.

Fuer die meisten Store-Locator- und Naehe-Anwendungsfaelle im E-Commerce reichen Redis Geo-Commands vollstaendig aus und sparen den Betrieb eines zusaetzlichen Systems. Erst wenn Polygone, Routenplanung oder sehr grosse Datenmengen mit komplexen raeumlichen Abfragen gefordert sind, lohnt sich der Umstieg auf ein dediziertes GIS.

10. Zusammenfassung

Die Redis Geo-Commands bauen auf der bewaehrten Sorted-Set-Struktur auf und kodieren Koordinaten als 52-Bit-Interleaved-Geohash im Score. GEOADD fuegt Standorte hinzu, GEOSEARCH ersetzt seit Redis 6.2 die alten GEORADIUS-Befehle und bietet sowohl kreisfoermige als auch rechteckige Suchen. GEODIST, GEOPOS und GEOHASH ergaenzen die Kernfunktionalitaet fuer Distanzberechnung, Koordinatenabfrage und Interop mit externen Systemen.

Fuer Store-Locator-Anwendungen, Naehe-Suchen und einfache raeumliche Rankings sind Geo-Commands eine leichtgewichtige, extrem schnelle Loesung ohne zusaetzliche Infrastruktur. Wer Polygone, Routenberechnung oder geodaetische Praezision im Zentimeterbereich benoetigt, sollte zu einem dedizierten GIS-System wie PostGIS greifen. Die richtige Wahl haengt von der tatsaechlichen Anforderung ab, nicht von der reinen Verfuegbarkeit der Geo-Commands in Redis.

11. FAQ: Redis Geo-Commands fuer standortbasierte Abfragen