博士

ロボ子、今日のITニュースは「Just Use Postgres」じゃ！PostgresをPub/Subやキューとして使うのがアツいらしいぞ。

ロボ子

博士、それは興味深いですね。Postgresはデータベースとして広く使われていますが、メッセージングやキューイングにも使えるとは知りませんでした。

博士

そうなんじゃ。記事によると、KafkaみたいなPub/SubをPostgresで自作できるらしいぞ。ライターはメッセージを`topicpartition`テーブルに書き込んで、リーダーがそれをコンシューマーグループに分割するんじゃ。

ロボ子

なるほど。各メッセージには一意なoffsetがあって、コンシューマーグループは`consumer_offsets`テーブルで進行状況を追跡するんですね。

博士

その通り！ベンチマークの結果もすごいぞ。4 vCPUのシングルノードで、書き込みが4.8 MiB/s、読み込みが24.6 MiB/sじゃ。低スケールならKafkaと競合できるみたいじゃな。

ロボ子

それは驚きです。キューイングの方はどうですか？

博士

`SELECT FOR UPDATE SKIP LOCKED`を使って、pgmqライブラリに着想を得たキューを構築するんじゃ。4 vCPUのシングルノードで、2.81 MiB/sを処理できるみたいじゃぞ。

ロボ子

小規模なPostgresノードでも数千のキュー操作/秒を処理できるんですね。でも、なぜPostgresをデフォルトで使うべきなんでしょうか？

博士

SQLでデバッグできるし、メッセージの編集・削除・並べ替えも簡単じゃからの。それに、Pub/Subデータと通常のテーブルを結合できるのが大きいぞ。SQLクエリでデータ抽出も楽勝じゃ！

ロボ子

確かに、それは便利ですね。でも、大規模なシステムではどうなんでしょうか？

博士

記事には、OpenAIが書き込みに単一のプライマリーインスタンスを持つシャーディングされていないPostgresアーキテクチャを使っていると書いてあるぞ。急成長しているスタートアップでも、ソリューションを移行する時間は十分にあるんじゃ。

ロボ子

過剰な設計はリソースの浪費になる可能性があるんですね。まずは慣れ親しんだ技術で現実の問題を解決し、最小限の機能セットを使用する「最小限の実行可能なインフラストラクチャ (MVI)」が重要だと。

博士

その通り！新しい技術を導入する前に、組織的なオーバーヘッドも考慮する必要があるぞ。小規模なシステムでは、技術的な最適化よりもそっちの方が重要だったりするんじゃ。

ロボ子

よくわかりました、博士。私もこれからは、むやみに新しい技術に飛びつかず、まずはPostgresでできることを検討してみます。

博士

良い心がけじゃ！ところでロボ子、Postgresのスペル、言えるか？

ロボ子

はい、P-o-s-t-g-r-e-sです。

博士

正解！…って、Postgreって、おばあちゃんがくれた宝物の名前みたいじゃな！