Breeze II: ハッシュとは? オブジェクトを使用して redis によって返された値を受け取ることが推奨されないのはなぜですか?

1 ハッシュとは

1.1 問題の生成

問題が発生: Redis を学習すると、redis の値のデータ型にハッシュ型があるので、ハッシュとは何ですか?

ここに画像の説明を挿入

1.2 問題分析

昔のデータ構造コースの私の記憶によると、ハッシュはキーと値の形式に相当するデータ構造です。

1.3 問題解決

1.3.1 キーコード (key) 値 (value)

ハッシュ表

  • ハッシュテーブル(ハッシュテーブル、ハッシュテーブルとも呼ばれる)は、关键码值(Key value)直接アクセスに基づくデータ構造です。
  • レコードにアクセスして关键码值映射到表中一个位置検索を高速化する。これ映射函数を と呼び、レコード散列函数格納する配列をハッシュテーブルと呼びます。
    ここに画像の説明を挿入

1.3.2 基礎となる配列の実装

  • ハッシュ テーブルの基になるレイヤーは、配列を介して実装されます。
  • 配列の特徴の 1 つは、初期化時に長さを指定する必要があることです。
    したがって、Hash テーブルのデータがいっぱいになったときに、引き続きデータを入れたい場合は、容量の大きい配列を作成してから、以前の配列のデータを新しい配列にコピーする必要があります。この処理はパフォーマンスを消費するため、ハッシュテーブルを使用する前にデータ容量を見積もり、拡張操作を避けるようにする必要があります。

1.3.3 ハッシュ テーブルの問題: ハッシュの競合が解決される

データはキー コード (キー) 値 (値) マッピング テーブル内の位置を介してアクセスされるため、このマッピング関係 (ハッシュ関数) は同じ結果を取得する可能性があり、ハッシュの競合が発生し、この競合は避けられません
ここに画像の説明を挿入

ハッシュ競合の解決策:オープン アドレス メソッドジッパー メソッド

1.3.3.1 競合の解決 - ジッパー方式

核となるアイデアは次のとおりです。ハッシュ競合がハッシュ テーブルの特定の位置で発生した場合 (つまり、挿入する要素が配列の特定の位置に配置された場合、この位置には既に要素が存在します)、格納します。リンクされたリストの形式でこれらの要素。

次に、これが問題を引き起こします。ハッシュ テーブルの特定の位置にハッシュの競合が多すぎると、非常に長いリンク リストが形成され、最終的にクエリのパフォーマンスに影響を与えます。

JDK8 では、上記の問題に対処するために最適化が行われました。赤黒い木、つまり、連結リストの長さが 8 に達すると、連結リストは自動的に赤黒木に変換され、クエリ効率が高くなります (赤黒木は自己平衡二分探索木です)

1.3.3.2 競合の解決 — オープンアドレス方式

核となるアイデア: メソッド ハッシュが競合する場合、保存する別の場所を見つける必要があります。

オープン アドレス方式で他の場所を見つけるには、線形検出、二次検出、再ハッシュの 3 つの方法があります。

線形検出方法:最初にマッピングする位置を判断し、この位置に要素がない場合はこの位置にマッピングし、要素がある場合はこの位置の次の位置に追加し、ある場合は続けますマッピングが成功するまで次の位置。

1.4 参考文献

データ構造:ハッシュテーブル
詳細ハッシュデータ構造、手書きハッシュテーブル

2 オブジェクトを使用して redis で戻り値を受け取ることが推奨されない理由

2.1 問題紹介

Java コードを使用してデータを追加し、Redis で操作を読み書きする練習をします。読み書きの過程では、デフォルトで使用されているとString类型接收返回的value值思います。Redis中数据都是以字符串(string)类型存储Object作为基本数据类型的父类
ここに画像の説明を挿入

2.2 問題分析

Object 型を使用して Redis で値を受け取ることができるためです。強制的に String 型を使用して戻り値を受け取る必要があるのはなぜですか? ( Redis中数据都是以字符串(string)类型存储?)、オブジェクト型はすべての基本型の親クラスであり、もちろん多くのメモリを消費します。Redis が高速に読み取る理由の 1 つは次のとおりです。其每种数据结构都是经过专门设计的,并都有一种或多种数据结构来支持

2.3 問題解決

redis の高性能の理由の 1 つは、它每种数据结构都是经过专门设计、および都有一种或多种数据结构来支持、このように提升读取、写入的性能.

如果使用Object类型接收

  • これは Redis の読み取りパフォーマンスに影響を与え、システム操作の後期段階でもサーバー メモリがいっぱいになります。これは、大きなデータ型が小さなデータ型を受信するために使用されているためです。要するに、小さなデータを使用するのが合理的です。タイプであり、常に正しいです。
  • もう1つのポイントは、オブジェクトを使用して戻り値を受け取ることです。これにより、文字列のような関連メソッドを使用できなくなります。
タイプ 占有バイト
物体 16または24
8または16

2.4 参考文献

redis学習スキルのオブジェクトの詳細な説明で、
HashMapのキーとしてカスタムオブジェクトを使用することが推奨されていないのはなぜですか?
インタビュアーはいじめられました: new Object() は何バイトを占めますか?

おすすめ

転載: blog.csdn.net/stange1/article/details/129473854