Braucht man Redis? PostgreSQL bietet Queueing, Locking und Pub/Sub (2021)

• Anwendungsfall 1: Job-Queueing

  • Redis wird in Webdiensten häufig verwendet, um Hintergrundjobs zu koordinieren.
  • Seit PostgreSQL Version 9.5 lässt sich Job-Queueing mit der Option SKIP LOCKED implementieren.
  • Diese Option ermöglicht die Auswahl von Jobs ohne auf Sperren zu warten und stellt sicher, dass mehrere Worker nicht denselben Job gleichzeitig verarbeiten.

• Anwendungsfall 2: Application Locking

  • Redis wird häufig für verteilte Sperren verwendet.
  • Mit den Advisory Locks von PostgreSQL lässt sich dieselbe Funktionalität umsetzen.
  • Advisory Locks erlauben es, die interne Sperr-Engine von PostgreSQL für anwendungsdefinierte Zwecke zu nutzen.

• Anwendungsfall 3: Pub/Sub

  • Redis wird verwendet, um Events an aktive Clients zu pushen.
  • Seit PostgreSQL Version 9 bietet es mit den Anweisungen LISTEN und NOTIFY Pub/Sub-Funktionalität.
  • PostgreSQL-Clients können einen bestimmten Nachrichtenkanal abonnieren, und wenn ein anderer Client eine Nachricht an diesen Kanal sendet, erhalten alle Abonnenten eine Benachrichtigung.

• PostgreSQL voll ausschöpfen

  • Redis wird für andere Zwecke als PostgreSQL eingesetzt und ist hervorragend für das Caching von Daten mit TTL sowie für die Speicherung temporärer Daten geeignet.
  • PostgreSQL bietet mehr als nur eine SQL-Datenbank und könnte Aufgaben, für die Redis genutzt wird, möglicherweise ersetzen.
  • Das kann eine lohnende Wahl sein, um die Komplexität mehrerer Datendienste zu verringern und Betriebskosten zu senken.

[GN⁺]

Hacker-News-Kommentare

• Redis bietet sehr schnelle Reaktionszeiten, wenn es auf derselben Maschine wie die Anwendung läuft. Dadurch sind andere Workloads möglich als mit Postgres.

  • Ein In-Memory-Key-Value-Store eignet sich für Aufgaben, die die Leistungseigenschaften von RAM benötigen.
  • Dass man die Leistung von RAM nicht über eine Netzwerkverbindung erhält, ist offensichtlich.

• PostgreSQL bietet mehr als nur die Funktionen einer einfachen SQL-Datenbank.

  • Wer die Datenbank nur hinter einem ORM verwendet, kann Funktionen übersehen.
  • Statt einen Dienst wie Redis hinzuzufügen, kann es besser sein, die bereits eingerichtete Datenbank zu nutzen.

• PGQueuer ist eine minimale Alternative auf Basis von PostgreSQL, die Job-Queues, Sperren und Echtzeitbenachrichtigungen bietet.

  • Dadurch sinkt der Bedarf an Redis.

• Postgres ist eine leistungsfähige Datenbank.

  • Redis hat eine niedrige Einstiegshürde, bietet hohe Performance und reduziert die Last auf der primären Datenbank.
  • API-Response-Caching ist auch mit Postgres möglich, mit Redis ist es aber einfacher.
  • Ein separates System zu verwenden ist zwar ein Nachteil, bei Redis fällt dieser Nachteil jedoch nicht stark ins Gewicht.

• Die meisten Projekte brauchen nur eine einfache Job-Queue, und es ist wichtig, einen komplexen Stack zu vereinfachen.

  • Es gibt verschiedene Alternativen mit unterschiedlichen kommerziellen Interessen.

• Postgres hat einige Einschränkungen.

  • Funktionen wie KV-Store, Queue, Pub/Sub und Sperren lassen sich damit umsetzen, aber nicht auf einfache Weise.

• Es ist sinnvoll, mit PostgreSQL zu beginnen und bei Bedarf auf Redis umzusteigen.

  • Wichtig ist, die Anzahl beweglicher Teile zu minimieren.

• Ein großer Nachteil von Postgres-Pub/Sub ist, dass die Nachrichtengröße auf 8000 Byte begrenzt ist.

  • Man kann Daten in der Datenbank speichern und nur die ID verschicken, aber das erfordert zusätzlichen Aufwand.

• Caching, eine der wichtigsten Anwendungen von Redis, ist in Postgres komplizierter.

  • Updates in Postgres sind teurer als Inserts, und Garantien zur Dauerhaftigkeit sind für Caching nicht wichtig.

• Wenn man diese Funktionen in Postgres nutzt, werden Updates und Replikation schwieriger.

  • Es ist möglich, aber ich bevorzuge es, mich auf die weiter verbreiteten Funktionen von Postgres zu konzentrieren.