こんにちは、かつコーチです。
「Redisってキャッシュに使うらしいけど、MySQLとかPostgreSQLと何が違うの？」
そんな疑問を持ったことはないでしょうか。
私自身、初めてRedisという名前を聞いたときは、「もう1つのデータベースが増えただけ」くらいにしか思っていませんでした。
ですが実際に触ってみると、RDBMS（Relational Database Management System、行と列の表形式でデータを管理するデータベース）とは根本的に発想が違う道具だと分かります。
この記事では、Redisの正体と、MySQLなどのRDBMSとの違いを初心者向けに整理します。
これまで学んできたSQL/DBシリーズの中でも、Redisは少し異色の存在です。
その理由も含めて、じっくり解説していきます。
Redisとは何か
インメモリKVSという仕組み
Redis（Remote Dictionary Server）は、データをディスクではなくメモリ（RAM）上に保持する、KVS（Key-Value Store、キーと値のペアでデータを管理する仕組み）です。
この「メモリ上にデータを保持する」という性質が、Redisを理解する上で最も重要なポイントです。
MySQLやPostgreSQLのようなRDBMSは、データを主にディスク（HDD/SSD）に保存し、必要に応じてメモリにキャッシュしながら読み書きします。
一方Redisは、原則としてすべてのデータをメモリ上に載せた状態で動作します。
メモリへのアクセスは、ディスクへのアクセスに比べて桁違いに高速です。
一般的に、ディスクアクセスがミリ秒単位の待ち時間を伴うのに対し、メモリアクセスは1ミリ秒以下で完了するとされています（ninja-school「Redis入門！キャッシュの仕組みやメリット」）。
この速度差こそが、Redisが「速いデータベース」と呼ばれる理由です。
RDBMSとの根本的な違い
ここまで学んできたMySQLやPostgreSQLは、テーブル・行・列という構造でデータを管理し、JOINや複雑なWHERE条件で柔軟にデータを検索できるのが強みでした。
Redisはこれとはまったく異なるアプローチを取ります。
| 観点 | RDBMS（MySQL等） | Redis |
|---|---|---|
| データの保存先 | 主にディスク | 主にメモリ |
| データ構造 | テーブル（行・列） | キーと値（KVS） |
| 得意なこと | 複雑な検索・集計・整合性の担保 | 高速な読み書き・一時的なデータ保持 |
| 検索方法 | SQL（SELECT・JOIN等） | キーを指定した直接アクセスが基本 |
| 永続化 | 標準で行う | オプション（設定次第） |
表を見て分かる通り、RedisはSQLで複雑な検索をするための道具ではありません。
「特定のキーに対応する値を、とにかく速く読み書きする」ことに特化した道具です。
そのため、Redisは「RDBMSの代わり」ではなく、「RDBMSと組み合わせて使う相棒」という位置づけになります。
なぜRedisが必要なのか
RDBMSだけでは速度が足りない場面がある
Webアプリケーションを運用していると、同じデータに対して大量のアクセスが集中する場面が出てきます。
例えばECサイトのセール開始直後や、チケット予約サイトの受付開始直後などです。
こうした場面で毎回MySQLにクエリを投げていると、ディスクI/Oがボトルネックになり、レスポンスが遅延したり、最悪の場合サーバーがダウンしたりします。
Redisは、こうした「一度調べた情報を一時的に保存し、次回以降高速に取り出す」というキャッシュの仕組みに強みがあり、大量同時アクセスが発生する場面で真価を発揮します（ninja-school「Redisをキャッシュとして使う基本ガイド」）。
つまりRedisは、RDBMSへの負荷を減らしつつ、ユーザーには高速なレスポンスを返すための「緩衝材」のような役割を担います。
キャッシュ以外にもある代表的な用途
Redisは単なるキャッシュサーバーだと思われがちですが、実際にはそれだけではありません。
- List・Hash・Set・Sorted Setといった多様なデータ構造を扱える
- ログイン状態などを管理するセッションストアとして使える
- Pub/Sub（発行/購読モデルによるメッセージ配信）でリアルタイム通知の基盤になる
これらの用途については、このシリーズの以降の記事（R03〜R05）で詳しく扱っていきます。
まずは「Redis＝速いキャッシュ専用ツール」という理解から一歩進めて、「メモリ上で動く汎用的なデータストア」という理解に更新しておいてください。
Redisを使う上での注意点
メモリ上にあるということはデータが消える可能性がある
Redisの最大の特徴である「メモリ上で動作する」という性質は、裏を返せばサーバーを再起動するとデータが消える可能性があるということでもあります。
私が初めてRedisを検証環境で触ったとき、サーバーの再起動テストをした後にセッションデータがすべて消えていて、一瞬「バグか」と焦った経験があります。
これはバグではなく、Redisの仕様通りの挙動です。
RedisにはRDB（スナップショット形式でディスクに保存する永続化方式）やAOF（Append Only File、実行したコマンドを記録して復元する永続化方式）といった永続化オプションがありますが、デフォルト設定のままでは想定通りに永続化されないケースがあります。
「消えても困らないキャッシュデータ」なのか、「消えると困る重要なデータ（セッションなど）」なのかを意識して、永続化の設定を検討する必要があります。
この点は、後続のTTL戦略・セッション管理の記事で詳しく扱います。
RDBMSを置き換える道具ではない
Redisの速さに惹かれて、「もうRDBMSはいらないのでは」と考えてしまう初学者は少なくありません。
しかし、RedisにはJOINのような複雑なリレーション検索や、トランザクションによる厳密な整合性担保の仕組みが、RDBMSほど充実していません。
注文データや会員情報のような「正確に、長期間保存しなければならないデータ」はRDBMSに任せ、「一時的に、とにかく速く読み書きしたいデータ」はRedisに任せる、という役割分担が実務での基本的な考え方です。
まとめ
この記事のポイント
- Redisはメモリ上でデータを管理するインメモリKVSであり、RDBMSとは根本的に異なる仕組みを持つ
- メモリアクセスの速さを活かし、キャッシュ・セッション管理・Pub/Subなど多様な用途で使われる
- メモリ上で動作するため、再起動でデータが消える可能性がある点に注意が必要
- RedisはRDBMSの置き換えではなく、役割分担して組み合わせる「相棒」として使うのが基本
次に読むべき記事
- Redisのインストールと基本コマンド（GET・SET・EXPIRE）
- Redisのデータ構造（List・Hash・Set・Sorted Set）の使い分け
- Redisをキャッシュとして使う：TTL戦略の基本
タグ: Redis, 初心者向け, 入門
