Redis 10x plus de l'utilisation de la mémoire de données

J'ai une petite question.

Je suis en train de stocker une liste de mots dans le redis. La performance est très bonne.

Ma démarche est de faire un jeu appelé "les mots" et à l'ajout de chaque nouveau mot par "sadd'.

Voici le problème lors de l'ajout d'un fichier c'est de 15,9 mo et contient environ un million de mots le redis-server processus consomme 160 mo de ram. Comment se fait-je suis à l'aide de 10x la mémoire, est-il une meilleure façon d'aborder ce problème?

Merci d'Avance

InformationsquelleAutor cwoebker | 2012-04-04
  1. 83

    Bien ce qui est attendu de tout stockage de données efficaces: les mots doivent être indexés en mémoire dans une dynamique de données de la structure des cellules liées par des pointeurs. La taille de la structure des métadonnées, les pointeurs et l'allocateur de mémoire interne, la fragmentation est la raison pour laquelle les données à prendre beaucoup plus de mémoire qu'un correspondant de fichier plat.

    Un Redis ensemble est mis en œuvre comme une table de hachage. Cela comprend:

    • un tableau de pointeurs de croissance géométrique (les puissances de deux)
    • un second tableau peut être requise lorsque les différentiels ressasser active est
    • seule liste liée cellules représentant les entrées dans la table de hachage (3 pointeurs, 24 octets par entrée)
    • Redis wrappers d'objets (un par valeur) (16 octets par entrée)
    • réel des données elles-mêmes (chacun d'eux préfixé par 8 octets pour la taille et de la capacité)

    Toutes les dimensions ci-dessus sont donnés pour les 64 bits de mise en œuvre. La comptabilité pour l'allocateur de mémoire de frais généraux, il en résulte Redis au moins de 64 octets par élément (en plus des données) pour une version récente de Redis à l'aide de la jemalloc allocateur (>= 2.4)

    Redis fournit des optimisations de mémoire pour certains types de données, mais elles ne couvrent pas les ensembles de chaînes de caractères. Si vous avez vraiment besoin pour optimiser la consommation de mémoire des ensembles, il y a des trucs que vous pouvez utiliser si. Je ne ferais pas cela pour seulement 160 MO de RAM, mais si vous avez plus de données, voici ce que vous pouvez faire.

    Si vous n'avez pas besoin de l'union, intersection, différence des capacités de jeux, alors vous pouvez stocker vos mots de hachage objets. L'avantage est de hachage objets peuvent être optimisés automatiquement par le Redis à l'aide de zipmap si elles sont assez petites. Le zipmap mécanisme a été remplacé par ziplist dans le Redis >= 2.6, mais l'idée est la même: à l'aide d'un sérialisé structure de données qui peut rentrer dans les caches CPU pour obtenir à la fois la performance et un compact empreinte mémoire.

    Pour garantir le hachage des objets sont assez petites, les données peuvent être distribuées selon certains mécanisme de hachage. En supposant que vous avez besoin de stocker 1M articles, l'ajout d'un mot pourrait être mise en œuvre de la manière suivante:

    • de hachage, il modulo 10000 (en fait sur le côté client)
    • HMSET mots:[hashnum] [mot] 1

    Au lieu de les stocker:

    words => set{ hi, hello, greetings, howdy, bonjour, salut, ... }

    vous pouvez stocker:

    words:H1 => map{ hi:1, greetings:1, bonjour:1, ... }
words:H2 => map{ hello:1, howdy:1, salut:1, ... }
...

    De récupérer ou de vérifier l'existence d'un mot, c'est la même chose (de hachage et de l'utiliser HGET ou HEXISTS).

    Avec cette stratégie, de mémoire importante économie peut être fait à condition que le modulo de la table de hachage est
    choisi en fonction de la zipmap de configuration (ou ziplist pour le Redis >= 2.6):

    # Hashes are encoded in a special way (much more memory efficient) when they
