An introduction to Redis®の翻訳です。
2022年9月7日
Redis®入門
Redisの内部と外部、そしてRedisがデータの連続体の中でどのような位置づけにあるのかを見てみましょう。
Redis®*は、インメモリ、シングルスレッド、オープンソースのNoSQLデータストアです。
ゲームのUIの一部にリーダーボード（トップ10プレイヤーリスト）を実装しているとします。ユーザーから見える更新をその場でスムーズに処理するソリューションが必要です。また、異なる認証サービスに接続するユーザーの「スティッキー」ログイン状態を処理するために、ユーザーセッションキャッシュを記述する必要があります。Microservices Architectureの別の部分では、プレイヤーレベルの状態を一時的に保存する必要があります。
これには、非常に高速で、軽量で、比較的形式にとらわれず、RAMを活用するシンプルなデータストアが必要です。
RDBMSと比較した場合、NoSQLデータストアとその柔軟性はよく知られているかもしれない。クラウドのACID準拠データベース・ソリューションは、トランザクション・データに最適で、レコードの完全性と分離を保証しますが、いくつかの異なるコストが発生します：
- 柔軟性に欠けるスキーマ：イベントはデータベースと同じスキーマに従わなければならない。
- 書き込み時間、パーティション、レプリケーション、レイテンシのコスト。
これは、数百万人のユーザーのそれぞれが、基本的にリアルタイムで更新されるリストや固有のセッションデータを必要とするような、大規模なゲームやソーシャルネットワークには単純にスケールしません。
人気のソーシャルメディア、ゲーム、共有コンピューティング、コラボレーションプラットフォームで常に更新されるリスト、カウンター、ビューを思い浮かべてください。Facebookのステータス、Twitterのトップトレンド、LinkedInのプロフィール閲覧数など、常に変化するデータを考えてみましょう。
あるいは、検索エンジンの結果カウンターを考えてみよう。もし厳格なトランザクション・メカニズムが、潜在的なネットワーク接続を介してACID一貫性のあるデータを1人1人のユーザーに対して読み書きするなら、Googleの結果カウンターのようなものは、何十億ものユーザーに対して本当にほとんど瞬時に機能するだろうか？
幸いなことに、まさにそのようなユースケースのために作られたオープンソースのソリューションがある。
この投稿では、インメモリ・キーバリューストア（その他）がどのようにデータを扱うのか、どのようなユースケースをサポートするのか、そして利用可能なRedisデータ型を通じてどのようにそれらをサポートするのかを見ていきます。
Redisとは？
Redis、またはRemote Dictionary SServerは、インメモリ、シングルスレッド、オープンソースのNoSQLデータストアです。その高いパフォーマンスにより、高速なデータストア、キャッシュ、さらには軽量なメッセージブローカーとして愛用されています。
Redis自身が「データ構造サーバー」と呼んでいるように、キーと値のペアの値の部分には、**文字列、リスト、集合、ソートされた集合、ハッシュ、ビットマップ、ハイパーログログを保持することができる。これらのデータ型がサポートする操作の範囲こそが、Redisをリレーショナル・データストアが過剰になるようなオンザフライ・ソリューションを立ち上げるための柔軟で簡単な選択肢にしているのです。
これらの機能により、RedisはRedisのデータ型そのものにほぼ直接マッピングされるさまざまな問題に対応することができます。しかし、Redisに切り替える必要はありません。ほとんどのアーキテクチャでは、Redisは他のデータストアを補完するものとして使用されています。
Redisができること（できないこと）
Redisは、その場でデータを保存したり呼び出したりできる、すぐに使えるキャッシュと考えることができる。Redisは1秒間に100k以上のSET（書き込み）と81k以上のGET（読み込み）が可能です。また、オフサイクルのディスク書き込みを頻繁に（設定可能）行うことで、永続化されたデータは再初期化時にも利用可能です。
プログラミング言語ライブラリの中には、Rubyのresqueやsidekiqライブラリのように、Redisのリストを利用して高速なデータソートのバックグラウンドジョブを実装しているものもあります。
SQLデータベースとは異なり、RedisはテーブルやカラムといったACIDをサポートするデータベーススキーマを実装していません。その代わりに、**{key}**という保存形式を採用している。メモリ常駐、シングルスレッド、C言語という低レベル言語で書かれているため、高速に変化するストアやキャッシュに最適です。
では、Redisがサポートしているデータ型はどのようにしてこの超高速実行を可能にしているのでしょうか？**Redisユーザーはデータ構造をその場で作成し、それに対して直接操作を実行します。
*キーは、そのキーに関連付けられたアイテム（値）を一意に識別し、検索するために使用されるアイテムです。キーはバイナリセーフなので、JPEGファイルと同じように、人間が読めるテキストでもバイナリ文字列でもかまいません。
Redisの値型には以下のものがあります：
- 文字列***は、キーに関連付けることができる最も単純な値です。文字列は、コードの断片、完全なHTMLページ、IPアドレスなど、プレーンテキストと思われるものを保存するのに適しています。Redisでは文字列を512MBまで保存できます。
- リスト***は、文字列またはリンクリストを挿入順に並べたものです。リストには重複した値を含めることができ、項目を先頭にも末尾にも追加できます。
- セット***はリストと似ていますが、重複した値を含むことができず、ソートされてい ません。セットは、結合、交差、減算を使用することができます。セットは一意で明確な値しか受け付けないため、カーディナリティを管理するのに適しています。
- 並べ替えセット*は、すべての文字列が浮動小数点数のスコアで並べ替えられたセットです。ソートされた集合では、スコアは繰り返すことができますが、関連する値は繰り返すことができません。
- ハッシュ(Hash) **** は、異なるオブジェクトを表す値に関連するフィールドのマップです。ハッシュは最大40億のフィールドを保持できる。そのため、ハッシュは1つのRedisインスタンスが非常に多くのオブジェクトを保持し、それらを操作するための効率的な方法を提供します。
- ビット配列とビットマップは文字列のように扱われ、個々のビットのセットとクリア、最初のセット（またはアンセット）ビットの検索、特定のバイナリ値にセットされたすべてのビットのカウントなどができます。
- HyperLogLog***またはHLLはRedis独自のもので、「集合のカーディナリティを推定するために使用される確率的データ構造」です。HLL自身は状態情報しか含まず、カウントされたアイテム数に比例するメモリ量ではなく、一定のメモリ量（最悪12k）を消費するアルゴリズムを採用しています。HLLは入力データを文字列から読み書きするので、文字列操作を使って項目の追加、取得、およびカーディナリティ計算からのカウントを行うことになる。
- pub/subパターンを持つストリーム*は、重要でないアイテムをコンシューマやグループにチャネリングするメカニズムの一部として使うことができる。新しいデータ型を実装したり、外部モジュールをサポートしてRedisの機能を強化することができます。
はじめに
Redisを試してみませんか？Aiven for Redisは、Aiven Consoleまたは直接コマンドラインから簡単にセットアップできます：
または直接コマンドラインから設定できます。
または、REST APIを使用することもできます。
まとめ
この記事では、Redisについて見てきました：Redisがどのようにデータを扱うのか、どのようなユースケースをサポートするのか、そしてどのようにサポートするのか。そして、Aiven ConsoleとAiven CLIの両方からAiven for Redisを使い始めました。
リスクフリーのホスティングおよびマネージドAiven for Redisを試してみたい方は、30日間の無料トライアルでお試しください、または製品ページですべてをお読みください！また、ブログや変更履歴のRSSフィードを購読したり、TwitterやLinkedInでフォローしてください。
参考文献
https://redis.io/topics/data-types-intro
http://oldblog.antirez.com/post/take-advantage-of-redis-adding-it-to-your-stack.html
http://highscalability.com/blog/2011/7/6/11-common-web-use-cases-solved-in-redis.html
* RedisはRedis Ltd.の商標です。RedisはRedis Ltd.の商標です。Aivenによる使用は参照目的のみであり、RedisとAiven Oyの間のいかなる後援、承認または提携を示すものではありません。