Comment Redis économise de la mémoire

Tout d'abord, cette application qui vérifie l'UID de l'utilisateur via une photo d'identité a les exigences suivantes :

• La vitesse de requête doit être suffisamment rapide

  # 🎜🎜 #
• Toutes les données doivent être stockées dans la mémoire, de préférence un modèle EC2 à haute mémoire (17 Go ou 34 Go, 68 Go est trop de gaspillage)

  # 🎜🎜#

  # 🎜🎜#Prend en charge la persistance, il n'est donc pas nécessaire de se réchauffer après le redémarrage du serveur

• Tout d'abord, ils ont rejeté la solution de stockage de base de données ( Keep It Simple and Stupid) est maintenu, car cette application n'utilise pas du tout la fonction de mise à jour, la fonction de transaction, les requêtes associées et d'autres fonctions impressionnantes de la base de données, il n'est donc pas nécessaire de choisir et de maintenir une base de données pour ces fonctions inutilisées.

Ils ont donc choisi Redis, une base de données en mémoire qui prend en charge la persistance. Toutes les données sont stockées en mémoire (oubliez la VM), et l'implémentation la plus simple consiste à utiliser la structure String de Redis. un magasin clé-valeur. Comme ceci :

SET media:1155315 939
GET media:1155315
> 939

Parmi eux, 1155315 est l'ID de l'image et 939 est l'ID de l'utilisateur. Nous utilisons chaque ID d'image comme clé et l'UID de l'utilisateur comme valeur pour enregistrer la paire clé-valeur. Ensuite, ils ont effectué un test et stocké les données selon la méthode ci-dessus. 1 000 000 de données utiliseront 70 Mo de mémoire et 300 000 000 de photos utiliseront 21 Go de mémoire. Par rapport au budget de 17 Go, c’est encore une dépense excessive.

(NoSQLFan : En fait, on peut voir ici un point d'optimisation. On peut supprimer le même média devant la valeur de la clé et enregistrer uniquement les chiffres. Cela réduira la longueur de la clé et réduira l'impact de la valeur de clé sur la surcharge de mémoire [Remarque : les valeurs de clé Redis ne convertissent pas les chaînes en nombres, donc ce qui est enregistré ici n'est que la surcharge des 6 octets de média :] Après les expériences, l'utilisation de la mémoire sera. être réduite à 50 Mo, et l'utilisation totale de la mémoire sera réduite. Elle est de 15 Go, ce qui répond à la demande, mais les améliorations ultérieures d'Instagram sont encore nécessaires)

Les développeurs d'Instagram ont donc demandé à Pieter Noordhuis, l'un des les développeurs de Redis, à propos du plan d'optimisation, et la réponse a été d'utiliser la structure Hash. La méthode spécifique consiste à segmenter les données et à utiliser une structure de hachage pour stocker chaque segment. Étant donné que la structure de hachage compressera et stockera un seul élément de hachage lorsqu'il est inférieur à un certain nombre, elle peut économiser beaucoup de mémoire. Cela n'existe pas dans la structure String ci-dessus. Le paramètre "hash-zipmap-max-entries" dans le fichier de configuration contrôle un certain nombre. Après les expériences des développeurs, lorsque hash-zipmap-max-entries est défini sur 1000, les performances sont meilleures. Après avoir dépassé 1000, la commande HSET entraînera une consommation CPU très importante.

Ils ont donc modifié le plan et stocké les données dans la structure suivante :

HSET "mediabucket:1155" "1155315" "939"
HGET "mediabucket:1155" "1155315"
> "939"

En prenant les quatre premiers chiffres de la photo d'identité à 7 chiffres comme valeur clé du Structure de hachage, c'est garanti. Chaque hachage ne contient qu'une clé à 3 chiffres, soit 1 000.

Après avoir mené une autre expérience, il a été constaté que seulement 16 Mo de mémoire étaient consommés pour 1 000 000 de clés. L'utilisation totale de la mémoire a également été réduite à 5 Go, ce qui répond aux exigences des applications.

(NoSQLFan : De même, nous pouvons toujours optimiser ici. La première consiste à changer la valeur clé de la structure de hachage en un nombre pur, afin que la longueur de la clé soit réduite de 12 octets. La seconde est pour modifier la structure de hachage, la valeur de la sous-clé devient trois chiffres, ce qui réduit la surcharge de 4 octets, comme indiqué ci-dessous. Après les expériences, l'utilisation de la mémoire sera réduite à 10 Mo et l'utilisation totale de la mémoire est de 3 Go)

HSET "1155" "315" "939"
HGET "1155" "315"
> "939"

. .

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!