Redis圧縮リストの詳しい紹介（サンプル解説）

この記事では、Redis 圧縮リストについて詳しく説明します。必要な方は参考にしてください。

この記事では、Redis のデータ保存方法の一つである圧縮リストを中心に紹介します。

この記事では、

1 および 圧縮リスト (ziplist) の使用シナリオ

2 を紹介します。 ?

3. 圧縮リストの保存形式

4. チェーン更新の問題

5 。 conf ファイルの設定。

実際には、主な操作は conf 構成ファイルを構成することです。正確な値はありませんが、経験的な値です。一部のプロジェクトは、元のデフォルト値を直接使用します。この記事は、データベースの基礎となるストレージ ロジックをより深く理解するのに役立ちます。エネルギーを研究し、蓄えるには、幅広い知識と深い知識の両方が必要です。この記事が、同じく Redis を学習している友人にとって役立つことを願っています。 (推奨チュートリアル: Redis チュートリアル )

1. 圧縮リスト (ziplist) の使用シナリオ:

Redis は、データ ストレージとストレージを最適化するために使用されます。メモリの節約、圧縮リストを使用する最適化スキームは、リスト、辞書 (ハッシュ キー)、およびソート セットの最後に実装されます。

たとえば、ハッシュ キーに格納されている文字列が比較的短い場合、Redis はそれを圧縮リスト形式で格納します。つまり、格納するためにバイト配列に変換します。ハッシュ キーに内部的に格納されている整数値が比較的小さい場合は、圧縮リスト内のノードとしても格納されます。同様に、リストキーによる小さなデータの保存は、ハッシュキーの操作に似ています。

このように、圧縮リストは、開発者が直接呼び出すことができる Redis のストレージ データ構造ではなく、 データ ストレージを最適化するための Redis の基礎的な取り組み です。これを理解することが依然として重要です。

2. メモリを節約する効果を実現するにはどうすればよいですか?

圧縮リストはシリアル化されたデータ構造であり、このデータ構造の機能は、連続したメモリ領域に一連のデータとそのエンコード情報を格納することです。ただし、論理的にはコンポーネント、つまりノードに分割されます。目的は、特定の制御可能な時間計算量条件下で不必要なメモリのオーバーヘッドを可能な限り削減し、メモリを節約する効果を達成することです。メモリを節約する効果を実現する方法を理解する必要があり、圧縮リストの保存形式も理解する必要があります。

3. 圧縮リストの保存形式:

圧縮リスト(ziplist)はRedisのリストキー、ハッシュキー、オーダードセットキーのいずれかです。基礎となる実装、その本質は シリアル化された データ ストレージ構造です。通常の状況とは異なり、Redis はリストを表すために両端リンク リストを使用し、ハッシュ キーを表すためにハッシュ テーブルを使用し、順序付きセットを表すためにハッシュ テーブルとジャンプ リストを使用します。リストまたはハッシュ ディクショナリ/順序付きセットに含まれるコンテンツの量が少なく、各リスト項目またはハッシュ項目/順序付きセット項目が小さい整数または比較的短い文字列である場合。その後、Redis は基になる実装に圧縮リストを使用します。

圧縮リストは、Redis によって特別にエンコードされた一連の 連続メモリ ブロック で構成され、各メモリ ブロックはノード (エントリ) と呼ばれ、圧縮リストには多数のノードを含めることができます。各ノードに格納されるデータ形式は、バイト配列 (中国語の文字列などはバイト配列に変換されます) または整数値のいずれかになります。

バイト配列の長さは次のいずれかです:

1. 長さは 63 バイト (2 の 6 乗) 以下です。 2. 長さは 16383 バイト (2 の 14 乗)

3 未満です。長さは 4294967295 バイト (2 の 32 乗) 以下です。整数値は、次の 6 つのタイプのいずれかになります。

1. 0 ～ 12 の 4 ビット長の符号なし整数。

##2。 3 ワード セクション長 符号付き整数

4. int16_t 型 integer

6. int64_t 型 integer

格納形式と圧縮リスト格納形式の違い:

リスト格納構造は通常、両端のリンク リストであり、各値はノードによって表され、各ノードは前の値を指します。 1 つのノードと次のノードへのポインタ、およびノー​​ドに含まれる文字列値へのポインタ。文字列値は 3 つの部分に格納されます。最初の部分には文字列の長さが格納され、2 番目の部分には文字列値内の残りの使用可能なバイトが格納され、3 番目の部分には文字列データ自体が格納されます。したがって、ノードは多くの場合、3 つのポインター、文字列情報を記録する 2 つの整数、文字列自体、および追加のバイトを保存する必要があります。全体的な追加オーバーヘッドはかなり大きくなります (21 バイト)。

圧縮リスト ノードの形式:

各ノードは、previous_entry_length、エンコーディング、およびコンテンツの 3 つの部分で構成されます。圧縮リストを走査する場合、後ろから前に走査されます。

1.previous_entry_length は、前のノードの長さを記録します。現在のポインタからこの値を減算するだけで、前のノードの開始アドレスに到達します。

2. エンコーディングは、ノードのコンテンツ属性に格納されるデータのタイプと長さを記録します。

3. コンテンツは、ノードの値を記録します。 # #リストを圧縮すると、明らかにストレージ スペースが大幅に節約されます。しかし、次のような問題も発生します。

