An welchem Punkt ersetzen Teams eine PostgreSQL-Queue-Tabelle durch einen Message Broker, und was löste den Wechsel aus?

Offene Frage

Die PostgreSQL-Dokumentation hält fest, dass mit SKIP LOCKED alle ausgewählten Zeilen, die nicht sofort gesperrt werden können, übersprungen werden, und dass dies zwar eine inkonsistente, für allgemeine Arbeit ungeeignete Sicht liefert, sich aber nutzen lässt, um Sperrkonkurrenz bei mehreren Konsumenten zu vermeiden, die auf eine warteschlangenartige Tabelle zugreifen. Design-Durchgänge in diesem Wiki, einschliesslich desjenigen zum Job-Scheduler, empfehlen deshalb, zuerst eine Queue-Tabelle einzusetzen und einen Message Broker aufzuschieben, bis Messungen ihn erfordern. Was fehlt, ist eine Aufzeichnung darüber, wann diese Notwendigkeit eintrat. Welche Systeme, die mit einer Queue-Tabelle begannen, wechselten später zu einem Broker, und was war der Auslöser: das Alter des ältesten bereiten Jobs, Sperrwartezeiten oder Dead Tuples durch häufige Updates, der Bedarf an Fan-out zu mehreren Konsumenten, die Aufbewahrung von Ereignissen für Replay, eine zweite Sprache oder ein zweiter Dienst, der dieselbe Warteschlange brauchte, oder schlicht die betriebliche Präferenz eines neuen Teammitglieds? Bei welchem Job-Volumen und welcher Zeilenzahl fand der Wechsel statt, und wurde die Tabellenvariante zuerst optimiert (Partitionierung, Archivierung erledigter Zeilen, Anpassung von Autovacuum) oder direkt ersetzt? Ebenso nützlich ist die andere Hälfte: Systeme, die die Queue-Tabelle über Jahre behielten, mit ihren Volumina, und was sie stattdessen getan haben, statt zu migrieren. Die Gruppe der Durchgänge beruht auf der Annahme, dass die Tabelle lange Zeit ausreicht; diese Annahme sollte an Fällen überprüft werden.

Was eine nützliche Antwort enthält

Die Arbeitslast: Jobs pro Tag, Durchschnitt und Spitze, in der Tabelle gehaltene Zeilenzahl, Anzahl der Worker-Prozesse und Job-Typen. Die Datenbankversion und ob SKIP LOCKED, Advisory Locks oder ein Aufwecken per LISTEN/NOTIFY verwendet wurde. Der Auslöser für den Wechsel, angegeben als beobachtetes Symptom mit der Messung, die es zeigte, nicht als allgemeine Sorge. Ob die Tabellenvariante zuerst optimiert wurde und was sich dadurch änderte. Der gewählte Broker, der Migrationsansatz (Dual-Write, Cut-over, je Job-Typ) und was danach schwieriger wurde (transaktionales Enqueue mit der Geschäftsänderung, Einsicht in die Job-Historie). Für Systeme, die nicht gewechselt haben, dieselben Arbeitslastzahlen und die eingesetzten Massnahmen. Antworten sollten angeben, wie die Zahlen ermittelt wurden, da eine nie erfasste Metrik zum Alter der Warteschlange nicht der Auslöser gewesen sein kann.