確かに、Postgresのパフォーマンスは大きな問題になりうるね。特にトラフィックが急増したときに、垂直スケーリングが厄介になることもある。Kafkaに使うのは、Kafkaの素晴らしい使い方の一つであるトラフィックバーストへの対処を誤解していることになる。突然、Postgresサーバーが圧倒されちゃって、Kafkaサーバーは問題ないのに。

自分の戦略は、まずPostgresを使うこと。アイデアを形にして、Postgresがボトルネックになったら切り替える。それが多くの場合、ボトルネックにならないんだよね。

誰かが「Postgresを使えばいい」と言ったとき、その人はデータとキューで同じインスタンスを使ってるのかな？

100% Postgresは永続的な置き換えを保証するものではないよ。もっと柔軟性があって、初めから速度も上がるシンプルなスタックの出発点としてよく使われる。Postgresから始めることでボトルネックが見えてきて、そこから最適化できるんだ。Postgresを調整するか、リソースを見直すか、Kafkaに飛び込むことも考えてみて。

これはどんなデータストレージにも当てはまるよ。並行性モデルや前提条件を理解して、ボトルネックがどこで発生するかを知っておく必要がある。リレーショナルデータベースの中でも、かなりの違いがあるからね。

各コンシューマが自分のオフセットを使うだけの話じゃない？キューのテーブルが順番通りか時間でインデックス付けされてれば、コンシューマは小さい/早いキーを提供するだけでオフセットを達成できるんじゃないかな？（何か見落としてる？）

記事は基本的に、大量のスループットが必要ないなら、Kafkaは多分必要ないって言ってるね。（私の解釈では）オフセットも必要ないかもしれないし、マルチスレッドのサポートも必要ないから、複数のスレッドも必要ないってことだと思う。PGがキュー管理にどんなネイティブサポートを持ってるかはわからないけど、基本的に「見たらタスクを殺す」ってのが十分だって前提がある。スクリプトを書くことと実行することのシンプルさは、Kafkaの開発、インフラ、DevOpsコストをはるかに上回るよ。でも、15秒で何かをする必要があるのか、5分でいいのか、1時間でいいのかはビジネスの判断だし、持ってるワークロードの成長パターンを理解することも大事だよね。

APIをPostgresで公開するのは、他の開発者たちが使っているのと同じようにやればいいよ。それで終わり。キューの実装はいくつかあって、目的を達成する確率を上げることができるよ。https://github.com/dhamaniasad/awesome-postgres

ユニークな単調増加オフセット番号 すべての購読者の問題を解決できるユニオンって、ちょっと白鯨的なものじゃない？私の知る限り、Kafkaでも完全に水-tightじゃないよ。

コミット時にだけシーケンスをインクリメントするDEFERRABLE INITIALLY DEFERREDトリガーはどう？

log_counterテーブルがこれを追跡してるよ。シーケンスを使ったナイーブな解決策がうまくいかないのは、君が言った理由そのものだね。

難しい問題だね。DDIAを読むことをおすすめするよ。これについて詳しく書いてあるから。https://www.oreilly.com/library/view/designing-data-intensiv... ラムポートクロックを使えば、分散モノトニック数列を生成できるよ。https://en.wikipedia.org/wiki/Lamport_timestamp ウィキペディアの説明はその本ほど詳しくないけどね。分散システムのパズルがこれで終わるわけじゃないけど、かなり進むことができるよ。ベクトルクロックについても見てみて。https://en.wikipedia.org/wiki/Vector_clock 編集: このスライドを見つけたんだけど、問題解決のための良い入門書になってるよ。70ページ以降の「論理時間」をチェックしてみて。https://ia904606.us.archive.org/32/items/distributed-systems...

僕が関わってるシステムにはこの問題があるんだけど、経験上の短い答えは、スケールが大きくなると、順序の問題を完全には防げなくて、アーキテクチャや問題の枠組みにレジリエンスを組み込む必要があるってこと。整合性を保つためには、遅延を支払うことになることが多いよ。

私は第三の極だね：3. 現在あるものは全部クソで、新しいものも何らかの未知の理由でクソになるだろう。

これがまさにそれだね。自分の対抗馬はElasticsearchの代替品で、PGは逆インデックスを持ってるから。PGの使いやすさや調整のしやすさはESに比べてひどいよ。確かに検索はできるけど、その検索を構築したり維持したりするのには関わりたくないな。

実際、適切に設定されたKafkaクラスターは、最小限のハードウェアでもCPUやディスクのボトルネックに達する前にネットワークリンクを飽和させるよ。

Kafkaが提供するものが必要ないなら、使わない方がいい。 これはまさに著者が言いたいことだね。

その通り。昨日、誰かが自分のノートパソコンでRedpanda（Kafka互換の実装）を使って250kメッセージ/秒ができるって投稿してたよ。https://www.youtube.com/watch?v=7CdM1WcuoLc 288 vCPUの3x c7i.24xlargeでそれ以下のスループットって、信じられないくらい無駄だよ。Postgresで何かできるからって、必ずしもやるべきとは限らない。 > 1. 一方の陣営はバズワードを追いかける。 > 2. もう一方は常識を追いかける。 この場合、「Postgres」はただのバズワードとして使われてるの？ [開示：私はRedpandaで働いています；Kafka互換のサービスを提供しています。]

同じこと考えてた、Kafkaの数が入ってないのは変だね。自分はKafka使ったことないけど、Redisキューを使ってスクリプトで永続性を確保してるから、同じプロダクション環境よりもはるかに高いスループットを出してるよ。Redisのpubsubも同じだけど、あれは普通の非永続pubsubだから、ちょっと優位性があるかもね。

