とにかく Postgres をあらゆる場所で使おう
(amazingcto.com)- Postgres は、多くのバックエンド技術を（数百万人規模のユーザーまで）置き換え可能
→ Kafka、RabbitMQ、Mongo、Redis など - キャッシュには Redis の代わりに、UNLOGGED テーブルで
TEXTを JSON 形式として使用- ストアドプロシージャでデータの有効期限を設定
- メッセージキュー（Kafka）:
SKIP LOCKED - データウェアハウスは Postgres + TimescaleDB
- Mongo の代わりに JSONB を保存し、検索とインデックス化を行う
pg_cronでメール送信のような CRON デーモンとして使用- 地理空間クエリに使用
- Elastic の代わりに全文検索に使用
- DB 内で JSON を生成し、サーバーサイドコードなしで API に直接渡す
- GraphQL アダプターで GraphQL もサポート
13件のコメント
うーん、各アプリでサポートされるより多くの機能が必要でなければ、基本的なコンセプトとしては Postgres で十分、ということのようですね。
各アプリは、上で置き換えているフローよりも多くの機能を使えますからね。
インターフェースさえしっかり設計して使えば、そこまで突飛な話でもないと思います。ただ、キャッシュやメッセージキューくらいは Redis に任せてもいいと思います。
私も最近、上の記事と同じようなことを考えています。もちろん大規模サービスでは、できるだけ分散してリスクを分散するのが良いですが、小規模な受託開発では別途 NoSQL を使わずに Postgres の
jsonb型を活用したほうが、はるかに使い勝手が良いことがよくありました。RDB + NoSQL を複合的に使うような使い勝手で、小規模プロジェクト内では十分な性能でした。1つですべてをこなすぶん、あらゆるリスクポイントが1か所に集まる…！
代替となる製品がなかった時代には、実際にRDBでやっていたこともありますが、Redis、Kafka、Cronのようなものは、その主な利点を置き換えられていないように見えます。面白半分で眺めて通り過ぎる程度のアイデアだと思います。
何でも1つでこなすのが好きな人には、まさにぴったりですね
私は Geospatial のために postgres を使っていたのですが、
他の DB と比べて 10〜100 倍ほど速かったです。geo 系は圧倒的でした。
ただ、皆さんご存じのとおりデータが増えて vacuum がうまく回らないと地獄を見ます……
おお、いろいろなテクニックがありますね。
ただ、最初の UNLOGGED とストアドプロシージャの組み合わせは、むしろ Redis を使うほうがずっとすっきりしている気はします（笑）
数年前のことですが、JSONBを使っていて負荷が高くなったときに、kvパターンに合うものを選んでRedisに切り出す形で作業したことがあり、快適な経験でした。
興味深い意見ですね。
釣りっぽいタイトルですが、それなりに考えてみる価値のあるテーマなので、そのまま持ってきました。
初期のMVPを進めるにあたって、あまりに多くのコンポーネントを導入するのも問題ですからね。
良いコンセプトのように見えます
ありがとうございます。