Detaillierte Einführung in die Redis-Komprimierungsliste (Beispielerklärung)

Der Inhalt dieses Artikels ist eine detaillierte Einführung (Beispielerklärung) zur Redis-Komprimierungsliste. Ich hoffe, dass er für Sie hilfreich ist. helfen.

In diesem Artikel wird hauptsächlich eine der Redis-Methoden zur Datenspeicherung vorgestellt: komprimierte Listen.

In diesem Artikel werden

1 Verwendungsszenarien für komprimierte Listen (Ziplist) vorgestellt

2 ?

3. Speicherformat der komprimierten Liste

4. Kettenaktualisierungsproblem

5 . Konfiguration der conf-Datei.

In der Praxis besteht der Hauptvorgang darin, die Konfigurationsdatei conf zu konfigurieren. Es gibt keinen genauen Wert, sondern eher einen Erfahrungswert. Einige Projekte verwenden direkt die ursprünglichen Standardwerte. Dieser Artikel wird hilfreich sein, um die zugrunde liegende Speicherlogik einer Datenbank besser zu verstehen. Um Energie zu erforschen und zu speichern, braucht man sowohl breites als auch profundes Wissen. Ich hoffe, dass dieser Artikel für Freunde nützlich sein wird, die ebenfalls Redis lernen. (Empfohlenes Tutorial:

Redis-Tutorial)

1. Verwendungsszenarien der komprimierten Liste (Ziplist):

Redis wird zur Optimierung der Datenspeicherung verwendet Speicher sparen: Das Optimierungsschema der Verwendung komprimierter Listen wird am Ende von Listen, Wörterbüchern (Hash-Schlüsseln) und sortierten Mengen implementiert.

Wenn beispielsweise die in einem Hash-Schlüssel gespeicherte Zeichenfolge relativ kurz ist, speichert Redis sie in einem komprimierten Listenformat, d. h. konvertiert sie zur Speicherung in ein Byte-Array. Wenn der in einem Hash-Schlüssel intern gespeicherte ganzzahlige Wert relativ klein ist, wird er auch als Knoten in der komprimierten Liste gespeichert. Ebenso ähnelt die Speicherung kleiner Datenmengen mithilfe von Listenschlüsseln der Verwendung von Hash-Schlüsseln.

Auf diese Weise ist die komprimierte Liste keine Speicherdatenstruktur in Redis, die Entwickler direkt aufrufen können, sondern eine zugrunde liegende Anstrengung in Redis,

die Datenspeicherung zu optimieren. Es ist immer noch wichtig, dies zu verstehen.

2. Wie erreicht man den Effekt der Speicherersparnis?

Komprimierte Liste ist eine serialisierte Datenstruktur. Die Funktion dieser Datenstruktur besteht darin, eine Reihe von Daten und ihre Codierungsinformationen in einem kontinuierlichen Speicherbereich zu speichern. Aber es ist logisch in Komponenten, also Knoten, unterteilt. Der Zweck besteht darin, unnötigen Speicheraufwand unter

bestimmten kontrollierbaren Zeitkomplexität-Bedingungen so weit wie möglich zu reduzieren, um den Effekt der Speichereinsparung zu erzielen. Sie müssen verstehen, wie Sie den Speicherspareffekt erzielen, und Sie müssen auch das Speicherformat der komprimierten Liste verstehen.

3. Speicherformat der komprimierten Liste:

Komprimierte Liste (Ziplist) ist Redis-Listenschlüssel, Hash-Schlüssel und geordneter Satzschlüssel Bei den zugrunde liegenden Implementierungen handelt es sich im Wesentlichen um eine

serialisierte Datenspeicherstruktur. Anders als in normalen Situationen verwendet Redis eine doppelendige verknüpfte Liste zur Darstellung einer Liste, eine Hash-Tabelle zur Darstellung eines Hash-Schlüssels und eine Hash-Tabelle + Sprungtabelle zur Darstellung einer geordneten Menge. Wenn eine Liste oder ein Hash-Wörterbuch/ein geordneter Satz nur eine kleine Menge an Inhalt enthält und jedes Listenelement oder Hash-Element/ein geordneter Satz eine kleine Ganzzahl oder eine relativ kurze Zeichenfolge ist. Dann verwendet Redis die komprimierte Liste für die zugrunde liegende Implementierung.