# have at max a given number of elements, and the biggest element does not
# exceed a given threshold. You can configure this limits with the following
# configuration directives.
hash-max-zipmap-entries 512
hash-max-zipmap-value 64

    Attention: le nom de ces paramètres ont été modifiés avec le Redis >= 2.6.

    Ici, modulo 10000 pour 1M éléments signifie que 100 articles par hachage des objets, ce qui permettra de garantir que tous sont stockées en tant que zipmaps/ziplists.

    • Fascinant et détaillée de la réponse; je ne le savais pas. Merci @Didier !
    • D'accord merci beaucoup je suis assez positif, que cela va résoudre mes problèmes. Et ouais 160 mo pour son bien, mais je suis dans l'attente de travailler avec 1 go de plaine de données de mots, et ne voulait pas que le pic à 10 go. Merci beaucoup encore une fois, d'apprécier la réponse détaillée.
    • Super réponse! Quelques corrections si a) les entrées de la table de hachage sont une seule liste liée, pas de double, 24 octets est correct si b) le Redis objet wrapper ne s'applique pas à chaque jeu/hachage entrées. Elle ne s'applique qu'à haut niveau de paire clé/valeur - de sorte que la charge du système est constante c) Vous pouvez peut-être indiquer que zipmap est supprimée de la version 2.6/instable, et que ziplist font la même chose.
    • merci, j'ai mis à jour ma réponse. Je continue de penser que robj d'utilisation s'applique à tous ensemble les touches bien. Je me réfère à la setDictType structure dans le redis.c et les fonctions correspondantes, qui définissent ce comportement.
    • re. robj d'utilisation : oui, vous avez raison. Je ne sais pas comment j'ai négligé que l'emballage!
    • Très belle & réponse détaillée.. Merci. +1
    • Une mise en garde/correction "Ici, modulo 10000 pour 1M éléments signifie que 100 articles par hachage des objets, ce qui permettra de garantir que tous sont stockées en tant que zipmaps/ziplists." ... Pourtant, au-delà de ce que vous donner un exemple de hachage des mots, le modulo par 10000. Il ne sera pas uniformément générer 100 articles par compartiment de hachage. Fondamentalement, certains de tables de hachage, sous certaines touches, facilement plus de 100 entrées en eux, en raison de la façon aléatoire des codes de hachage distribuer. Le mieux pour définir hash-max-zipmap-entries bien au-dessus de 100.
    • Au lieu de stockage: mots => set{ hi, bonjour, salut, bonjour, bonjour, salut, ... } vous pouvez stocker: les mots:H1 => map{ hi:1, salutations:1, bonjour:1, ... } mots:H2 => map{ bonjour:1, howdy:1, "salut": 1, ... } Cloud vous expliquer plus en détail comment vous le faire?. Merci beaucoup @DidierSpezia

    InformationsquelleAutor Didier Spezia
  2. 5

    Quant à mes expériences, Il est préférable de stocker vos données dans une table de hachage/dictionnaire . le meilleur cas, j'ai atteint après beaucoup de l'analyse comparative consiste à stocker à l'intérieur de votre table de hachage des données entrées ne sont pas supérieures à 500 clés.

    J'ai essayé de cordes standard set/get, pour 1 million de clés/valeurs, la taille était de 79 MO. Il est très grand dans le cas où si vous avez de grands nombres de 100 millions de dollars qui permettra d'utiliser autour de 8 GO.

    J'ai essayé de hachages pour stocker les mêmes données, pour les mêmes millions de clés/valeurs, la taille était de plus en plus petite de 16 MO.

    Avoir un essai dans le cas où si quelqu'un a besoin de l'analyse comparative de code, envoyez-moi un mail

    • Comment avez-vous effectuer ces mesures? Merci
    InformationsquelleAutor Muhammad Soliman
  3. 2

    Avez-vous essayé la persistance de la base de données (BGSAVE par exemple), arrêt du serveur et de le faire remonter? En raison de la fragmentation de comportement, quand il s'agit de sauvegarder et de remplit son de données de la sauvegarde de la RDB dossier, il pourrait prendre moins de mémoire.

    Aussi: Quelle version de Redis pour qui vous travaillez? Jetez un oeil à ce blog - il dit que la fragmentation a partiellement résolu à partir de la version 2.4.

    InformationsquelleAutor Ofer Zelig