だから、ベンチマークはハードウェアの限界に基づくべきだと思う。例えば、このSSDのIOPSやスループットを最大限に引き出すとか、ネットワークカードをフル活用するとかね。CPUはちょっと難しいけど、何とか示せると思うよ。

96 vCPUのセットアップは、AWSで約2万ドル/月かかるよ、割引前でね。そして、Pub/Subシステムで避けたいのは、単一のインスタンスがすべての読み書きを処理することだよ。AWSでそのくらいの金額なら、かなり大きなKafkaクラスタを運用できるよ。

ちょっと余計なことを言ってるかもしれないけど、私の主な考えはこうだね。「アプリにはたぶんPostgreSQLがもうあるよね。追加のユースケースをカバーするために新しいインフラを設定する必要はないよ。既存のツールを再利用すればいいんだ。」技術的には新しいものでカバーできるユースケースが増えていくけど、実際には既存のインフラで十分対応できることが多いよ。成長が必要だと証明されるまではね。

この人、実際にKafkaのベンチマークを取ったの？ 誰かがこの記事全体を読んでるのか、それとも最初の印象が良くない数字に反応して、ここで見つけた最初の否定的なコメントに飛びついてるだけなの？ Kafkaのベンチマークを取ることが目的じゃないんだよ。著者はPostgresがKafkaより優れているとは言ってない。主張は、PostgresがKafkaの運用の複雑さを避けたいチームにとって、適度なメッセージワークロードを十分に処理できるってことだよ。そう、スループットはそんなに強力なCPUにしては驚くほど低いけど、それがポイントなんだ。今、Postgresが高性能なマシンでどれくらい動くかがわかるよ。Kafkaレベルのスケールが常に必要ってわけじゃない。要するに、Postgresがすでにあるなら実用的な選択肢になりうるってこと。だから、最初の印象が良くない数字で否定するんじゃなくて、TFAの実際の問題に応じて反応してみて。Postgresが「十分良い」とされるラインはどこなのか？ それについて話すのは面白いと思うよ。

900kの書き込み/s（非複製）を、Kafka 0.8の頃にランダムな物理サーバーで古いFusion-ioドライブを使ってやってたのを覚えてるよ（どれくらい前のことかがわかるね :D）。もしすでにpgsqlのセットアップがあって、たまにメッセージが必要なだけなら、pgは十分だよね。でも、96 vCPUのセットアップは異常だよ。

OPがKafkaのパーティションやコンシューマオフセットを真似するのではなく、別のスキーマを実装していたら、違った結果が得られたかもしれないね。もしかしたら無知なことを言ってるかもしれないけど、Postgresでpub/subを実装するなら、その強みを活かして、イベントソーシングの基本に戻るのが良いと思う。

pub/subシステムの例を挙げてるんだ。Kafkaに一番詳しいから、それに例を引き合いに出しただけ。実際にはKafkaが提供する全てを実装したわけじゃなくて、シンプルなpub/subのクエリを2つだけやったんだ。

セットアップを少し見直したいんだけど、IoTをやってて、MQTT -> Redpanda（メッセージログやリプレイ用）-> Postgres/Timescaledb（データ用）+ S3（アーカイブ用）って考えてるんだ。そこにFlink/RisingWave/Arroyoを加えて、アラートやインクリメンタル更新のマテリアライズドビューをやるかも。これって「シンプルそう」なんだけど（Redpandaの経験はないけど）、MQTT -> Postgres（キューとして）-> Postgres/Timescaledb + S3に比べると、確かにもう一つ動く部分が増えるよね。質問がいくつかあるんだけど、1. 同じPostgresをキューとビジネスデータベースで使うと、「メッセージ取り込み」の部分が「ビジネス」部分をブロックしちゃうことがあるかな（ロックとか）？データベースのスキーマを更新したいときに、メッセージの流入を「止めたくない」んだけど、これって簡単にできるのかな？2. メッセージをキューに書き込んでから削除するから、ビジネスデータベースに比べてGCやバキュームが多くなるのかな？3. 「Postgresキュー」と「Postgresデータベース」を別のプロセスに分けると、確かに「覚える技術が一つ減る」けど、pgmqに慣れたり統合したりする必要があるよね。それってRedpandaを追加するよりずっと簡単なの？4. 大抵のPostgresキューは「シンプル」で、複数のことに「ファンアウト」を提供してない気がする（例えば、IoTメッセージの一つを取り出して、クリーンアップしてTimescaledbに保存し、S3にもアーカイブして、アラート検出器を動かす、みたいな）。おすすめは何かな？

一つのノードに収まらないなら、本当に分散キューが必要なの？（代替案：昔ながらの負荷分散とREST API、もしかしたら非同期セマンティクスやリトライセマンティクスを使って）それって分散してると思うけど、異なる技術を組み合わせて実現してるだけだよね。異なるDBノードにRESTリクエストを負荷分散するのが、Kafkaよりも簡単なことってあるの？

小規模プロジェクトでよくある問題は、関わっているエンジニアが「このプロジェクトにうまくいくもの」と「次のプロジェクト/仕事にうまくいくもの」を共同で最適化することが多いってことだと思う。特にスタートアップでは、離職率や雇用の安定性が低いから、関わっているエンジニアにとっては最適な行動なんだよね。もし従業員が、現在のプロジェクトをできるだけシンプルで効果的にすることから得られる報酬が一番だと思っていない限り、現在のプロジェクトが本当にシンプルになることはほとんどないと思う。

pgmqみたいなライブラリが作られたらいいな。需要がどれくらいあるかは分からないけど、ニッチな感じがする。