Die komprimierte Liste besteht aus einer Reihe von

kontinuierlichen Speicherblöcken, die speziell von Redis codiert werden. Jeder Speicherblock wird als Knoten (Eintrag) bezeichnet, und eine komprimierte Liste kann viele Knoten enthalten. Das in jedem Knoten gespeicherte Datenformat kann ein Byte-Array (chinesische Zeichenfolgen usw. werden in Byte-Arrays umgewandelt) oder ganzzahlige Werte sein.

Die Länge des Byte-Arrays kann eine der folgenden sein:

1. Die Länge ist kleiner oder gleich 63 Bytes (2 hoch 6)

2. Die Länge ist kleiner als gleich 16383 Bytes (2 hoch 14)

3. Die Länge ist kleiner oder gleich 4294967295 Bytes (2 hoch 32 hoch)

Die Ganzzahlwert kann einer der folgenden sechs Typen sein:

1. 4-Bit lange Ganzzahl ohne Vorzeichen zwischen 0-12

2. 1-Byte lange Ganzzahl mit Vorzeichen

3 . 3 Wörter, Ganzzahl vom Typ int16_t

6 Der Unterschied zwischen dem Speicherformat und dem Speicherformat für komprimierte Listen:

Die Listenspeicherstruktur ist normalerweise eine doppelendige verknüpfte Liste. Jeder Wert wird durch einen Knoten dargestellt, und jeder Knoten zeigt auf vorwärts Zeiger auf einen Knoten und den folgenden Knoten sowie einen Zeiger auf den Zeichenfolgenwert, den der Knoten enthält. Der String-Wert wird in drei Teilen gespeichert. Der erste Teil speichert die String-Länge, der zweite Teil speichert die verbleibenden verfügbaren Bytes im String-Wert und der dritte Teil speichert die String-Daten selbst. Daher muss ein Knoten häufig drei Zeiger, zwei Ganzzahlen, die String-Informationen aufzeichnen, den String selbst und ein zusätzliches Byte speichern. Der gesamte zusätzliche Overhead ist erheblich (21 Byte).

Format komprimierter Listenknoten:

Jeder Knoten besteht aus drei Teilen: vorherige_Eintragslänge, Kodierung und Inhalt. Beim Durchlaufen der Komprimierungsliste wird sie von hinten nach vorne durchlaufen.

1. previous_entry_length zeichnet die Länge des vorherigen Knotens auf. Subtrahieren Sie diesen Wert einfach vom aktuellen Zeiger, um die Startadresse des vorherigen Knotens zu erreichen.

2. Die Kodierung zeichnet den Typ und die Länge der im Knoteninhaltsattribut gespeicherten Daten auf

3. Der Inhalt zeichnet den Wert eines Knotens auf

Das Komprimieren der Liste spart natürlich viel Speicherplatz. Aber es wird auch die folgenden Probleme verursachen.

4. Probleme mit Kettenaktualisierungen:

Wenn die Gesamtlänge des vorherigen Knotens weniger als 254 Bytes beträgt, gilt im Allgemeinen die previous_entry_length Das Attribut benötigt nur 1 Byte Speicherplatz, um diesen Längenwert zu speichern. Wenn der vorherige Knoten größer als 254 Byte ist, verwendet das Attribut previous_entry_length 5 Byte Speicherplatz, um den Längenwert aufzuzeichnen.

Wenn ein neuer Knoten vor einem Knoten mit einer Länge von etwa 254 Bytes eingefügt wird, muss previous_entry_length hinzugefügt werden, um den Versatz dieses Knotens zum neuen Knoten aufzuzeichnen. Zu diesem Zeitpunkt muss die Länge dieses Knotens größer als 254 Byte sein. Daher kann der Knoten nach diesem Knoten nicht nur ein Byte von previous_entry_length zum Aufzeichnen der Informationen dieses Knotens verwenden, sondern benötigt zum Aufzeichnen 5 Bytes. Wenn die Länge mehrerer aufeinanderfolgender Knoten etwa 254 Bytes beträgt, erfolgt das Einfügen und Löschen von Knoten vor/nach einem der Knoten (die Begründung für das Löschen ist entgegengesetzt zu der für das Einfügen, und der ursprüngliche Datensatz des vorherigen Knotens mit 5 Bytes kann möglicherweise verwendet werden). wird 1 Byte) kann Kettenaktualisierungen auslösen, was sich offensichtlich sehr nachteilig auf die Betriebseffizienz des Systems auswirkt. Allerdings kommt diese Situation in der Praxis immer noch selten vor.

Die doppelendige verknüpfte Liste wird das Aktualisieren, Hinzufügen und Löschen von Knoten viel „einfacher“ machen. Weil die in jedem Knoten gespeicherten Informationen relativ unabhängig sind.

Praktische Bedeutung:

Um abzuschätzen, wie viele Bytes Speicherplatz ein Knoten belegt, passen Sie das Speicherformat des Felds entsprechend an, ohne dass der gespeicherte Feldwert weniger als 254 Wörter einnimmt (minus). das Codierungsattribut und das previous_entry_length-Attribut) oder so.

Verwandte Befehle zum Anzeigen der Länge von Zeichenfolgen- und Hash-Schlüsselwerten in Redis:

1. Fragen Sie die Länge des entsprechenden Werts ab zur Zeichenfolgentaste

Befehl:

Strlen

Zum Beispiel:

127.0.0.1:6379> strlen m_name

(integer ) 8

2. Fragen Sie die Länge eines bestimmten Feldes des Hash-Schlüssels ab

Befehl:

Hstrlen

Zum Beispiel:

127.0.0.1:6379> hstrlen good_list good_list1

(integer) 226

5. Conf Dateikonfiguration:

Durch Ändern der Konfigurationsdatei können Sie steuern, ob eine komprimierte Liste verwendet, um die maximale Anzahl von Elementen und die Größe des maximalen Elements

Conf-Dateikonfiguration:

1.

[] -max-ziplist-entries: Gibt die maximale Anzahl von Elementen des Schlüssels an, d. h. die Anzahl der Knoten unter dem angegebenen Wert in a Der Schlüssel wird in einer komprimierten Liste gespeichert

[] -max-ziplist-value: Gibt die maximale Größe jedes Knotens in der komprimierten Liste in Bytes an

Bei der tatsächlichen Verwendung ein bestimmtes Element von Ein Listenschlüssel/Hash-Schlüssel speichert oft eine relativ große Informationsmenge, die größer als 64 Byte ist, daher ist es wahrscheinlich, dass sie während der Konfiguration größer als 64 ist. Gleichzeitig wird die tatsächliche Speicherkapazität der Daten berücksichtigt Die oben erwähnte Größe der vorherigen_Eintragslänge, [] -max-ziplist-value, sollte angemessen konfiguriert sein.

Inhalt der Konfigurationsdatei:

############## 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

Fall:

Verwenden Sie die Standardkonfiguration, bevor Sie die Konfiguration ändern:

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> object Kodierung good_list

"hashtable"

Konfiguration ändern:

hash-max-ziplist-entries 512

hash-max-ziplist-value 254

Hinweis: Sie müssen den Server neu starten, nachdem Sie die Konfiguration geändert haben

127.0.0.1:6379> hstrlen good_list good_list1

(integer) 226

127.0.0.1 :6379> Objektkodierung good_list

"ziplist"

Sie können sehen, dass die Speichermethode in ziplist geändert wurde

Weitere offizielle Drucktests und Anleitungsvorschläge:

Wenn die Anzahl der Elemente einer komprimierten Liste auf mehrere Tausend ansteigt (die tatsächliche Nutzung kann weit unter diesem Wert liegen), verringert sich die Leistung der Die komprimierte Liste kann kleiner werden, da Redis dies betreibt. Bei Verwendung dieser Struktur besteht ein gewisser Druck auf die Kodierung und Dekodierung.

Die Länge der komprimierten Liste ist auf 500-2000 begrenzt, und die Größe jedes Elements ist auf 128 Byte oder weniger begrenzt. Die Leistung der komprimierten Liste liegt in einem angemessenen Bereich.

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung in die Redis-Komprimierungsliste (Beispielerklärung). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!