Introduction détaillée à la liste de compression Redis (exemple d'explication)

Le contenu de cet article est une introduction détaillée (exemple d'explication) sur la liste de compression Redis. Il a une certaine valeur de référence. J'espère qu'il vous sera utile. aide.

Cet article présente principalement l'une des méthodes de stockage de données de Redis, les listes compressées.

Cet article présentera

1. Scénarios d'utilisation de liste compressée (ziplist)

2. ?

3. Format de stockage de la liste compressée

4. Problème de mise à jour de la chaîne

5 . configuration du fichier de configuration.

En pratique, l'opération principale est de configurer le fichier de configuration de conf. Il n'y a pas de valeur exacte, mais plutôt une valeur empirique. Certains projets utiliseront directement les valeurs par défaut d'origine. Cet article sera utile pour mieux comprendre la logique de stockage sous-jacente d'une base de données. Pour étudier et stocker l’énergie, vous avez besoin à la fois de connaissances étendues et de connaissances approfondies. J'espère que cet article sera utile aux amis qui apprennent également Redis. (Tutoriel recommandé : Tutoriel Redis)

1. Scénarios d'utilisation de la liste compressée (ziplist) :

Redis est utilisé pour optimiser le stockage des données et économiser de la mémoire , le schéma d'optimisation de l'utilisation de listes compressées est implémenté au bas des listes, des dictionnaires (clés de hachage) et des ensembles triés.

Par exemple, si la chaîne stockée dans une clé de hachage est relativement courte, Redis la stockera dans un format de liste compressée, c'est-à-dire la convertira en un tableau d'octets pour le stockage. Si la valeur entière stockée en interne dans une clé de hachage est relativement petite, elle sera également stockée en tant que nœud dans la liste compressée. De la même manière, le stockage de petites données par clés de liste est similaire au fonctionnement des clés de hachage.

De cette façon, la liste compressée n'est pas une structure de données de stockage dans Redis que les développeurs peuvent appeler directement, mais un effort sous-jacent dans Redis pour optimiser le stockage des données . Il est quand même important de comprendre cela.

2. Comment obtenir l'effet d'économie de mémoire ?

La liste compressée est une structure de données sérialisée. La fonction de cette structure de données est de stocker une série de données et ses informations de codage dans une zone de mémoire continue. Mais il est logiquement divisé en composants, c'est-à-dire en nœuds. L'objectif est de réduire autant que possible la surcharge de mémoire inutile dans certaines complexités temporelles contrôlables, afin d'obtenir l'effet d'économiser de la mémoire. Vous devez comprendre comment obtenir l'effet d'économie de mémoire, et vous devez également comprendre le format de stockage de la liste compressée.

3. Format de stockage de la liste compressée :

La liste compressée (ziplist) est la clé de liste Redis, la clé de hachage et la clé d'ensemble ordonnée. les implémentations sous-jacentes, son essence est une structure de stockage de données sérialisée. Différent des situations ordinaires, Redis utilise une liste chaînée à double extrémité pour représenter une liste, une table de hachage pour représenter une clé de hachage et une table de hachage + table de saut pour représenter un ensemble ordonné. Lorsqu'une liste ou un dictionnaire de hachage/un ensemble ordonné ne contient qu'une petite quantité de contenu et que chaque élément de liste ou élément de hachage/élément d'ensemble ordonné est un petit entier ou une chaîne relativement courte. Ensuite, Redis utilisera la liste compressée pour l'implémentation sous-jacente.

La liste compressée se compose d'une série de blocs de mémoire continus spécialement codés par Redis. Chaque bloc de mémoire est appelé un nœud (entrée), et une liste compressée peut contenir de nombreux nœuds. Le format de données stocké dans chaque nœud peut être un tableau d'octets (les chaînes chinoises, etc. seront converties en tableaux d'octets) ou des valeurs entières.

La longueur du tableau d'octets peut être l'une des suivantes :

1. La longueur est inférieure ou égale à 63 octets (2 à la puissance 6)

2. La longueur est inférieure à Égale à 16383 octets (2 à la puissance 14)

3. La longueur est inférieure ou égale à 4294967295 octets (2 à la puissance 32)

Le la valeur entière peut être l'un des six types suivants :

1. Entier non signé de 4 bits compris entre 0 et 12

2. Entier signé de 1 octet

3. . 3 mots de longueur de section signé

4. int16_t type entier

5. int32_type entier

6. La différence entre le format de stockage et le format de stockage de liste compressée :

La structure de stockage de liste est généralement une liste chaînée à double extrémité. Chaque valeur est représentée par un nœud, et chaque nœud pointe vers le. forward Pointeurs vers un nœud et le nœud suivant, ainsi qu'un pointeur vers la valeur de chaîne que le nœud contient. La valeur de chaîne est stockée en trois parties. La première partie stocke la longueur de la chaîne, la deuxième partie stocke les octets disponibles restants dans la valeur de chaîne et la troisième partie stocke les données de chaîne elles-mêmes. Par conséquent, un nœud doit souvent stocker 3 pointeurs, 2 entiers enregistrant les informations de chaîne, la chaîne elle-même et un octet supplémentaire. La surcharge globale supplémentaire est importante (21 octets).

Format des nœuds de liste compressés :

Chaque nœud se compose de trois parties : previous_entry_length, encoding et content Lors du parcours de la liste de compression, elle est parcourue de l'arrière vers l'avant.

1. previous_entry_length enregistre la longueur du nœud précédent. Soustrayez simplement cette valeur du pointeur actuel pour atteindre l'adresse de départ du nœud précédent.

2. L'encodage enregistre le type et la longueur des données stockées dans l'attribut de contenu du nœud

3. 🎜 >Évidemment, compresser la liste permet d'économiser beaucoup d'espace de stockage. Mais cela entraînera également les problèmes suivants.

4. Problèmes avec les mises à jour de chaîne : De manière générale, si la longueur totale du nœud précédent est inférieure à 254 octets, la longueur_entrée_précédente est inférieure à 254 octets. L'attribut n'a besoin que de 1 octet d'espace pour stocker cette valeur de longueur. Lorsque le nœud précédent fait plus de 254 octets, l'attribut previous_entry_length utilise 5 octets d'espace pour enregistrer la valeur de longueur.

Lorsqu'un nouveau nœud est inséré avant un nœud d'une longueur d'environ 254 octets, previous_entry_length doit être ajouté pour enregistrer le décalage de ce nœud par rapport au nouveau nœud. A ce moment, la longueur de ce nœud doit être supérieure à 254 octets. Par conséquent, le nœud après ce nœud ne peut pas utiliser seulement un octet de previous_entry_length pour enregistrer les informations de ce nœud, mais nécessite 5 octets pour enregistrer. Si la longueur de plusieurs nœuds consécutifs est d'environ 254 octets, l'insertion et la suppression des nœuds se produisent avant/après l'un des nœuds (le raisonnement de la suppression est opposé à celui de l'insertion, et l'enregistrement original du nœud précédent avec 5 octets peut devenir 1 octet), peut déclencher des mises à jour en chaîne, cela est évidemment très préjudiciable à l'efficacité opérationnelle du système. Cependant, cette situation se produit encore rarement dans les applications pratiques.

La liste chaînée à double extrémité sera beaucoup "plus facile" dans la mise à jour, l'ajout et la suppression de nœuds. Parce que les informations stockées dans chaque nœud sont relativement indépendantes.

Importance pratique :

Pour estimer le nombre d'octets d'espace de stockage qu'un nœud occupe, ajustez le format de stockage du champ de manière appropriée sans que la valeur du champ stocké occupe moins de 254 mots (moins. l'attribut encoding et l'attribut previous_entry_length) ou plus.

Commandes associées pour afficher la longueur des valeurs de chaîne et de clé de hachage dans Redis

 : Interroger la longueur de la valeur correspondante. à la clé de chaîne

Commande :

Strlen

Par exemple :

127.0.0.1:6379> strlen m_name

(entier ) 8

2. Interroger la longueur d'un certain champ de la clé de hachage

Commande :

Hstrlen

Par exemple :

127.0.0.1:6379> hstrlen good_list good_list1

(entier) 226

5. Conf configuration du fichier : en modifiant le fichier de configuration, vous pouvez contrôler si

utilise une

liste compressée pour stocker le nombre maximum d'éléments et la taille de l'élément maximum Configuration du fichier Conf :

1.

[] -max-ziplist-entries : Indique que le nombre maximum d'éléments de la clé, c'est-à-dire le nombre de nœuds sous la valeur spécifiée dans un la clé sera stockée dans une liste compressée

[] -max-ziplist-value : Indique la taille maximale de chaque nœud dans la liste compressée en octets

En utilisation réelle, un certain élément de une clé de liste/clé de hachage stocke souvent une quantité d'informations relativement importante qui sera supérieure à 64 octets, elle est donc susceptible d'être supérieure à 64 lors de la configuration, en tenant compte de la capacité de stockage réelle des données et de la capacité de stockage réelle des données. taille de previous_entry_length mentionnée ci-dessus, [] -max-ziplist-value doit être une configuration raisonnablement ajustée.

Contenu du fichier de configuration :

Cas :

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

Utiliser la configuration par défaut avant de modifier la configuration :

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

127.0.0.1:6379> hstrlen good_list good_list1

(entier) 226

127.0.0.1:6379> ; objet encodant good_list

"hashtable"

Modifier la configuration :

hash-max-ziplist-entries 512

hash-max-ziplist -value 254

Remarque : vous devez redémarrer le serveur après avoir modifié la configuration

127.0.0.1:6379> hstrlen good_list good_list1

(integer) 226

127.0 .0.1:6379> encodage d'objet good_list

"ziplist"

Vous pouvez voir que la méthode de stockage a été modifiée en ziplist

Suggestions de tests de résistance et d'orientation plus officielles :

Lorsque le nombre d'éléments d'une liste compressée atteint plusieurs milliers (l'utilisation réelle peut être bien inférieure à cette valeur), les performances de la liste compressée peut diminuer car Redis Lors de l'utilisation de cette structure, il y aura une certaine pression sur l'encodage et le décodage.

La longueur de la liste compressée est limitée à 500-2000 et la taille de chaque élément est limitée à 128 octets ou moins. Les performances de la liste compressée seront dans une plage raisonnable.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!