Vielleicht brauchen Sie kein Redis

 (viblo.se)
9 Punkte von GN⁺ 2025-03-10 | 5 Kommentare | Auf WhatsApp teilen
  • Redis gehört zu den Technologien mit dem positivsten Ruf in der Tech-Branche
    • Es ist eine hervorragend entwickelte, ausgezeichnete Technologie und hat an sich keine Mängel, aber nicht immer notwendig
  • Über 10+ Jahre hinweg wurde in drei Unternehmen dasselbe Muster beobachtet:
    • Es trat ein Problem auf und Redis schien passend, verbesserte die Situation in der Praxis jedoch nicht oder löste das grundlegende Problem nicht
    • Es war einfach nur mehr Komplexität um der Komplexität willen

Erster Fall: Erfahrungen bei Tantan

  • Tantan ist die zweitgrößte Dating-App in China und betreibt 50 bis 100 leistungsstarke Datenbankserver auf PostgreSQL-Basis
  • Jeder Server ist nach Benutzer-ID geshardet, sodass die Daten eines bestimmten Nutzers nur auf einem einzigen Server gespeichert werden
  • Problemsituation
    • Es entstand die Anforderung, die Anzahl der „Swipes“ zu speichern und schnell zu aktualisieren
    • Anfangs wurde angenommen, dass eine Speicherung in Redis passend wäre
    • Man ging davon aus, dass einige wenige leistungsstarke Redis-Server ausreichen würden, und begann mit der Konfiguration
  • Neubewertung und Lösung
    • Im Team wurde diskutiert, die Daten statt in Redis direkt in PostgreSQL zu speichern
    • Da die PostgreSQL-Server bereits stark ausgelastet waren, wurde erwartet, dass die zusätzliche Last nur geringfügig sein würde
    • Auch nach der Speicherung in PostgreSQL gab es keinen Leistungsabfall, und die Einführung von Redis war unnötig

Zweiter Fall: Erfahrungen bei Bannerflow

  • Hintergrund
    • Bannerflow ist eine Plattform zur Erstellung und Veröffentlichung von Werbung
    • Für einen neuen Microservice wurde die Einführung von Redis beschlossen, um das Veröffentlichen von Werbung in sozialen Netzwerken wie Facebook zu unterstützen
  • Problemsituation
    • Angesichts einer im Vergleich zu Tantan deutlich geringeren Last war unklar, ob die Einführung von Redis überhaupt notwendig war
    • Nachdem der ursprüngliche Entwickler das Unternehmen verlassen hatte, konnte niemand mehr klar erklären, warum Redis eingeführt worden war
  • Ergebnis
    • Redis war bei der geringen Last nicht wirklich nötig
    • Langfristig kam man zu dem Schluss, dass es am besten wäre, Redis zu entfernen

Dritter Fall: Erfahrungen bei MAJORITY

  • Hintergrund
    • MAJORITY ist ein Fintech-Unternehmen und führte Redis ein, um die Ergebnisse externer API-Aufrufe zu cachen
    • Redis wurde eingeführt, um Standortabfragedaten zu cachen, die Verarbeitung zu beschleunigen und Kosten zu senken
  • Problemsituation
    • Dieselben Daten wurden auch in der DB (Azure SQL) gespeichert
    • Es wurde erwartet, dass selbst ein Ersatz der Redis-Aufrufe durch DB-Aufrufe die Last kaum erhöhen würde
    • Man wollte Redis wegen des erforderlichen Locking zunächst weiterverwenden, doch Azure SQL konnte dies ausreichend übernehmen
  • Ergebnis
    • Man kam zu dem Schluss, dass die Einführung von Redis unnötig war
    • Es wurde ein Plan erstellt, von Redis auf Azure SQL umzusteigen

Fazit

  • Alle drei Fälle traten in unterschiedlichen Domänen, Technologie-Stacks und Lastbedingungen auf
  • Die Gemeinsamkeit war jeweils die unnötige Einführung von Redis
  • Vor der Einführung von Redis sollten der tatsächliche Bedarf und die Performance-Vorteile sorgfältig geprüft werden
  • Empfehlung für Dan McKinleys Vortrag „Choose Boring Technology“

Verwandte Beiträge

5 Kommentare

 
iolothebard 2025-03-10

Unabhängig davon, ob man Redis verwendet oder nicht, ist es überhaupt kein Overengineering, zwischen Domain und Persistenz eine Caching-Schicht einzuziehen, deren Standardimplementierung ein Bypass ist. Logging, Fake-Daten, Debugging, Profiling, vielleicht sogar echtes Caching…
 
nodelay 2025-03-10

