【テクニカル・上級編】 Bitmapsコマンド群 – Redis

Redis Bitmapsの真髄：メモリを極限まで削り、計算量をO(1)に収束させる技術

多くのエンジニアがRedisを「Key-Valueストア」と呼ぶ。しかし、我々アーキテクトにとって、Redisは「極めて洗練されたメモリ操作エンジン」だ。

特に`Bitmaps`は、その最たる例といえる。単なるフラグ管理の道具だと思っているなら、それはRedisのポテンシャルを10%も引き出せていない。今回は、`SETBIT`から始まるコマンド群の裏側にあるメモリレイアウトと、スケーラビリティを確保するための「非自明な設計」について深掘りしよう。

—

Redisにおいて、`Bitmaps`というデータ型は存在しない。正体は`String`型だ。
`SETBIT key offset value`を実行した瞬間、Redisは指定されたオフセットをバイト単位に変換し、必要に応じて`sds`（Simple Dynamic String）を拡張する。

オフセット `2^32 – 1` を指定すると、理論上は約512MBのメモリが確保される。しかし、ここには重要な罠がある。「疎なビットマップ」の生成には細心の注意が必要だ。

例えば、`SETBIT user:1 4294967295 1` を実行すると、Redisは即座に512MBのメモリをアロケートしようとする。この間、Redisはシングルスレッドでメモリ確保とゼロ埋めを行うため、サーバー全体が停止する。大規模システムでこれをやれば、即座にサービスアウトだ。

—

`BITCOUNT`や`BITOP`がなぜこれほど高速なのか。それは、Redisが内部でSIMD（Single Instruction, Multiple Data）命令を駆使して、ビット演算をCPUのレジスタ単位で並列処理しているからだ。

特に`BITCOUNT`の内部実装を見てみよう。Redisは個々のビットを逐次確認するような愚かな真似はしない。

このアーキテクチャのおかげで、数億ユーザー規模のログイン状態管理であっても、`BITCOUNT`はミリ秒単位で結果を返す。もしあなたが自前のDBで同じことをやろうとすれば、数秒のクエリになるのは目に見えている。

—

Bitmapsを実務で使う際、最も避けなければならないのは「単一キーの肥大化」だ。
数億ビットのキーを一つで管理すれば、Redisのレプリケーション時に巨大なパケットが流れ、ネットワークI/Oを飽和させる。

私は大規模トラフィックを捌く際、以下のような設計をとる。

ユーザーIDをキーのプレフィックスとオフセットに分割する
key = “daily_active:20231027:shard:{shard_id}”
offset = user_id % 1000000

シャードIDごとに分散させることで、メモリとレプリケーション負荷を均等化する
SETBIT daily_active:20231027:shard:0 12345 1

このように設計することで、特定のキーにアクセスが集中する「ホットキー問題」を回避しつつ、水平スケーラビリティを確保できる。

—

`BITPOS`（指定されたビット値が出現する最初の位置を探すコマンド）は、インデックス構築において最強の武器となる。
これは、メモリ上のバイト列をスキャンする際、「ビット演算によるスキップ」を行っている。

多くのエンジニアは「検索＝ループ」と考えがちだが、`BITPOS`は：
1. バイト単位でチェックし、`0x00`であれば一気に飛ばす。
2. 非ゼロのバイトに当たったら、その中でビットごとの探索を行う。

この実装により、メモリ空間にスパース（疎）なデータが含まれている場合、実質的な探索コストは極めて小さくなる。これこそが、Redisが「高速」であると言われる所以だ。

—

`SETBIT`や`BITCOUNT`を単なる関数として呼び出すのは、楽器の構造を知らずに鍵盤を叩いているのと同じだ。

Redisは、メモリという極めて高価で高速なリソースを、いかにエレガントに、いかに無駄なく使い切るかを競うためのリングだ。Bitmapsを使いこなせば、あなたは単なる開発者を超え、システムの「物理層」を支配するアーキテクトに近づくはずだ。

さあ、次はどのメモリ領域を最適化する？