Tutoriel Redis (14) : Introduction à l'optimisation de la mémoire

1. Encodage spécial :

Depuis Redis 2.2, de nombreux types de données peuvent être optimisés pour l'espace de stockage grâce à un encodage spécial. Parmi eux, Hash, List et Sets composés d'Integer peuvent tous utiliser cette méthode pour optimiser la structure de stockage afin d'occuper moins d'espace. Dans certains cas, 9/10 de l'espace peut être économisé.
Ces encodages spéciaux sont totalement transparents pour l'utilisation de Redis. En fait, il s'agit simplement d'une transaction entre le CPU et la mémoire. Si l'utilisation de la mémoire est plus élevée, davantage de CPU sera naturellement consommée lors de l'exploitation des données, et vice versa. Redis fournit un ensemble de paramètres de configuration pour définir divers seuils liés à un codage spécial, tels que :

  #如果Hash中字段的数量小于参数值，Redis将对该Key的Hash Value采用特殊编码。
    hash-max-zipmap-entries 64
    #如果Hash中各个字段的最大长度不超过512字节，Redis也将对该Key的Hash Value采用特殊编码方式。
    hash-max-zipmap-value 512
    #下面两个参数的含义基本等同于上面两个和Hash相关的参数，只是作用的对象类型为List。
    list-max-ziplist-entries 512
    list-max-ziplist-value 64
    #如果set中整型元素的数量不超过512时，Redis将会采用该特殊编码。
    set-max-intset-entries 512

Si une valeur qui a été codée dépasse la valeur dans les informations de configuration après avoir été modifiée. Si la limite maximale est atteint, Redis le convertira automatiquement en un format d'encodage normal. Cette opération est très rapide. Cependant, si vous le faites à l'envers et convertissez une valeur d'encodage normale plus grande en un encodage spécial, la suggestion de Redis est de le faire officiellement. Il est préférable de tester brièvement l'efficacité de la conversion avant, car de telles conversions sont souvent très inefficaces.

2. Opérations au niveau BIT et octet :

À partir de Redis 2.2, Redis fournit quatre caractères : GETRANGE/SETRANGE/GETBIT/SETBIT String type Key/ Commande de valeur. Grâce à ces commandes, nous pouvons accéder aux données de valeur de type String, tout comme les tableaux d'exploitation. Par exemple, l'ID qui identifie de manière unique un utilisateur peut être simplement une sous-chaîne de la valeur String. De cette manière, il peut être facilement extrait via la commande GETRANGE/SETRANGE. De plus, vous pouvez utiliser BITMAP pour représenter les informations de genre de l'utilisateur, par exemple 1 pour un homme et 0 pour une femme. Lorsque vous utilisez cette méthode pour représenter les informations de genre de 100 000 000 d'utilisateurs, elle n'occupe que 12 Mo d'espace de stockage. Dans le même temps, le parcours des données via la commande SETBIT/GETBIT est également très efficace.

3. Utilisez le hachage autant que possible :

Étant donné que les petites données de type Hash prennent relativement peu de place, nous devrions envisager d'utiliser le type Hash autant que possible dans les applications réelles, telles que l'enregistrement des utilisateurs. informations, qui comprennent des champs tels que le nom, le sexe, l’e-mail, l’âge et le mot de passe. Bien entendu, nous pouvons stocker ces informations sous forme de clé, et les informations renseignées par l'utilisateur sont stockées sous forme de valeur de chaîne. Cependant, Redis préfère le stocker sous forme de hachage, et les informations ci-dessus sont exprimées sous forme de champ/valeur.
Nous allons maintenant prouver davantage cette affirmation en apprenant le mécanisme de stockage de Redis. Le mécanisme de codage spécial a été mentionné au début de ce blog, et il existe deux paramètres de configuration liés au type de hachage : hash-max-zipmap-entries et hash-max-zipmap-value. Quant à leur champ d’action, ils ont déjà été donnés, je n’entrerai donc pas dans les détails ici. Supposons maintenant que le nombre de champs stockés dans la valeur de hachage est inférieur à hash-max-zipmap-entries et que la longueur de chaque élément est également inférieure à hash-max-zipmap-value. De cette façon, chaque fois qu'il y a un nouveau stockage clé/valeur de type Hash, Redis créera un espace de longueur fixe pour la valeur de hachage. Le nombre maximum d'octets pré-alloués est :
total_bytes = hash-max-zipmap-. entrées * hash -max-zipmap-value
De cette façon, les positions de tous les champs dans le hachage ont été réservées et le champ/valeur est accessible de manière aléatoire comme pour accéder à un tableau. L'intervalle entre eux est hash-max. -zipmap-valeur. Ce n'est que lorsque le nombre de champs dans la valeur de hachage ou la longueur d'un nouvel élément dépasse respectivement les deux valeurs de paramètres ci-dessus que Redis envisagera de les restaurer sous la forme d'une table de hachage, sinon il conservera toujours ce stockage efficace. et accès. De plus, étant donné que chaque clé doit stocker certaines informations système associées, telles que le délai d'expiration, le LRU, etc., par rapport à la clé/valeur de type chaîne, le type Hash réduit considérablement le nombre de clés (la plupart des clés sont représentées et stockées sous la forme d'un champ de hachage), optimisant ainsi davantage l'efficacité d'utilisation de l'espace de stockage.

Ce qui précède est le contenu du didacticiel Redis (14) : Introduction à l'optimisation de la mémoire. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !