【Redis】データ型の種類と用途、ユースケース（キャッシュ）

データ型の種類と用途

Redis Strings

Redisの最も基本データ型です。最大512MBまで格納できます。バイナリも格納できるため画像なども格納できます。また、加算減算コマンドもあります。

Redis Lists

「Redis Strings」のリストです。約42億個の要素にアクセスできます。

ユースケース

SNSやブログなどのタイムライン実装

LPUSHというクエリで要素を即座に追加したり、LRANGEというクエリで直近要素を高速に取り出して表示するなどもできる。

Redis Sets

順序を持たないStringsの集合。重複を許さない。

ユースケース

• IPや端末IDなどからアプリケーションへのユニークアクセスを確認する用途
• ブログや動画サイトなどでよく見かける、タギングシステムなども実装可能

Redis Hashes

オブジェクトを表現するのに適している。

Redis Sorteds Sets（ソート済みセット）

重複を許さないソート済みのものになります。

ユースケース

• 逐次更新が必要なシステム（リアルタイム更新されるスコアボード）
• Redisのデータインデックス

Bitmap

専用のデータ型ではない。

HyperLogLog

ユニーク要素のカウントを行う。Setsとかでも可能そうだが、ユーザー数が増えるごとに、メモリ消費量も増える。確実性を少し減らしてメモリ消費量を低減することをもくろむ機能。

ユースケース

大量のユニークユーザーのアクセスが予想されるサイトにおいて、そのカウントがSetsで実現できない場合などに用いる。

データストアにRDBを選んだ場合

大量アクセスがある場合、RDBへの書き込みや問い合わせ部分がボトルネックとなる場合がある。

原因

DBサーバのリソースや、帯域の圧迫などが想定されます。

これを対処しようと思うと、前者はスケールアップによる対処、後者はマスター/スレーブレプリケーションによるスケールアウトなどが必要になる。どちらも非常に高いコストがかかる。

Redisを使った場合

基本的には後述するように、「RDBが特に苦手とし、ボトルネックになりやすいソート処理を楽にするために使用するケースが実務では多い」でしょう。

クライアントからのリクエストによってRDB上のデータが必要になった場合に、まずRedisに対してそのクエリの結果がキャッシュとして存在するかどうか確認します。キャッシュにヒットした場合は、RDBへの問い合わせを行わずにキャッシュを用いて処理を実行して、クライアントへのレスポンスを行います。

もし、存在しなかった場合はRDBに問い合わせてRedisに格納します。

このように同様のクエリを頻繁に実行するWebアプリケーションの場合はRedisを使うことによって性能向上やボトルネックの解消に寄与できます。また、RDBへのリクエストの集中を分散できます。

特に効果を発揮するケース

特に、「Sorted Set(ソート済みセット型）」を使うことで高速にソート済みのデータを検索したり、取得できたりできます。

扱いやすいデータとして持つことも可能

RedisはHash型などの構造化したデータを持つことができるためアプリケーションから扱いやすい形でデータを持つことが可能。

時間による設定

時間ごとに割り当てるマシンリソースをコントロールすることが可能。特に、Elastic Cacheなどを使えば非常に簡単に設定できる。

増やした台数により性能向上を期待できる。

RDBと異なりレプリケーションによるスケールアウトができるので、増やした台数によって効率よく性能向上を期待できます。

このケースでの注意点

キャッシュの特性

キャッシュの生存期間によってはリアルタイム性が下がる可能性がある。システム設計の段階でキャッシュするデータ（リアルタイムに変化しないデータ）、キャッシュしないデータ（リアルタイムに変化するデータ）を明確にしておく必要がある。