Postgresキュー技術の選択

• Postgres Queue は優れているが主流ではない理由: 他のキュー技術のほうがより高いスケーラビリティを提供するという一般的な考えがあるため
• webapp.io のような企業は、運用の単純さ、保守性、そして親しみやすさをスケーラビリティより重視し、Postgres キューを選択した
• Postgres キュー技術の構成要素
  • 新しいジョブを通知して受け取ること（pub/sub）と相互排他（row locks）
  • この2つは 2016 年にリリースされた Postgres 9.5 から提供されている
• Postgres をこのように使うのは「ハック的」だという業界の一般的な考えに反論し、Postgres は取るに足らないキュー技術ではないと主張
• 長時間実行されるジョブを処理するためのキューツールとして、Redis、Apache Kafka、RabbitMQ、Amazon SQS などが選ばれてきた
• 技術業界の「規模」への執着を批判し、単純さ、保守のしやすさ、開発者の認知負荷の低減を犠牲にすることを問題視
• 技術的な意思決定を行う際には、現在使っていて十分に理解している技術を考慮すべきだという著者の提案
• すでに使っていて理解が進んでいる「退屈な技術」を選ぶことを推奨
• 「出口を作りながら進む」という概念を紹介し、ジョブ処理のためのアプリケーションコードはキューに依存しないべきだという意味
• 著者は、Postgres キュー技術を検討し、「退屈な技術」をデフォルトの選択肢にするよう他の人々を後押しする形で締めくくっている

[GN⁺]

Hacker Newsの意見

• Kafkaの簡潔さ、永続性、耐障害性は評価されているが、その分散的な性質はほとんどのユースケースで複雑さを増す可能性がある。
• PostgresキューはRedisキューの代替にはなり得るが、SQSキューの代替にはならない。
• Postgresはシステム稼働後に4億件を超えるイベントを処理し、1日あたり約100万件のイベントを処理するために使われた。
• 通常のテーブルを使い、SELECT FOR UPDATE SKIP LOCKEDを使用するのは、あらゆるORM/Query DSLフレームワークで動作するシンプルなアプローチである。
• LISTEN/NOTIFYを使ってPostgreSQLをpub/subバスとして使う主な欠点は、LISTENがセッション機能であるため、ステートメントレベルのコネクションプーリングと互換性がないことだ。
• Postgresをアプリケーションキューとして使うことにはトランザクション性の利点があり、スケジュールされた非同期ジョブはこの恩恵を受ける。
• Postgresはキュー用途向けにスケールできるが、AWS、GCP、AzureでSQSやその他のキュースタックを設定するほうがより簡単で、目的にも適している。
• PostgresはGitHub CIインスタンスで1200jobs/sのベンチマークを実行し、追加のワーカーによって5000jobs/sまでスケールした。
• ElixirのObanを使ったPostgresは、バックグラウンドジョブ周辺のトランザクションセマンティクスが便利であることが実証されており、毎日数十万から数百万件のジョブを処理するために使われた。
• 4,700万件のジョブが処理された実装は、VACUUMのためのSKIP LOCKED、遅延ジョブ、再試行、状態更新、「少なくとも1回」といったコストの高いパターンを実装するためのインデックス付き永続ストレージの利点を強調している.