Redis Bitmap の基礎知識
Redis の Bitmap は、厳密には単体のデータ型として存在するものではなく、文字列(String)を基盤とした上でビット単位の操作を提供する拡張機能です。この仕組みにより、配列のようにインデックスを指定して各ビット(0 または 1)にアクセスすることが可能になります。
内部ではバイト単位のデータが格納されますが、アプリケーション層ではこれをビットの集合体として扱います。例えば、1 バイト(8 ビット)の領域があれば、最大 8 つのフラグ情報を格納できます。オフセット値(index)は 0 から開始され、特定の位置にあるビットの状態を読み書きするための基準となります。
主要な操作コマンド
Bitmap を取り扱う際は、主に以下の 4 つのコマンドを使用します。
-
SEBIT
指定されたキーに対し、特定のオフセット位置のビット値を 0 または 1 に設定します。
# 2024 年 1 月 1 日のログイン履歴にユーザー 50 と 120 を登録 SETBIT login_hist:20240101 50 1 SETBIT login_hist:20240101 120 1 SETBIT login_hist:20240101 330 1 SETBIT login_hist:20240101 505 1 -
GETBIT
キーの特定オフセット位置のビット値を取得します。
# ユーザー 330 が該当日時にログインしたか確認 GETBIT login_hist:20240101 330 -
BITCOUNT
保存されたバイト列全体、または指定された範囲内(バイト単位)で 1 となっているビットの総数を返します。
# 当日の総ログインユーザー数を算出 BITCOUNT login_hist:20240101 # 特定のバイト範囲のみ集計(例:オフセット 8〜23 相当) BITCOUNT login_hist:20240101 1 3 -
BITOP
複数のキーに対して論理演算(AND, OR, XOR, NOT)を行い、結果を別のキーへ格納します。
# 連続 2 日間ログインしたユーザーを抽出(共通部分) BITOP AND overlap_user:20231201_02 hist:20231201 hist:20231202 # 計算結果の人数を確認 BITCOUNT overlap_user:20231201_02
Set データ型との消費メモリ比較
大規模なユーザー基盤を持つサービスにおいて、どの方式を採用するかはメモリコストに直結します。以下は、1 億人のユーザーのうち 5000 万人がアクティブである場合の仮定による試算です。
| データ種別 | 識別子あたりの必要幅 | 対象ユーザー数 | 1 日あたりの容量目安 | 年間推定容量 |
|---|---|---|---|---|
| Set コレクション | 64 ビット | 5000 万 | 約 400MB | 約 144GB |
| Bitmap | 1 ビット | 1 億 | 約 12.5MB | 約 4.5GB |
しかし、アクティブ数が極端に少ないケースでは逆転現象が発生します。例えば、全ユーザー数が 1 億人でも、アクティブユーザーが 10 万人程度の場合、Set 型のほうが約 800KB で済み、Bitmap の固定サイズ(約 12.5MB)と比較して圧倒的に軽量になります。このため、Bitmap は密度が高いデータ(スパースでない状態)に適用するのが適切です。
実装上の注意点と設計指針
Bitmap の効率的な利用には、いくつかの設計上の配慮が必要です。
- オフセットの正規化
ユーザーID やシード値などが巨大な数値帯域を持っている場合、そのままオフセットに使用するとキー自体が大きくなりすぎます。ベースとなる最小値を引くなどして、相対的な数値に変換してから保存することでメモリ確保範囲を最適化できます。 - 初期化時のレイテンシ
非常に大きなオフセット値へアクセスを行う際、Redis はその間のメモリ領域を確保するために時間がかかることがあります。事前に必要な範囲を見積もり、適切な鍵設計を行わないと、予期せぬ処理停止や遅延を引き起こす可能性があります。 - 向いているユースケース
メインテナンス頻度の高い大規模サイトの MAU(月間アクティブユーザー)解析、あるいは高頻度なチェックイン機能など、データ密度が高く大量の記録をコンパクトに保持したいシステム構築において特に有効です。