【データベース】RedisとPostgreSQL

Transcript

1. 【データベース】 RedisとPostgreSQL
2. 目次 1. はじめに 2. Redisの基本的な構造 3. RedisとPostgreSQLの違い 4. RedisとPostgreSQLの速度検証 5. RedisとPostgreSQLの組み合わせ 6. まとめ
3. 1. 　はじめに • NoSQLとは？ ◦ スキーマ不要で柔軟なデータ管理ができるデータベースの総称。 ◦ 高速処理やスケーラビリティに優れ、キャッシュやリアルタイム処理に適している。 • Redisとは？ ◦ インメモリ型のKey-Valueストアで、データを高速に扱えるNoSQLデータベース。 • なぜRedisを学ぶのか？ ◦ ゲームで使用されるキャッシュ、ランキング、リアルタイム処理に強い ◦ RDB（特にPostgreSQL）との違いを理解することで、適材適所の選択ができる • このLTの目的 ◦ Redisの特徴を知る ◦ PostgreSQLとの違いを比較する ◦ 速度検証を通じて使いどころを理解する
4. 2.　Redisの基本的な特徴 • ✅ 高速なKey-Valueストア ◦ 📌 メモリ上でデータを管理し、高速アクセス（O(1)）が可能 ▪ データをRAM上に保存し、ディスクアクセスなし ▪ ハッシュテーブルを使用し、キー検索がO(1) で実行可能 ▪ 数百万件のデータでも即座にアクセスできる ◦ 📌 ディスクI/Oがないため、RDBより圧倒的に速い ▪ RDBはディスクI/Oが発生し、読み書きに時間がかかる ▪ Redisはメモリ上で処理するため、アクセスが極めて高速 ▪ 頻繁に読み書きするデータ(キャッシュ、ランキング)で特に有利
5. 2.　Redisの基本的な特徴 • ✅ データ構造 データ型 例 主な用途 String "userId" → "Taro" キャッシュ、カウンター List ["A", "B", "C", "A"] キュー、ログ管理 Set {"A", "B", "C"} 一意なデータ管理(ユーザID) Sorted Set (ZSET) (スコアのついたSet) {("A", 100), ("B", 200), ("C", 150)} ランキング Hash (Keyとフィールドのペア) Key : User123 フィールド : {"name": "Taro", "age": 30} ユーザー情報
6. 2.　Redisの基本的な特徴 データ永続化のオプション（データ保持方法） • RDB方式 → 一定間隔でスナップショットを保存し、まとめて ディスクへ書き込む ◦ デフォルトの保存方式。メモリの状態を定期的にスナップショットとして保存 ◦ 書き込み頻度が少ないデータ向き（大量の書き込みには不向き） • AOF方式 → すべての書き込みをログに記録し、順次 ディスクへ書き込む ◦ 書き込みの完全な履歴を保持し、サーバーダウン時にデータを復元しやすい ◦ ディスクI/Oが増えるため、パフォーマンスに影響が出ることもある • ハイブリッド → RDB + AOF を組み合わせ、速度とデータ耐久性を両立 ◦ スナップショットの高速性 + ログの完全性の両方を確保 ◦ 信頼性が求められるシステムでは、この方式が推奨される 🚨補足: Redisはメモリ上でデータを管理するため、 　　　　永続化設定をしないと電源を落とすとデータが消える。
7. 2.　Redisの基本的な特徴 スケーラブルな設計（Redisは拡張しやすい！） • シングルスレッドで動作（ロック不要） ◦ 1つの処理を順番に実行するため、複雑なロック処理が不要 ◦ 並列処理の競合がないため、高速かつ安定して動作 • レプリケーションでデータをコピー ◦ 本体（マスター）とは別に、コピー（スレーブ）を自動作成 ◦ 万が一、マスターが停止してもスレーブが代わりに動作 • シャーディングで負荷分散 ◦ データを複数のRedisサーバーに分けて管理し、1台の負担を軽減 ◦ 大量のデータやアクセスがあってもスムーズに処理できる！ 🚀 Redisはシンプルな設計のまま、負荷が増えてもスムーズに拡張できる！
8. 2.　Redisの基本的な特徴 主なユースケース（🚀 速処理が求められる場面で、特に力を発揮する！） • キャッシュ（頻繁にアクセスするデータの保存） ◦ データベースの負荷を減らし、高速にデータを取得できる ◦ 例：検索結果、APIレスポンス、ユーザープロフィールの一時保存 • ランキング（Sorted Setを活用） ◦ スコア付きデータをランキング順に管理し、素早く取得できる ◦ 例：ゲームのスコアランキング、人気記事ランキング • リアルタイムデータ処理（Pub/Sub） ◦ イベント発生時に即座に通知を送れる仕組み ◦ 例：チャットアプリのメッセージ配信、通知システム • セッション管理（ログイン情報の一時保存） ◦ ユーザーのログイン状態を保持し、認証処理を高速化 ◦ 例：Webアプリのセッション情報、ショッピングカートのデータ管理
9. 3.　RedisとPostgreSQLの違い ・Redisは大量のコマンドを高速に流すことを重視 ・PostgreSQLは整合性と堅牢性を重視 　→ だから処理方式も異なる 観点 Redis（NoSQL） PostgreSQL（RDB） トランザクション 整合性 基本無し （軽量なMULTI, EXECあり） ASID準拠 （順番に処理、確実に記録） 応答の扱い 応答を待たずに複数コマンドを送信可能 1クエリごとに応答が返る クライアント通信 pipe などで一括送信＋一括応答 JDBC／psqlで順番に送信、順番に応答 エラー時の対応 エラーが混在しても動く（運用で判断） 失敗時はロールバックが基本 データ保存 インメモリ ディスク保存 ✅ RedisとPostgreSQLはそもそも設計思想が異なる
10. 3.　RedisとPostgreSQLの違い ✅ 大量データを処理するには？ • Redis（NoSQL） ◦ ACID（特に整合性・永続性）を強くは保証しない ◦ そのため、コマンドごとの成功・失敗を都度待つ必要がない ▪ 一括でコマンドを送りつけてあとでまとめて応答を受ける 「パイプライン方式 」が可能 ▪ 逐次応答が不要 → 高速化に有利 • PostgreSQL（RDB） ◦ ACID（原子性・整合性・一貫性・耐久性）を厳密に保証 ◦ 特に、トランザクションの整合性が超重要 ▪ 各クエリは「順番に送信して、順番に結果を受け取る」のが基本 ▪ 一括で送るなら、複数レコードをまとめた SQL（バルク処理 ）で対応
11. 3.　RedisとPostgreSQLの違い 🚀 Redisは速度重視、PostgreSQLはデータの整合性重視！ 項目 Redis（NoSQL） PostgreSQL（RDB） データ保存 メモリ上(RAM) → 高速アクセス ディスク(HDD/SSD) → 永続的に保存 データ構造 Key-Value型 （String, List, Hash, 等） リレーショナル型 （テーブル・行・列） スキーマ 不要（スキーマレス） → 柔軟にデータ管理 必要（スキーマあり） → データ構造を厳密に管理 検索方法 キー検索（O(1)） SQLで複雑な検索（JOIN, WHERE） トランザクション シンプル（MULTI, EXEC） ACID完全対応 用途 ランキング、リアルタイム処理 データの一貫性が必要な業務システム ✅ その他の違い
12. 4.　RedisとPostgreSQLの速度検証 📌 検証環境（Redis & PostgreSQL） • 共通 ◦ OS : Mac ◦ 環境 : Docker ◦ 計測回数 : 2回目～4回目（合計3回） の測定結果を平均化 ▪ 1回目はキャッシュなしのため除外 ◦ 測定方法 :DockerCLIで各コマンドを実行し、ログから実行時間を算出 ◦ 必要なコマンドやクエリは通信前に作成しこれを送信 • Redis ◦ 100万件の追加更新削除はパイプライン処理 を使用 • PostgreSQL ◦ 対象テーブルにカラムは3つ。そのうち1つが主キー ◦ 100万件の追加更新削除はプロシージャのバルク処理 を使用
13. 4.　RedisとPostgreSQLの速度検証 （補足）パイプライン処理とバルク処理の比較 比較項目 Redis のパイプライン処理 PostgreSQL のバルク処理 処理方式 複数のコマンドを一括で送信・受信 複数レコードを一つの SQL でまとめて処理 目的 通信の往復回数を減らして高速化 トランザクション数とパース回数を減らし高速化 対象 Redis コマンド（例：SET, HSET, ZADD） SQL クエリ（例：INSERT, UPDATE, DELETE） クライアントの役割 コマンドを組み立てて パイプで流す SQL を組み立てて 1つにまとめる サーバの動作 コマンドを順に実行 SQL を1回でパース・最適化 効果が出やすい条件 リクエストを送信し、 応答までに時間のかかる環境 データ量が多く、1件ずつの SQL が非効率な場合 主なユースケース 大量データ登録・一括更新など まとめてINSERT/UPDATE/DELETE/COPYする時
14. 4.　RedisとPostgreSQLの速度検証 カテゴリ Redisの処理 結果 (秒) PostgreSQLの処理 結果 (秒) 追加(1件) HSETで1件分の ユーザーデータを追加 0.209 INSERT文をクライアント側で 1件生成し、 BEGIN〜COMMITで一括実行 0.243 追加(100万件) HSETを使ったコマンドを生成し --pipe でパイプライン一括追加 4.283 INSERT文をクライアント側で 100万件生成し、 BEGIN〜COMMITで一括実行 6.23 更新(1件) HSETで同一キーに 再追加し値を更新 0.201 UPDATE文（id指定）を1件生成し、 BEGIN〜COMMITで一括実行 0.274 更新(100万件) HSETで既存の100万キーに対し 新しい値を再設定（ --pipe使用） 3.838 UPDATE文（id指定）を100万件生成し、 BEGIN〜COMMITで一括実行 147.61 削除(1件) DELでキーごと削除 0.224 DELETE文（id指定）を1件生成し、 BEGIN〜COMMITで一括実行 0.246 削除(100万件) DELコマンドを100万件分生成し、 --pipe で一括削除 1.535 DELETE文（id指定）を100万件生成し、 BEGIN〜COMMITで一括実行 151.80
15. 4.　RedisとPostgreSQLの速度検証 カテゴリ Redisの処理 結果 (秒) PostgreSQLの処理 結果 (秒) 単純キー検索 (100万件) HGETで対象ハッシュ内の 特定フィールドを検索（ O(1)） 0.217 WHERE id=◯◯◯ を用いた1件取得 0.257 範囲検索 (100万件) ZADDでスコア付き情報を登録後、 ZRANGEBYSCOREで30以上を抽出 1.338 WHERE score >= 30 で検索 3.994 ランキング取得 (100万件) ZADDでスコアを設定後、 ZREVRANGEで上位100件を取得 0.212 ORDER BY score DESC LIMIT 100 による上位100件取得 0.289
16. 5.　RedisとPostgreSQLの組み合わせ • Redis × PostgreSQL の役割分担 🔄 ◦ Redis：リアルタイム処理や一時的なキャッシュに強い ◦ PostgreSQL：永続的なデータの保存や複雑な集計・整合性に強い • 組み合わせるメリット 💡 ◦ 頻繁にアクセスするデータを Redisにキャッシュ → アプリの応答速度アップ ◦ 更新・保存が必要なデータは PostgreSQLに記録 → データの信頼性を確保 ◦ → それぞれの強みを活かせる構成 • 活用例（ゲームの場合） 🔧 ◦ ランキングやセッション情報 → Redis（高速アクセス） ◦ プレイヤーのプロフィールや課金履歴 → PostgreSQL（整合性・履歴保持） • 一言まとめ ✅ ◦ 💡 リアルタイム性と整合性、両方を求めるアプリケーションで 相互補完の関係が築ける！
17. 6.　まとめ • RedisとPostgreSQLの比較からわかったこと 📌 ◦ Redisはリアルタイム性・高速性に優れ、一時的なデータ管理やランキングなどに最適 ◦ PostgreSQLは整合性・複雑な検索・集計処理に強く、永続的なデータ管理に最適 • 速度検証の結果から 🚀 ◦ 一件処理はどちらも高速だが、大量処理では Redisのパイプライン処理が圧倒的に速い ◦ 一方で、PostgreSQLはACID準拠のため処理順や整合性を保証するぶん、時間がかかる ◦ 処理速度だけでなく、システムの要件に応じた選択が重要 • RedisとPostgreSQLは目的が異なる ✅ ◦ 💡 RedisとPostgreSQLはそもそも設計思想が異なるため、 単純な速度比較だけでは本質を見誤る可能性がある。 → 大事なのは「適材適所」で活用すること！ • 最後に 🎯 ◦ それぞれの強みを理解し、組み合わせて使う設計が最も効果的 ◦ リアルタイム性と整合性の両立を意識した設計ができるようになろう！