+1 Ich stimme auch zu. Schon das Hinzufügen einer weiteren Schicht schafft Spielraum und eröffnet Raum, um unzählige Dinge zu lösen.
 
galadbran 2025-03-10

Es scheint weniger darum zu gehen, dass es ein Problem mit Redis gibt, sondern vielmehr um die Perspektive: Wenn die Datenbank allein ausreicht, warum sollte man dann zusätzliche Komponenten einführen und damit den Verwaltungsaufwand erhöhen?
Es wird eher recht knapp erklärt, daher sollte man es wohl in dem Sinne aufnehmen, dass auch diese Sichtweise bedenkenswert ist.
Es kann schließlich auch Situationen geben, in denen es die bessere Wahl ist, bei einfacher Application-Logik einen Redis-Cache einzuführen.
Letztlich sollte man also je nach Situation entscheiden.
 
zinisuni 2025-03-24

Der Titel war wohl Clickbait. :) Stimme zu~~
 
GN⁺ 2025-03-10
Hacker-News-Kommentare

  • Als ich 2015 bei Uber arbeitete, wollten wir die geografische Aufteilung auf Basis von Postleitzahlen auf ein hexagonbasiertes Verfahren umstellen

    • Anstatt eine Stadt in einige Dutzend Postleitzahlen aufzuteilen, wurde sie in mehrere hunderttausend Hexagone unterteilt, wobei Bereiche dynamisch erzeugt wurden
    • Der erste Launch fand in Phoenix statt, und das Team arbeitete die ganze Nacht durch, um das System für die Surge-Pricing-Skalierung auszubauen
    • Der globale Rollout verzögerte sich
    • Es gab viele Engineers, die Redis mochten
    • Der Pricing-Service basierte auf Redis und verarbeitete Millionen von Requests
    • Das war teuer und brachte auch Skalierungsprobleme mit sich
    • Durch Verbesserungen am Algorithmus konnten dynamische Bereiche für mehrere Städte auf einer einzigen Maschine berechnet werden
    • Ein Engineer namens Isaac implementierte und deployte das an einem Wochenende

  • Es gab eine Debatte über den übermäßigen Einsatz von Redis

    • Redis ist großartig, aber bei der Nutzung entstehen Netzwerklatenz und Serialisierungs-Overhead
    • Wenn die Daten bereits partitioniert sind, kann eine gewöhnliche Hash-Map besser sein
    • In Java gibt es ConcurrentHashMap, Guava Caches und Caffeine Caches
    • Eine lokale Cache-Implementierung ist fast immer schneller als die Nutzung des Netzwerks
    • Redis wird tendenziell übermäßig oft verwendet

  • Die Nutzungskultur rund um Redis hat sich nicht im gleichen Maß entwickelt wie seine Popularität

    • Redis unterstützt verschiedene Datenstrukturen, und je weiter sich die Unternehmenskultur entwickelt, desto mehr Patterns kann man lernen
    • Schade ist, dass es kein Pattern-Compendium für Redis gibt

  • Es geht nicht um Redis gegen Nicht-Redis, sondern um das Problem, mit Daten zu arbeiten, die sich nicht gut serialisieren lassen

    • Für Counter, Newsfeeds und Chat-Nachrichten kann Redis effizienter sein
    • In den meisten Fällen reicht aber auch MySQL aus

  • Softwareentwicklung neigt oft dazu, die Vorgehensweisen anderer zu wiederholen

    • Es begann mit Memcached und entwickelte sich dann zu Redis weiter
    • Es gibt die Tendenz, Caches zu verwenden, um die Komplexität von Datenbanken zu vermeiden
    • Datenbanken sind aber nach wie vor komplex und schwierig

  • Redis ist der einzige produktionsreife "Datenstruktur-Server"

    • Es ist nützlich, wenn mehrere Instanzen auf denselben Service zugreifen

  • Möglicherweise braucht man gar keinen Cache

    • Es gibt Erfahrungen damit, sich auf Architekturverbesserungen zu konzentrieren, ohne einen Cache einzuführen

  • Die API von Redis ist hervorragend, aber es gibt operative Risiken

    • Als Cache ist es gut, aber als Datenspeicher für Produktionsdaten nicht zuverlässig

  • Es ist überraschend, dass es eine Tendenz gibt, von Redis abzuraten

    • Redis bietet nach wie vor hervorragende Datenstrukturen und Performance

  • Redis ist als temporärer Cache in Ordnung, reicht aber für Transaktionen oder verteilte Datenspeicherung nicht aus

    • Man muss etwas über Probleme mit verteilten Sperren lernen