Auswahl der Queue-Technologie mit Postgres

• Warum Postgres-Queues gut sind, aber nicht zum Mainstream gehören: wegen der verbreiteten Annahme, dass andere Queue-Technologien eine größere Skalierbarkeit bieten
• Unternehmen wie webapp.io haben sich für Postgres-Queues entschieden, weil sie betriebliche Einfachheit, Wartbarkeit und Vertrautheit höher gewichten als Skalierbarkeit
• Bestandteile der Postgres-Queue-Technologie
  • Benachrichtigen und Empfangen neuer Jobs (pub/sub) sowie gegenseitiger Ausschluss (row locks)
  • Diese beiden Funktionen sind seit Postgres 9.5 verfügbar, das 2016 veröffentlicht wurde
• Der Autor widerspricht der in der Branche verbreiteten Ansicht, die Nutzung von Postgres auf diese Weise sei ein „Hack“, und argumentiert, dass Postgres keine zweitklassige Queue-Technologie ist
• Für Queue-Tools zur Verarbeitung lang laufender Jobs wurden bislang Redis, Apache Kafka, RabbitMQ und Amazon SQS gewählt
• Kritik an der Besessenheit der Tech-Branche von „Scale“ und daran, dafür Einfachheit, Wartungsfreundlichkeit und eine geringere kognitive Last für Entwickler zu opfern
• Der Autor schlägt vor, bei technischen Entscheidungen auch Technologien zu berücksichtigen, die man bereits nutzt und gut versteht
• Empfohlen wird die Wahl bereits eingesetzter und gut verstandener „langweiliger Technologie“
• Einführung des Konzepts, sich einen „Ausweg offen zu halten“: Der Anwendungscode zur Job-Verarbeitung sollte von der Queue unabhängig sein
• Abschließend ermutigt der Autor andere, Postgres-Queue-Technologie in Betracht zu ziehen und „langweilige Technologie“ als Standardwahl zu setzen

[GN⁺]

Hacker-News-Kommentare

• Die Einfachheit, Persistenz und Fehlertoleranz von Kafka werden anerkannt, aber seine verteilte Natur kann für die meisten Anwendungsfälle zusätzliche Komplexität mit sich bringen.
• Eine Postgres-Queue kann eine Redis-Queue ersetzen, aber keine SQS-Queue.
• Postgres wurde nach dem Go-live des Systems für die Verarbeitung von über 400 Millionen Events eingesetzt und verarbeitet etwa 1 Million Events pro Tag.
• Die Verwendung einer normalen Tabelle mit SELECT FOR UPDATE SKIP LOCKED ist ein einfacher Ansatz, der mit allen ORM-/Query-DSL-Frameworks funktioniert.
• Ein wesentlicher Nachteil bei der Nutzung von PostgreSQL als Pub/Sub-Bus mit LISTEN/NOTIFY ist, dass LISTEN eine Session-Funktion ist und daher nicht mit Connection Pooling auf Statement-Ebene kompatibel ist.
• Die Verwendung von Postgres als Application-Queue bietet Vorteile durch Transaktionalität, wovon geplante asynchrone Jobs profitieren.
• Postgres lässt sich für Queues skalieren, aber das Einrichten von SQS oder anderen Queue-Stacks auf AWS, GCP oder Azure ist einfacher und dafür besser geeignet.
• Postgres führte Benchmarks auf einer GitHub-CI-Instanz mit 1200 Jobs/s aus und skalierte mit zusätzlichen Workern auf 5000 Jobs/s.
• Postgres mit Oban aus Elixir wurde für die Verarbeitung von zehntausenden bis hin zu Millionen von Jobs pro Tag eingesetzt, wobei sich die Transaktionssemantik rund um Background-Jobs als nützlich erwiesen hat.
• Eine Implementierung mit 47 Mio. verarbeiteten Jobs hebt die Vorteile von durablem Storage mit Indizes hervor, um aufwendige Muster wie SKIP LOCKED für VACUUM, verzögerte Jobs, Retries, Status-Updates und „at least once“ umzusetzen.