Redisは必要か？ PostgreSQLがキューイング、ロッキング、そして pub/sub 機能を提供してくれるのに（2021）

• ユースケース 1: ジョブキューイング

  • Redis は Web サービスでバックグラウンドジョブを調整するためによく使われる。
  • PostgreSQL 9.5 以降では SKIP LOCKED オプションを使ってジョブキューイングを実装できる。
  • このオプションにより、ロック待ちなしでジョブを選択でき、複数のワーカーが同じジョブを同時に処理しないことを保証する。

• ユースケース 2: アプリケーションロック

  • Redis は分散ロックによく使われる。
  • PostgreSQL のアドバイザリロックを使って同じ機能を実装できる。
  • アドバイザリロックにより、PostgreSQL の内部ロックエンジンをアプリケーション定義の目的で活用できる。

• ユースケース 3: Pub/Sub

  • Redis はイベントをアクティブなクライアントにプッシュするために使われる。
  • PostgreSQL 9 以降では LISTEN と NOTIFY 文を使って Pub/Sub 機能を提供できる。
  • PostgreSQL クライアントは特定のメッセージチャネルを購読でき、別のクライアントがそのチャネルにメッセージを送ると、すべての購読者が通知を受け取る。

• PostgreSQL をフル活用する

  • Redis は PostgreSQL とは異なる用途で使われ、TTL を持つデータのキャッシュや一時的なデータ保存に優れている。
  • PostgreSQL は SQL データベース以上の機能を提供しており、Redis を使っていた処理を PostgreSQL で置き換えられる可能性がある。
  • 複数のデータサービスを使う複雑さを減らし、運用コストを削減できる有力な選択肢になり得る。

[GN⁺]

Hacker Newsの意見

• Redisはアプリケーションと同じマシン上で動作すると、非常に高速な応答を提供する。これにより、Postgresとは異なる種類の処理が可能になる

  • インメモリのキー・バリューストアは、RAMの性能特性を必要とする処理に適している
  • ネットワーク越しにRAMの性能を得られないのは自明である

• PostgreSQLは単なるSQLデータベース以上の機能を提供する

  • ORMの背後でしかデータベースを使わないと、その機能を見逃す可能性がある
  • Redisのようなサービスを追加するより、すでに設定済みのデータベースを活用したほうがよい場合がある

• PGQueuerはPostgreSQLを使ってジョブキュー、ロック、リアルタイム通知を提供する最小限の代替手段である

  • Redisの必要性を減らせる

• Postgresは強力なデータベースである

  • Redisは導入のハードルが低く高い性能を提供し、メインデータベースの負荷を軽減する
  • APIレスポンスのキャッシュはPostgresでも可能だが、Redisを使うほうが簡単である
  • 別個のシステムを使うことには欠点もあるが、Redisの場合その欠点はそれほど大きくない

• ほとんどのプロジェクトで必要なのはシンプルなジョブキューだけであり、複雑なスタックを簡素化することが重要である

  • 商業的な利害を持つさまざまな代替手段が存在する

• Postgresにはいくつかの制約がある

  • KVストア、キュー、pub/sub、ロックなどの機能は実現できるが、簡単ではない

• まずはPostgreSQLで始め、必要になったらRedisに切り替えるのがよい

  • 可動部品の数を最小限に抑えることが重要である

• Postgresのpub/subの大きな欠点は、メッセージサイズが8000バイトに制限されることである

  • データをデータベースに保存してIDを送る方法もあるが、追加の作業が必要になる

• Redisの最も重要な用途の1つであるキャッシュは、Postgresではより複雑になる

  • Postgresの更新は挿入よりコストが高く、耐久性の保証はキャッシュにとって重要ではない

• Postgresでこれらの機能を使うと、更新とレプリケーションがより難しくなる

  • 可能ではあるが、Postgresのより広く使われている機能に集中したい