Redis名前空間とRedisで開発するためのその他のキー

Redisを使用してアプリケーションを開発するのはとても楽しいですが、他のテクノロジーと同様に、RedisベースまたはRedis名前空間アプリケーションを設計する際に留意すべき点がいくつかあります。おそらくすでにリレーショナルデータベースの開発に精通しているでしょうが、同じ方法の多くが当てはまりますが、Redisはインメモリデータベースであり、（ほとんど）シングルスレッドであることに注意してください。 Redisキーのベストプラクティスを探求するために読んでください。

したがって、Redisを使用する際に注意する必要があるいくつかの特性があります：

1。 Redis名前空間を使用してキーを追跡します

データベースにはデータが保存されますが、開発者は、Redisに入力しているデータの一部を見失う可能性があります。これは、アプリケーションの要件が変更されたり、データの保存方法が変更されたりするため、当然のことです。おそらく、いくつかのキーを期限切れにすることを怠ったか、アプリケーションのモジュールが廃止された可能性があります。

いずれにせよ、Redisデータベース内の一部のデータが使用されなくなり、目的のないスペースを占有している可能性があります。 Redisのスキーマがないという性質により、キーに堅実な命名法を使用しない限り、データセットのコンテンツを理解することは非常に困難です。キーにRedis名前空間を使用して適切な命名方法を使用すると、データベースのハウスキーピングがはるかに簡単になります。アプリケーションまたはサービスによってキーに名前空間を付ける場合、慣例では、コロン（‘：’）文字を使用して、キーの名前の一部を区切ります。これは、Redis名前空間のベストプラクティスです。このようにして、データの移行、変換、削除、または移動中にそれらを簡単に識別できます。 Redis名前空間とRedis名前空間キーはこの識別に役立ちます。

Redis名前空間以外に、Redisのもう1つの一般的な使用例は、「ホット」データアイテムのセカンダリデータストアとしてですが、ほとんどのデータは別のデータベース（PostgreSQL、MongoDBなど）に保持されます。このような場合、開発者は、プライマリデータストアからデータを移動するときに、Redisからデータを削除することを忘れることがよくあります。この種のデータストア間の依存関係には、カスケード削除が必要です。これは、特定のデータ項目のすべての識別子をRedisセットに保持することで実装できます。これにより、プライマリデータストアからの削除後に呼び出されるクリーンアップ手順では、関連するすべてのコピーと関連する情報（完了時のセット自体を含む）を削除するために、そのセットのコンテンツを反復処理するだけで済みます。

2。キー名の長さを追跡する

これは、Redis名前空間に関する上記と矛盾しているように見えるかもしれませんが、キー名もメモリを消費するため、短くするように努める必要があります。明らかに、これは数百万または数十億のキーで構成されるデータセットで問題になりますが、実際には、長いキーにはハッシュテーブルとの価格があります。

例：Redis名前空間で1,000,000個のキーを保存すると、それぞれが32文字の値で設定され、6文字のキー名を使用する場合は約96MB、12文字の名前で111MBを消費する（32ビットのRedisサーバーの場合）と考えてください。キーの数が増えると、この15％を超えるオーバーヘッドは非常に重要になります。 Redisを使用すると、プレフィックス付きのキーを削除することも可能です。

3。適切なデータ構造を使用する

メモリ使用量またはパフォーマンスのいずれかのために、あるデータ構造が別のデータセットよりもデータセットに適している場合があります。覚えておくべきいくつかのベストプラクティスは次のとおりです。

• 数千（または数百万）の独立した文字列値でデータを保存する代わりに、関連データをハッシュデータ構造でグループ化することを検討してください。ハッシュは非常に効率的であり、メモリ使用量を減らすことができます（さらに、ハッシュは詳細の一部を抽象化し、コードを読みやすくするという付加価値を提供します）。詳細については、この記事をご覧ください。

• 該当する場合は、セットの代わりにリストを使用してください。一意性を確保したりメンバーシップを確認したりするためにセットのプロパティが必要ない場合、リストはより少ないメモリを消費し、挿入をより高速に実行します。

• ソートされたセットは、メモリ消費と基本的な操作の複雑さ（新しいメンバーのZADDなど）の両方の観点から、最もコストのかかるデータ構造です。スコアを検索する方法が必要で、順序が重要でない場合は、代わりにハッシュを使用することを検討してください。

• Redisで見落とされがちな機能は、ビットマップまたはビットセット（v2.2以降で使用可能）です。ビットセットを使用すると、Redis値に対していくつかのビットレベルの操作を実行できます。これは、大量のデータを効率的に保存することを意味します。これは、たとえば、一部の軽量分析に使用できます。

4。 SCANを使用し、KEYSは使用しないでください

SCANコマンドはRedisv2.8以降で使用可能であり、カーソルを使用してキースペース内のキーを取得できます。この動作は、一致するすべての要素を一度に返す（hiss）KEYSコマンドの動作とは異なりますが、Redisサーバーをブロックし、RAMリソースを使い果たす可能性があるため、本番環境では危険であると見なされます。一方、SCANを使用すると、サーバーをブロックしたり、スレーブに依存したりするリスクなしに、データを検査できます。

SCANでは、後続のSCANの呼び出しに渡されるカーソル値を読み取る必要があることに注意してください。 SCANは、キー名パターンとオプションのカウント引数も受け入れます。 SCANとKEYSのもう1つの違いは、SCANを使用して同じキー名を複数回取得できることです。

SCANには、SSCAN、HSCAN、およびZSCANが付属しており、セット、ハッシュ、およびソートされたセットの内容をそれぞれ繰り返すことができます。

5。サーバーサイドLuaスクリプトを使用する

開発者は、Luaスクリプトを実行するRedisの機能を採用すると、慣れ親しんだ分野をナビゲートできるようになります。習得が最も簡単な言語の1つであるLuaは、Redisサーバー自体の内部で実行されるコードを使用して創造性を表現する機能を提供します。正しく適用されると、Luaスクリプトはパフォーマンスとリソース消費の点で世界を変えることができます。スクリプトを使用すると、（アプリケーションの）CPUにデータを取り込む代わりに、データの近くでロジックを実行できるため、ネットワークの遅延とデータの冗長な送信が削減されます。

Luaの劇的な影響の典型的な例は、Redisから大量のデータをフェッチして、アプリケーションでデータをフィルタリングまたは集約する場合にのみ発生します。処理ワークフローをスクリプトにカプセル化することで、ほんのわずかな時間とリソースで非常に小さな回答を得るために、それを呼び出すだけで済みます。

上級者向けのヒント： Luaは素晴らしいですが、ワークフローをそれに移動すると、エラーの報告と処理が難しくなる場合があります（結局、Redisサーバー内で実行しています）。これを回避する賢い方法の1つは、RedisのPub / Subを使用し、スクリプトに「ログ」メッセージを専用チャネルに公開させることです。次に、これらのメッセージを取得してそれに応じて処理するサブスクライバープロセスを設定します。

Redisのエスケープ中に取得する重要なヒントは他にもたくさんありますが、このリストは、最も重要なヒントのいくつかを開始するのに役立つはずです。他に共有したい提案、フィードバック、質問がある場合は、遠慮なく私に声をかけてください。私は高可用性を備えています🙂