Redis Set型を使いこなせ：O(1)の魔法と「集合演算」の劇薬
RedisのSet型。ただの「ユニークな値のリスト」だと思っていないか？
もしそう考えているなら、君の設計はまだ一段階、浅い。
Set型は、Redisの真髄である「計算量の最適化」を最も体現するデータ構造の一つだ。インメモリにおけるハッシュテーブルの実装であり、挿入、削除、存在確認（SISMEMBER）が、ほぼすべてO(1)で完了する。
今日は、教科書的な説明は省く。現場で「なぜSetを使うのか」「どう使うと火傷するのか」という、我々アーキテクトがレビューで最も気にするポイントに絞って伝授する。
—
1. 「集合演算」という名の諸刃の剣
`SINTER`（積集合）、`SUNION`（和集合）、`SDIFF`（差集合）。これらは非常に強力だが、同時にパフォーマンスの地雷でもある。
これらのコマンドの計算量は $O(N \times M)$（Nは最小のセットの要素数、Mはセットの総数）に比例する。つまり、数百万件の要素を持つ巨大なSetに対してこれらを実行すれば、シングルスレッドであるRedisは瞬時にブロックされ、他のリクエストがすべてスタックする。
アーキテクトの助言:
- 巨大なセットの演算は避ける: アプリケーション側で処理するか、あるいは演算結果を別のキーにキャッシュする `SINTERSTORE` を使い、その書き込み負荷を考慮して非同期処理に回せ。
- 読み取り専用レプリカへのオフロード: もし計算コストが高い演算を頻繁に行うなら、マスターに負荷をかけず、リードレプリカで演算させるという戦略も視野に入れるべきだ。
—
2. SISMEMBERの「正しさ」を担保する
実務で最も多用するのが `SISMEMBER` だ。ユーザーIDの存在確認や、権限チェック、重複排除のフラグとして使うことが多いだろう。
ユーザーの「お気に入り」管理
O(1)で瞬時に判定。RDBMSの COUNT() > 0 より遥かに速い。
SADD user:100:favorites “item:555”
SISMEMBER user:100:favorites “item:555”
=> 1 (存在する場合)
ここで注意点だ。
もし君が「存在確認をしてから何か処理をする」というロジックをアプリケーション側で書いているなら、それは競合（Race Condition）の温床だ。
RedisのSetはアトミックだが、アプリケーション側の「チェック→実行」はアトミックではない。複雑なビジネスロジックが絡む場合は、Luaスクリプトを使ってRedis側で完結させろ。
—
3. メモリ効率と「要素数」のリアリティ
Set型は、要素が少ないうちは `intset` というメモリ効率の極めて高い構造体として内部保持されるが、設定値を超えると通常のハッシュテーブルに昇格する。
- `set-max-intset-entries` の設定値を意識したことはあるか？
- 数十万件規模のSetを乱立させると、Redisのメモリ消費量は線形的に跳ね上がる。
メモリは無限ではない。もし「ただ存在を知りたいだけ」で、かつ誤検知がある程度許容できるなら、Bloom Filter (RedisBloomモジュール) を検討しろ。Setの数分の一のメモリで同等の結果が得られるはずだ。
—
4. SRANDMEMBERとSPOP：ランダムサンプリングの真価
意外と知られていないが、`SRANDMEMBER` は単なるランダム取得ではない。
統計的なサンプリングや、A/Bテストのユーザー振り分けに極めて強力だ。
100万人のユーザーから、ランダムに100人を抽出してクーポンを配布する
データベース全件走査などという愚かなことはせず、Redisに任せろ
SRANDMEMBER active_users 100
`SPOP` を使えば、キューイングシステムのような使い方もできる。「二重処理が許されないタスクの取り出し」において、これほど効率的で安全な手段は他にない。
—
魂を込めた設計のまとめ
1. Setは「高速な存在確認」のための最強のインデックスだと認識せよ。
2. 集合演算（SINTER/SUNION）は「重い処理」であることを常に意識し、必要なら `STORE` 系コマンドで結果を永続化せよ。
3. キーの設計を疎かにするな。 `user:{id}:likes` のようなキー設計は、Redisのメモリを確実に食いつぶす。TTLの設定、あるいはLRUによる淘汰が適切か、設計フェーズで必ず議論すること。
Redisは「速い」だけではない。どう使うかという「知性」を問うツールだ。
明日からの実装で、ただSetを使うのではなく、「なぜSetなのか」を自問自答してほしい。それが君を一段上のエンジニアへと引き上げるはずだ。
以上だ。健闘を祈る。
コメント