Redis lässt sich leicht auf "schnellen Schlüssel-Wert-Cache" reduzieren.
Das übersieht den Teil, der es wertvoll macht: Redis bietet spezialisierte Datenstrukturen mit sehr spezifischen Leistungs- und Speicherkompromissen.
HyperLogLog ist das beste Beispiel
Wenn Sie eine ungefähre Zählung einzigartiger Werte benötigen, könnte eine Menge übertrieben sein.
Eine Redis-Menge bietet Ihnen exakte Einzigartigkeit, aber die Speicherkosten steigen mit der Anzahl der Mitglieder.
HyperLogLog tauscht Exaktheit gegen einen kleinen festen Speicherverbrauch:
PFADD stream:123:views 203.0.113.10
PFADD stream:123:views 203.0.113.11
PFCOUNT stream:123:views
Das macht es zu einer guten Wahl für:
- ungefähre einzigartige Besucher
- ungefähre einzigartige Ereignisse
- Trendmessungen, bei denen ein kleiner Fehler akzeptabel ist
Es ist die falsche Wahl, wenn genaue Zählungen für Abrechnung, Compliance oder Geldbewegungen erforderlich sind.
Deshalb ist ein kleiner Proof of Concept vor der Einführung wichtig. Füttern Sie HyperLogLog mit realistischem Verkehr und vergleichen Sie das ungefähre Ergebnis mit einer exakten Menge auf einem Beispieldatensatz. Der Speichergewinn ist oft hervorragend, aber die akzeptable Fehlerrate sollte im Hinblick auf den tatsächlichen Anwendungsfall überprüft werden, nicht aus einem Blogbeitrag angenommen werden.
Das ist das Muster bei Redis-Datenstrukturen im Allgemeinen: Jede codiert einen nützlichen Kompromiss.
Denken Sie in Problemmustern
Redis wird leistungsfähiger, wenn Sie fragen:
- brauche ich Exaktheit oder Annäherung?
- benötige ich eine Ordnung?
- brauche ich Einzigartigkeit?
- benötige ich ein zeitfensterbezogenes Verhalten?
Das führt natürlich zu sortierten Mengen, Bitmaps, HyperLogLog, Streams und dem Rest des Werkzeugsatzes.
Weiterführende Literatur