【実務・中級編】 Redisデータ構造の概要 – Redis

Redisデータ構造の「正解」：単なるKVSとして使うのは今日で終わりにしよう

「Redis＝キャッシュサーバー」。この認識で止まっているなら、君のシステムはRedisのポテンシャルの1%も引き出せていない。

Redisは単なるキーバリューストアではない。インメモリで動作する「データ構造サーバー」だ。この本質を理解しているか否かで、アプリケーションのレイテンシとスケーラビリティは劇的に変わる。今日は、現場の第一線で戦うエンジニアのために、Redisのデータ構造をどう「武器」に変えるか、その極意を伝授する。

—

1. String：ただの文字列だと思うな

`SET`と`GET`しか使わないのは初心者だ。`APPEND`でログを溜めたり、`BITOP`でビット演算を行ったりするのは基本だが、真の使いどころはアトミックなカウンターにある。

極限の知見: `INCR`系コマンドは、単なる数値増加ではない。アプリケーション側で「読み取って計算して保存」というレースコンディションを誘発する実装をしていないか？全てのロジックをRedis側に委譲せよ。それがパフォーマンスを最大化する唯一の道だ。

2. Hash：オブジェクトをフラットに展開せよ

RDBのレコードをJSON文字列として`SET`しているなら、今すぐ修正してほしい。シリアライズのオーバーヘッドは馬鹿にならない。

実務的設計: `HSET`を使ってフィールド単位で管理せよ。ユーザープロファイルの更新などで、名前だけ変えたいのに全体を読み書きするのは非効率だ。`HGETALL`で全取得するのではなく、必要なフィールドだけを`HMGET`で抜く。これがメモリとCPUを節約するプロの流儀だ。

3. List / Set / Sorted Set：使い分けの境界線

この3つの違いを「なんとなく」で選ぶのは、設計の敗北だ。

List (Linked List): キューとして使う。`LPUSH` + `RPOP`によるタスクキューは鉄板だが、ブロッキング操作(`BRPOP`)を忘れるな。忙しいループでCPUを回し続けるのは愚行だ。
Set: 重複排除と集合演算。会員IDの管理やタグ付けに最強だ。`SISMEMBER`によるO(1)の存在確認は、RDBの`SELECT COUNT() … WHERE`よりも桁違いに速い。
Sorted Set (ZSet): Redisの真骨頂。スコアによる順位付け。ランキングシステムだけだと思ったら大間違いだ。「時系列データのタイムスタンプをスコアにする」ことで、期限切れ処理や範囲検索が信じられないほど高速になる。

ユーザーのランキングとスコアを管理
ZADD leaderboard 100 “user:1” 200 “user:2” 150 “user:3”

特定のスコア範囲のユーザーを取得（範囲検索の爆速化）
ZRANGEBYSCORE leaderboard 120 250
-> “user:3”, “user:2” が返る。RDBのインデックススキャンより高速だ。

4. HyperLogLog & Bitmap：メモリの限界を突破する魔法

データ量が1億件を超えた時、`SET`や`List`で管理しようとするとメモリがパンクする。ここでこれらを使う。

HyperLogLog: 誤差を許容できるなら、数億のユニークカウントもわずか12KBで収まる。DAU（Daily Active Users）計測でこれを使わない理由はない。
Bitmap: ユーザーのログイン履歴（日次）をビットで管理せよ。1ビット＝1日。1ユーザー1年分でも数百バイトだ。`BITCOUNT`を使えば、特定期間のログイン日数を一瞬で算出できる。

5. 設計レビューで必ず指摘する「やってはいけないこと」

1. Keysコマンドの乱用: 本番環境で`KEYS `を打った瞬間、Redisは停止する。`SCAN`を使え。これは鉄の掟だ。
2. 巨大なコレクションの放置: `HSET`や`SADD`で数百万の要素を1つのキーに詰め込むな。メモリ断片化と単一スレッドのブロックを招く。キーを分割（Sharding）し、負荷を分散させろ。
3. シリアライズの過信: メモリは無限ではない。特に構造化されていない巨大なJSONを突っ込むなら、まずはデータ構造を見直すのが先だ。

—

最後に：アーキテクトからの助言

Redisの最大の強みは、「どのデータ構造を使っても、その操作はほぼ計算量O(1)かO(log N)で終わる」という予測可能性にある。

コードを書くとき、常に考えろ。「このデータ構造は、俺がやりたい処理に対して計算効率が最適か？」と。RDBとRedisを適材適所で使い分ける。その境界線を引けるエンジニアこそが、高負荷に耐えうるシステムを設計できる。

さあ、次は君のコードで、Redisを限界まで使い倒してくれ。レビューを楽しみにしている。