4. チェーン更新の問題: 一般的に、前のノードの全体の長さが 254 バイト未満の場合、previous_entry_length属性には、この長さの値を格納するために 1 バイトのスペースのみが必要です。前のノードが 254 バイトより大きい場合、previous_entry_length 属性は長さの値を記録するために 5 バイトのスペースを使用します。

新しいノードが約 254 バイトの長さのノードの前に挿入される場合、previous_entry_length を追加して、このノードから新しいノードへのオフセットを記録する必要があります。現時点では、このノードの長さは 254 バイトより大きくなければなりません。したがって、このノードの後のノードは、このノードの情報を記録するためにprevious_entry_lengthの1バイトしか使用できず、記録するために5バイトを必要とする。連続する複数のノードの長さが約 254 バイトの場合、ノードの挿入と削除はいずれかのノードの前後で行われます (削除の理由は挿入の理由と逆であり、前のノードの元のレコードは 5 バイトである可能性があります)。 1 バイトになる）、チェーン更新がトリガーされる可能性があることは、明らかに、システムの動作効率に非常に悪影響を及ぼします。ただし、この状況は実際のアプリケーションではまだほとんど発生しません。

両端リンク リストを使用すると、ノードの更新、追加、削除がはるかに「簡単」になります。各ノードに保存されている情報は比較的独立しているためです。

実際的な重要性:

ノードが占める記憶領域のバイト数を見積もるには、格納されたフィールド値が占有する記憶領域が 254 ワード未満にならないように、フィールドの記憶形式を適切に調整します。セクション（エンコード属性とprevious_entry_length属性を除く）程度。

Redis

の文字列とハッシュ キーの値の長さを表示する関連コマンド: 1 に対応する値の長さをクエリします。文字列 key

コマンド:

Strlen

例:

127.0.0.1:6379> strlen m_name

(integer; ) 8

2. ハッシュ キーの特定のフィールドの長さをクエリします。

コマンド:

Hstrlen

例:

127.0.0.1:6379> hstrlen Good_list Good_list1

(整数) 226

ファイル構成: 構成ファイルを変更することで、 圧縮リストを使用して 要素の最大数と関連キーの最大要素のサイズを格納するかどうかを制御できます

Conf ファイルの構成: 1.[] -max-ziplist-entries: キーの要素の最大数、つまり、キーで指定された値の下にあるノードは圧縮リストに格納されます

[] -max-ziplist-value: 圧縮リスト内の各ノードの最大サイズをバイト単位で示します

In実際の使用では、リスト キー/ハッシュ キーの特定の要素には比較的大きな情報量が格納されることが多く、そのため、構成時に 64 バイトを超える可能性があります。データの実際のストレージ容量と上記のprevious_entry_lengthのサイズを考慮して、[] -max-ziplist-valueを適切に調整する必要があります。

構成ファイルの内容:

############## ADVANCED CONFIG ##########################
哈希键
# Hashes are encoded using a memory efficient data structure when they have a
# small number of entries, and the biggest entry does not exceed a given
# threshold. These thresholds can be configured using the following directives.
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

有序集合键
# Similarly to hashes and lists, sorted sets are also specially encoded in
# order to save a lot of space. This encoding is only used when the length and
# elements of a sorted set are below the following limits:
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

列表键，比较特殊，直接使用制定大小kb字节数表示（有些conf文件的列表键与hash键的表达式没太大区别）
# Lists are also encoded in a special way to save a lot of space.
# The number of entries allowed per internal list node can be specified
# as a fixed maximum size or a maximum number of elements.
# For a fixed maximum size, use -5 through -1, meaning:
# -5: max size: 64 Kb  <-- not recommended for normal workloads
# -4: max size: 32 Kb  <-- not recommended
# -3: max size: 16 Kb  <-- probably not recommended
# -2: max size: 8 Kb   <-- good
# -1: max size: 4 Kb   <-- good
# Positive numbers mean store up to _exactly_ that number of elements
# per list node.
# The highest performing option is usually -2 (8 Kb size) or -1 (4 Kb size),
# but if your use case is unique, adjust the settings as necessary.
list-max-ziplist-size -2

ケース:

構成を変更する前にデフォルト構成を使用してください:

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

127.0.0.1:6379> hstrlen Good_list Good_list1

(integer) 226

127.0.0.1:6379>エンコーディング Good_list

"hashtable"

構成の変更:

hash-max-ziplist-entries 512

hash-max-ziplist-value 254

注: 構成を変更した後はサーバーを再起動する必要があります

127.0.0.1:6379> hstrlen good_list good_list1

(integer) 226

127.0.0.1 :6379>オブジェクトエンコーディングgood_list

"ziplist"

保存方法がziplist

#に変更されていることがわかります。 #その他の公的圧力 テストとガイダンスの提案:

圧縮リスト内の要素の数が数千に増加すると (実際の使用量はこの値よりはるかに少ない可能性があります)、 Redis がこれを操作するため、圧縮リストが減少する可能性があります。この構造を使用すると、エンコードとデコードにある程度の負荷がかかります。

圧縮リストの長さは 500 ～ 2000 に制限され、各要素のサイズは 128 バイト以下に制限されます。圧縮リストのパフォーマンスは妥当な範囲内になります。

以上がRedis圧縮リストの詳しい紹介（サンプル解説）の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。