1、文字列：生、int型、embstr
2、ハッシュ：ハッシュテーブル、ziplist
3：リスト：LinkedListの、ziplist
4：セット：ハッシュテーブル、INTSET
5：ZSET：skiplist、ziplist
デザインの利点：
1：内部および外部のデータ構造を改善することができコーディングとコマンドは効果がありません
2：内部コーディングのさまざまなインプリメンテーションは、メモリを節約するために、よりziplistなど、さまざまなシナリオで自分の強みに再生することができますが、パフォーマンスは長い間、リストの要素をドロップします、そしてRedisのは、メモリのLinkedListのタイプの設定オプションの変換リストに基づいて実装されます
ストリング
この構造は、文字列を格納し（「シンプル動的ストリング」）SDSを使用してのRedis、
1：コードは、5つのSDS構造を定義します。
1：構造体__attribute __（（__packed__））sdshdr5 {unsigned char型フラグ。チャーBUF []。}。
2：sdshdr8
3：sdshdr16
4：sdshdr32
5：sdshdr64
2：フィールドでの主な機能：
LEN：文字列の長さ（長さは、実際に使用）
ALLOC：メモリサイズを割り当てます
フラグ：フラグ、下位3種類、残りの5つの未使用を表します。
BUF：文字列
3：コーディング
INTコード：保存long型64ビット符号付き整数、RedisのキーはOBJ_ENCODING_INTに対応するタイプコード、長い貯蔵型に変換します
長以下の文字列を保存するために44バイト（OBJ_ENCODING_EMBSTR）より：エンコードembstr
生コード：44バイト（OBJ_ENCODING_RAW）よりも長さ以上の文字列を保存します
ziplist
1：ziplist構造
zlbytes：バイト数が使用時に行わziplist、サイズ変更操作を占有示し
zltail：最後のノードのオフセットを表し、だけでなく、リスト全体を横断避けるために、
zllen：ziplistは（65,535以上のノード、zllen無効なフィールド値、実数を取得するためにトラバースする必要がある）、ノードの数を表し、
zlend：ziplist表す識別子エンド
2：ziplistノード・データ構造（要約）
3つの成分のprevious_entry_length、エンコーディング、コンテンツ（フィールドは、実際の構造を参照していない）により、各圧縮ノードリスト
previous_entry_length：前のノードの長さは、前のノードの長さに応じて、後により前方横断、又は5つのバイトを必要とするかもしれないため。
エンコーディング：ノードデータレコードは、タイプ及びデータ長を記憶します。
コンテンツ：ノードに格納されたデータの内容。
ziplistデータを格納するメモリの連続使用期間を、メモリフラグメンテーションを比較ハッシュテーブル、およびポインタメモリフットプリントを低減します。ノードが少ないときや、CPUのキャッシュにロードされる可能性が高いziplist。
3：ziplist利点
CPUのキャッシュにロードされるメモリフットプリントにくいです
コンパクトは、メモリの断片化を減らします
4：ziplist欠点
チェーンのアップデート（主に頭の上にヘッド挿入または削除操作ziplistと透過型のオブジェクトのリストを保存するときに、オブジェクトが保存されたハッシュヘッドを更新する必要はありません。）
各挿入または変更操作開始のreallocはそれによって性能が低下、メモリコピーを引き起こす大きな確率を有します。
大きなデータをコピーするためのメモリコピーのコストと、上昇を対応するメモリコピーが発生します。
ときziplist ziplist必要性に関する検索が横断したので、非常に低くなり、特定のパフォーマンスデータ項目を見つけるために、それにあまりにも多くのデータ項目。
クエリの複雑さはO（1）O（N）（オブジェクトが格納されているハッシュ）となるから、
5：ziplist設定
redis.conf設定：
ハッシュ-MAX-ziplist-エントリ512
ハッシュ-MAX-ziplist値64
ハッシュのハッシュ-MAX-ziplist・エントリ設定（デフォルト512）よりも小さい要素の種類の数、すべての値がハッシュMAX-ziplist値設定（デフォルト64バイト）している間は、いつ、ハッシュziplistはRedisのに使用したように内部実装、連続する複数の要素を達成するために、よりコンパクトな保管のziplist使用、ハッシュテーブルよりメモリを節約する点でその結果、より優れました。
この設計のためのハッシュ理由のRedisのはziplistが大きくなるとき、それは次のような欠点を持っているということです。
船のリスト
1：skipListジャンプテーブル
skipList多層チェーン・モデル、ノードは、単一または複数のノードの後にレコードポインタ向い層の乱数（レベル）を割り当てるだけ多くのノードを必要とせず、挿入ノードの前と後の操作インサートポインタを変更する必要が調整。時間計算量はO（logN個）の平均O（N）の、最悪の場合の複雑さ、性能一般匹敵バランスのとれたツリーを低減します。
2：確率
生成するノードの層より多数の、より低い確率。以下のように定量分析は、次のとおりです。
少なくとも一つのノードの層の数。ノード1は、層の数が確率分布を満たすよりも大きいです。
ノード層は、正確に等しい確率1-Pです。
2以上のpに等しい層のノード数の確率は、層とノード2の数は、正確確率P（1-P）に等しいです。
層の数が3がP2に等しいノードの確率よりも大きい、層の数及びノード3は、確率P2（1-P）と正確に同じです。
ノード層4以上確率P3に等しい、及びP3（1-P）の層4の正確数のノード確率。
3：skiplistの比較とバランス木、ハッシュテーブル
- そして、様々なskiplistバランスツリー（例えば、AVL、赤黒木、等）要素が順序付けされ、ハッシュテーブルは順序付けられていません。したがって、ハッシュテーブルは、単一キーのルックアップ、および範囲検索に適さない操作を行うことができます。指定された2つの値の間の大きさのすべてのノードを見つける人々を参照して、検索の範囲、いわゆる。
- 範囲をする時間を見つけ、バランスツリーの動作は、より多くのskiplistよりも複雑です。木のバランスを取るの後、私たちは、指定された範囲の小さな値が、他のノードが大きな値を超えない求め続けないトラバースするために順序を見つけます。あなたは木に行きがけを達成するのは容易ではない、特定の変換を、バランスしていない場合。そして、ちょうど小さな値を求めた後、いくつかの段階を通過する第一の層のリストを達成することができ、skiplist上の範囲を見つけることは非常に簡単です。
- バランスのとれたツリーの挿入および削除操作は、サブツリー・ロジックの複雑さ調整につながる可能性があり、そしてskiplist挿入および欠失は、ポインタ隣接ノード、簡単かつ迅速に変更する必要があります。
- メモリフットプリントからは、バランスの取れた木のいくつかのより柔軟skiplist。ポインタの数はパラメータpの大きさに応じて、各ノードが1 /（1-P）の平均値が含まskiplistながら一般的に、各ノードは、バランスのとれたツリー2ポインタ（それぞれ、左及び右サブツリーを指す）を含みます。同一の実現にRedisのように、P = 1/4を取る場合、各ノードは1.33ポインタ、利点よりバランスのとれたツリーの平均を含んでいます。
- ハッシュの衝突の確率が低い値を維持しながら、近い時間複雑さOを見つけるために、（1）ハッシュテーブル、単一のキー、skiplistを見つけ、バランス木はおおよそO（対数N）の時間複雑ですパフォーマンスが高いです。私たちが通常使用するので、様々な地図や辞書構造、主にハッシュテーブルに基づく実装。
- バランスの取れた木よりもはるかに簡単なアルゴリズム実装の難易度、skiplistからアップ比較。
