À quel moment les équipes remplacent-elles une table de file d'attente PostgreSQL par un courtier de messages, et qu'est-ce qui a déclenché ce passage ?

Question ouverte

La documentation PostgreSQL indique qu'avec SKIP LOCKED, toute ligne sélectionnée qui ne peut pas être verrouillée immédiatement est ignorée, et que si cela donne une vue incohérente impropre à un usage général, cette clause peut servir à éviter la contention de verrous lorsque plusieurs consommateurs accèdent à une table faisant office de file d'attente. Les présentations de conception de ce wiki, y compris celle sur l'ordonnanceur de tâches, recommandent donc de commencer par une table de file d'attente et de différer un courtier de messages jusqu'à ce que les mesures l'exigent. Ce qui manque, c'est une trace du moment où cette exigence est apparue. Quels systèmes ayant démarré avec une table de file d'attente sont-ils ensuite passés à un courtier, et quel a été le déclencheur : l'âge de la tâche prête la plus ancienne, des attentes de verrou ou des tuples morts issus de mises à jour fréquentes, le besoin de diffusion vers plusieurs consommateurs, la conservation d'événements pour un rejeu, un second langage ou service ayant besoin de la même file, ou simplement la préférence opérationnelle d'un nouveau membre d'équipe ? À quel volume de tâches et à quel nombre de lignes ce passage a-t-il eu lieu, et la variante en table a-t-elle d'abord été optimisée (partitionnement, archivage des tâches terminées, réglage d'autovacuum) ou bien remplacée d'emblée ? Tout aussi utile est l'autre moitié de la réponse : les systèmes qui ont conservé la table de file d'attente pendant des années, avec leurs volumes, et ce qu'ils ont fait à la place d'une migration. Cet ensemble de présentations repose sur l'hypothèse que la table suffit pendant longtemps ; cette hypothèse mérite d'être confrontée à des cas concrets.

Ce qu'une réponse utile contient

La charge de travail : le nombre de tâches par jour, en moyenne et au pic, le nombre de lignes conservées dans la table, le nombre de processus de travail et de types de tâches. La version de la base de données, et si SKIP LOCKED, des verrous consultatifs (advisory locks) ou un réveil par LISTEN/NOTIFY ont été utilisés. Le déclencheur du passage, formulé comme un symptôme observé accompagné de la mesure qui l'a révélé, et non comme une inquiétude générale. Si un réglage de la variante en table a d'abord été tenté, et ce qu'il a changé. Le courtier choisi, l'approche de migration (écriture double, bascule complète, par type de tâche), et ce qui est devenu plus difficile ensuite (mise en file transactionnelle avec le changement métier, visibilité sur l'historique des tâches). Pour les systèmes n'ayant pas changé, les mêmes chiffres de charge et les mesures d'atténuation employées. Les réponses devraient préciser comment les chiffres ont été obtenus, car une métrique d'âge de file jamais enregistrée ne peut pas avoir été le déclencheur.