Redis（REmote DIctionary Server）は、
主に アプリケーションキャッシュ や 高速なデータストア として使われる
オープンソースのインメモリ NoSQL Key-Value ストアです。
本記事では、
- RDBMSとRedisの思想の違い
- Redisがなぜ速いのか
- Redis Clusterによるシャーディング
- Redisのpub/sub
を解説します。
RDBMSの仕組み（図書館モデル）
RDBMSを一言で言うと、
「安全・高機能だが慎重」なデータ管理システム
です。
イメージ
- 利用者：アプリケーション
- 司書：DBエンジン
- 本棚：ディスク
- 机：メモリ（バッファ）
利用者は司書に依頼し、司書が本棚から本を持ってきます。
- JOIN
- WHERE
- 集計
- 並び替え
といった 複雑な要求 にも応えられる反面、
毎回きっちり確認・管理するため処理は重い です。
RDBMSの長所・短所
長所
- データの整合性・永続性が高い
- 複雑な検索が可能
短所
- レイテンシが大きい
- スケールしづらい
Redisの仕組み（机に置きっぱなしモデル）
Redisは真逆の思想です。
「速さ最優先。複雑なことはしない」
イメージ
- 本棚はほぼ使わない
- 本は机の上に置きっぱなし
- どこに何があるかを完全に把握している「机マスター」が即座に取り出す
Redisの長所・短所
長所
- 圧倒的に速い（ミリ秒未満）
- 実装が単純
短所
- 複雑な検索はできない
- メモリ依存（容量・揮発性）
- RDBMSほどの安全性はない
なぜRedisは速いのか
理由はシンプルです。
速さ = (データ構造が単純) × (すべてメモリ上)
- ディスクI/Oがほぼない
- JOINがない
- インデックス設計が不要
- トランザクション管理が軽量
Redis Cluster（シャーディング）
Redisは 1台あたりのメモリに限界 があるため、
複数台でデータを分散管理します。
これを シャーディング と呼び、
その管理を行うのが Redis Cluster です。
slot（スロット）とは
Redis Clusterでは、
すべてのKeyが 0〜16383 の slot に割り当てられます。
例：
- slot 0〜5460 → Node1
- slot 5461〜10922 → Node2
- slot 10923〜16383 → Node3
Redis Clusterのシーケンス図
※ 実際にはクライアントライブラリが
MOVED 応答を見て自動的に再接続します。
Redisのデータ型
String
- Key / Value の最小単位
- 数値も扱える（INCR など）
用途例：
- セッション
- フラグ
- カウンタ
List
- 順序付き配列
- 最大約 40億要素
用途例：
- キュー
- ログ
Set
- 順序なし
- 重複なし
用途例：
- タグ管理
- 抽選
- フィルタリング
Sorted Set
- Set + score
- スコア順に並ぶ
用途例：
- ランキング
- 優先度付きキュー
Hash
- Key の中に field / value
用途例：
- ユーザープロファイル
- オブジェクト表現
Redisのユースケース
- リアルタイム分析
- キャッシュ
- セッション管理
- ランキング
- 地理情報検索
- メッセージング
pub/subとは
pub/sub（Publish / Subscribe）は、
「送る側」と「受ける側」を疎結合にする通信モデル
JavaScript の addEventListener に近い考え方です。
Redisにおけるpub/subの流れ
基本動作
- Subscriber が
SUBSCRIBE channel - Redisと 接続が張りっぱなし
- Publisher が
PUBLISH channel message - Subscriber に即時配送
pub/subのシーケンス図
pub/subの注意点（重要）
-
SUBSCRIBE接続では 他のRedisコマンドを送らない -
接続プールとは分ける
-
非同期処理必須（Node.js向き）
-
Subscriberがいなければメッセージは消える
-
DB番号（SELECT）は影響しない
- チャンネル名で分離する
まとめ
-
RDBMS
→ 正確・安全・多機能だが遅い -
Redis
→ 単純・高速・リアルタイム向け -
Redis Cluster
→ slotによるシャーディング -
pub/sub
→ 疎結合なリアルタイム通信に最適