Get Started

Dive Deep Redis ~ 入門から実装の確認まで

Redis本を執筆しました。こちらも是非合わせてご覧ください。 実践Redis入門 技術の仕組みから現場の活用まで ——————————————————————————————————————————————————— Redis(REmote DIrectory Server) Redisは例えば以下の特徴を持つLLOOGGを元としたインメモリの非リレーショナルのデータベースです。 この記事では、入門から始まり、実装をより意識することで深く理解することを目標としています。以下の説明中の(*)マークは、特にVanilla Redisでの話となり、サービスとしてRedisが提供されている場合には工夫されていて挙動が異なるものもあります。 なお、合わせてRedisのソースコードの各種ファイルの概要についての詳細は以下の記事をご覧ください。 RedisのGETコマンド実行時のソースコード中のフローの詳細については、以下の記事をご覧ください。 レポジトリはこちらになります。 データ型 Basic その他代表コマンド UNLINKはRedis 4.0から導入されたコマンドで、サイズが小さいときはDELと同様の挙動で、そうでないときは一旦バックグラウンドでキューに入れられ、他のスレッドによって非同期に削除される挙動になります。削除対象のオブジェクトのサイズが大きいとDELは操作をブロックする問題を受けて、オブジェクトの割当て解除のコストを考慮して削除を行うコマンドが実装されました。また、FLUSHALLで全データベース内、FLUSHDBで現在のデータベース内の全キーを削除することが可能ですが、4.0以降にASYNCオプションで、これらのコマンドでも非同期に削除できるようになりました。 内部エンコーディング Redisでは、各種データを保存する際に、メモリ使用量を押さえるために内部エンコーディングを実施して保存することができます。その際に閾値はパラメータ等で設定を行います。 実行例 パイプライニング/トランザクション/Luaスクリプト/モジュール パイプライニング パイプライニングは前のレスポンスを待たずに新しいリクエストを送ることができるようにして、複数のコマンドを送信することで、ネットワークのRTTを節約することによるネットワーク最適化を目的としたものとなります。パイプライニング内での順番は保証されているため、それを必要とするようなワークロードの場合には特に効果的です。read()やwrite()のsyscallといったソケットI/Oは、ユーザーランドからカーネルランドへの移動でコンテキストスイッチが大きく、これらを集約することができるため、RTT以外でもこちらの観点でもレイテンシー削減の効果があります。 RTT削減という観点では、MGET/MSETやHMGET/HMSETで複数キーを送信することも可能です。後述のトランザクション/Luaスクリプトでは処理を実行中他のクライアントが割り込むことができないためAtomicに処理が行われますが、パイプライニングでは実行中他のクライアントも処理を実行することができるため処理スクリプトがAtomicに処理が行われることは保証されません。 loopbackインターフェイス使用しているにも関わらず遅い場合は、カーネルのスケジューラーでプロセスが稼働していない可能性も考慮 トランザクション トランザクション(Redis 1.2~)であるMULTI/EXECは実行内で他のクライアントが割り込むことなく処理をすることを保証します。MULTIコマンド以降に宣言されたコマンドをキューイングしていきます。トランザクション実行時は、以下のような理由で失敗することがあります。Redis 2.6.5以降は、キューイング中にエラーが発生した場合、EXECコマンド実行時にトランザクションの実行を拒否し、自動的に破棄するようになりました。以前は、キューイングに成功したコマンドはトランザクションを実行するような挙動になっていました。 Redisはロールバック機能をサポートしておらずコマンド失敗時もそのまま残りの処理を継続します。コマンド失敗は上記のような場合が考えられ、事前に検知可能と考えられるため、機能を省くことでよりシンプルかつ高速に動作するように設計しています。DISCARDコマンドでトランザクションを途中で打ち切りキューを捨てることができます。WATCHコマンドはCAS機能を実現し、EXEC実行前に対象のキーに変更が加えられていたらトランザクション全体を中止します。このように競合しないことを期待して処理を行っていく種類のロックを楽観的ロックと呼びます。なお、WATCHコマンドのキーを対象から除外するためにUNWATCHコマンドもあります。 Luaスクリプト Luaスクリプト(Redis 2.6~)は、RTT削減に加えて、Read/Writeの両方を最小レイテンシーで利用するような場面で特に効果を発揮します。一方でパイプライニングでは、writeコマンド呼び出しの前にreadコマンドのリプライを必要とするため役立ちません。パイプラインやトランザクションで可能なことは　後続で登場したLuaスクリプトで実現可能です。 モジュール モジュール機能(Redis 4.0~)では、Redisが提供しているString,List,Set,Hash,Sorted Setなどのデータ型にとどまらず独自でデータ構造を実行することができます。またコマンド等も自作することができるため、アプリケーションごとに最適な環境をRedisに実装することができます。モジュールは互換性を意識してRedisコアとモジュールAPIを介して操作するような設計となっています。モジュール機能をLuaスクリプトと比較すると、以下のような特徴があります。 バックアップ: RDB/AOF AOFファイルでは、fsyncでディスクへの書き込みが行われるが、appnefsyncの設定に応じてタイミングを設定できます。 また、以下の基準を満たすと自動でバックグラウンドスレッドの処理により、BGREWRITEAOFコマンドを実行することでAOFのrewriteでディスクへの書き込みが行われます。ただし、AOFのrewrite中やRDBファイルの保存中は実行を避けます。 AOFとRDBファイルの両方がある場合、appendonlyがyesの場合はAOFファイルが読み込まれ、noの場合はRDBファイルが読み込まれます。ただし、Redis 4.0以降、RDB+AOFのMIX形式を使用することができます。RDBファイルで定期的に完全なダンプファイルを取得し、RDBファイル以降の差分はAOFとしてコマンドを保存する形で両者の良いところ取りのような形で行われます。aof-use-rdb-preambleをyesにすることでmix型を使用できます。5.0以降デフォルトでも有効になりました。 BGSAVEのようなRDB取得によるバックアップの処理はパフォーマンスへ影響が出ることが考えられますので、以下の観点で確認しておくと良いです。 互換性 2.4で作成されたAOF/RDBを2.6から読み取ることができません。同様に2.4のマスターからスレーブを2.6のものを使用することはできません。 メモリ管理 アーキテクチャ 関係式 maxmemoryにはスレーブのClient Output Bufferが含まれない点に注意。 Client Output […]