Maison > base de données > Redis > Quand Redis utilise-t-il le type de hachage ?

Quand Redis utilise-t-il le type de hachage ?

Libérer: 2019-07-04 16:16:09
original
3716 Les gens l'ont consulté

Quand Redis utilise-t-il le type de hachage ?

Le type Hash est une table de mappage de champs et de valeurs de type String, ou une collection String. Il est particulièrement adapté au stockage d'objets en comparaison, au stockage d'un type d'objet dans le Hash. type Par rapport au stockage dans une classe de type String, il prend moins d'espace mémoire et facilite l'accès à l'ensemble de l'objet.

Dans Redis, le type de hachage fait référence à la valeur clé elle-même qui est une structure de paire clé-valeur, sous la forme : value={{field1,value1},{field2,value2},{fieldN,valueN }} ,

Commandes communes :

hget, hset, hgetall, etc.

Scénario d'application :

Donnons un exemple simple pour décrire le scénario d'application de Hash. Par exemple, nous souhaitons stocker les données d'un objet d'information utilisateur, comprenant les informations suivantes :

<.>ID utilisateur, pour la clé de recherche, la valeur de l'objet utilisateur stockée dans

contient des informations telles que le nom, l'âge, l'anniversaire, etc.

Si vous utilisez une structure clé/valeur normale pour stocker, il existe deux méthodes de stockage principales :

La première méthode utilise l'ID utilisateur comme clé de recherche et encapsule d'autres informations dans un objet. Stocké de manière sérialisée,

tel que : set u001 "Li San,18,20010101"

L'inconvénient de cette méthode est qu'elle augmente la surcharge de sérialisation/désérialisation, et dans Quand l'une des informations doit être modifiée, l'objet entier doit être récupéré et l'opération de modification doit protéger la concurrence, introduisant des problèmes complexes tels que CAS.

La deuxième méthode consiste à stocker autant de paires clé-valeur qu'il y a de membres dans l'objet d'information utilisateur, et à utiliser l'ID utilisateur + le nom de l'attribut correspondant comme identifiant unique pour obtenir la valeur du attribut correspondant, tel que : mset user : 001:name "李三 "user:001:age18 user:001:birthday "20010101"

Bien que la surcharge de sérialisation et les problèmes de concurrence soient éliminés, l'ID utilisateur est stocké à plusieurs reprises S'il existe une grande quantité de telles données, le gaspillage de mémoire reste très considérable.

Ensuite, le Hash fourni par Redis résout très bien ce problème. Le Hash de Redis stocke en fait la valeur en interne sous forme de HashMap, et fournit une interface pour un accès direct aux membres de cette Map.

Par exemple : utilisateur hmset :001 nom "李三" âge 18 ans anniversaire "20010101"

En d'autres termes, la clé est toujours l'ID utilisateur, la valeur est une carte et la la clé de cette Map est un membre Le nom de l'attribut, la valeur est la valeur de l'attribut, afin que la modification et l'accès aux données puissent se faire directement via la Clé de sa Map interne (la clé de la Map interne est appelée champ dans Redis), c'est-à-dire que via la clé (ID utilisateur) + le champ (balise d'attribut), les données d'attribut correspondantes sont exploitées. Il n'est pas nécessaire de stocker les données à plusieurs reprises et cela ne pose pas de problèmes de sérialisation et de contrôle des modifications simultanées. Très bien résolu le problème. Il convient également de noter ici que Redis fournit une interface (hgetall) pour obtenir directement toutes les données d'attribut. Cependant, s'il existe de nombreux membres de la carte interne, cela implique l'opération de parcourir l'intégralité de la carte interne en raison du monothread. Dans le modèle Redis, cette opération de traversée peut prendre plus de temps et les autres demandes des clients ne répondront pas du tout, ce qui nécessite une attention particulière.

Méthode d'implémentation : comme mentionné ci-dessus, le hachage Redis correspondant à la valeur est en fait un HashMap. Il existe en fait deux implémentations différentes ici. Lorsque le hachage a moins de membres, Redis utilisera un tableau unidimensionnel. méthode pour économiser de la mémoire. Pour stocker de manière compacte, au lieu d'utiliser la vraie structure HashMap, l'encodage de la valeur correspondante redisObject est zipmap. Lorsque le nombre de membres augmente, il sera automatiquement converti en un véritable HashMap, et l'encodage est ht.

Pour plus de connaissances sur Redis, veuillez visiter la colonne

Tutoriel d'utilisation de Redis !

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!

Étiquettes associées:
source:php.cn
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal