Redis はどのような場合にハッシュ タイプを使用しますか?

ハッシュ タイプは、文字列タイプまたは文字列コレクションのフィールドと値のマッピング テーブルです。オブジェクトの保存に特に適しています。比較して、オブジェクト タイプをハッシュに保存するのは、 type String 型クラスに格納する場合に比べて、メモリ占有量が少なく、オブジェクト全体へのアクセスが容易になります。

Redis では、ハッシュ タイプは、次の形式のキーと値のペア構造であるキー値自体を指します: value={{field1,value1},{field2,value2},{fieldN,valueN }} ,

一般的に使用されるコマンド:

hget、hset、hgetall など。

アプリケーション シナリオ:

Hash のアプリケーション シナリオを説明するための簡単な例を示します。たとえば、次の情報を含むユーザー情報オブジェクト データを保存したいとします。 ##ユーザー ID を検索キーとして、

に格納される値ユーザー オブジェクトには、名前、年齢、誕生日などの情報が含まれます。

通常のキー/値構造を使用して保存する場合、主に 2 つの保存方法があります。

最初の方法は、ユーザー ID を検索キーとして使用し、他の情報をオブジェクトにカプセル化します。シリアル化された方法で保存されます。

例: set u001 "李三,18,20010101"

このメソッドの欠点は、シリアル化/逆シリアル化のオーバーヘッドが増加することです。情報の 1 つを変更する必要があり、オブジェクト全体を取得する必要があり、変更操作では同時実行性を保護する必要があるため、CAS などの複雑な問題が発生します。

2 番目の方法は、ユーザー情報オブジェクトのメンバーの数と同じ数のキーと値のペアを格納し、ユーザー ID に対応する属性の名前を一意の識別子として使用して、その値を取得する方法です。対応する属性、例: mset user: 001:name "李三 "user:001:age18 user:001:birthday "20010101"

シリアル化のオーバーヘッドと同時実行の問題は解消されますが、ユーザー ID は繰り返し保存されます。このようなデータが大量にある場合でも、メモリの浪費はかなりの量になります。

Redis が提供するハッシュは、この問題を非常にうまく解決します。Redis のハッシュは実際に値を HashMap として内部に保存し、このマップのメンバーに直接アクセスするためのインターフェイスを提供します。

例: hmset user:001 name "李三" 年齢 18 誕生日 "20010101"

つまり、キーは依然としてユーザー ID であり、値は Map であり、このマップのキーはメンバーです。属性名、値は属性値です。そのため、データの変更とアクセスは、内部マップのキーを介して直接行うことができます (内部マップのキーは、Redis ではフィールドと呼ばれます)。 、つまり、キー（ユーザー ID）フィールド（属性ラベル））を介して、対応する属性データを操作するため、データを繰り返し格納する必要がなく、シリアル化および同時変更制御に問題が発生しません。問題を非常にうまく解決しました。ここで注意すべき点は、Redis はすべての属性データを直接取得するためのインターフェイス (hgetall) を提供していますが、内部 Map のメンバーが多数ある場合、内部 Map 全体を横断する操作が必要になります。 Redis のモデルでは、このトラバーサル操作には時間がかかる可能性があり、他のクライアントのリクエストはまったく応答しなくなるため、特別な注意が必要です。

実装方法: 前述のように、Value に対応する Redis ハッシュは実際には HashMap です。実際には 2 つの異なる実装があります。ハッシュのメンバーが少ない場合、Redis は 1 次元配列を使用します。メモリを節約するため、コンパクトに格納するため、実際の HashMap 構造を使用する代わりに、対応する値 redisObject のエンコードは zipmap になり、メンバーの数が増えると自動的に実際の HashMap に変換され、エンコードは ht になります。

Redis 関連の知識の詳細については、

Redis 使用法チュートリアル

列をご覧ください。

以上がRedis はどのような場合にハッシュ タイプを使用しますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。