Ajouter vs définir dans Memcached

17

Je ne comprends pas la différence entre ADD et SET. Des indices? Il semble que ADD inclut SET ou que ADD renvoie false si quelque chose est là et que SET écrase simplement. Merci!

EDIT: Ma question spécifique est: "Quand utilisez-vous ajouter plutôt que définir ou définir plutôt que d'ajouter?"

memcached

— user851171
source

22

Vous avez déjà à peu près la réponse à votre première question: l'intention de ADDest de ne fonctionner que lorsqu'une clé n'existe pas déjà, alors qu'il SETest là pour mettre à jour la valeur, qu'elle existe déjà ou non. Si vous êtes familier avec SQL, c'est (à peu près) comme la différence entre les INSERTrequêtes ( ADD) et UPDATE( SET).

En ce qui concerne votre question addenda, vous utiliseriez celui qui convient à votre objectif. Je dirais que ce SETserait l'opération la plus courante, car il est plus courant que vous vouliez simplement dire "Je veux que la clé fooait de la valeur bar, et je me fiche de savoir si elle était déjà là". Cependant, il y aurait des occasions (moins fréquentes) où il serait nécessaire de savoir qu'une clé n'est pas déjà dans le cache.

Un exemple qui me vient à l'esprit quand il ADDserait approprié est de stocker des sessions dans memcache (ce que je ne recommande d'ailleurs pas) - si vous générez vos identifiants de session de manière aléatoire (ou via le hachage), vous ne voudriez pas pour créer une nouvelle session avec la même clé qu'une session existante, car cela permettrait à un utilisateur d'accéder aux données d'un autre utilisateur. Dans ce cas, lorsque vous avez créé la session que vous utiliseriez ADDet si elle renvoyait un état d'échec, vous devez générer un nouvel ID de session et réessayer. La mise à jour de la session, bien sûr, serait alors utilisée SETpendant que l'utilisateur se frayait un chemin dans votre application.

— womble
source

1

Je pourrais être un peu tatillonne ici, mais dans votre comparaison avec SQL, si "ajouter" se compare à INSERT, "définir" se comparerait à REMPLACER plutôt qu'à METTRE À JOUR.

— matteo

2

D'où l'utilisation du mot "grossièrement". Si vous voulez devenir vraiment nerveux, ce REPLACEn'est même pas du SQL ... c'est "le langage vaguement inspiré du SQL que MySQL comprend" (sourire)

— womble

3

En plus de la réponse ci-dessus par l'ID utilisateur 'womble', veuillez également considérer les points suivants:

Possibilité d'une condition de concurrence avec 'set' par opposition à 'add'. Voir ci-dessous le lien vers une réponse de Nick Johnson: /programming/13234556/using-memcache-add-instead-of-set
Si vous savez que «ajouter» fera l'affaire, alors n'utilisez pas «set». C'est pour éviter d'envoyer des données sur le réseau car ce sont des appels RPC . Et pratiquement tout le temps est consommé par le trafic réseau au lieu de rechercher une paire clé-valeur dans memcache. Donc, si vous pouvez éviter le trafic réseau qui est le meilleur, comme dans ce cas, votre temps de réponse sera plus rapide.

Voir Appstats ( https://developers.google.com/appengine/docs/python/tools/appstats (par Google)) et pour mieux comprendre le point # 2 ci-dessus, veuillez regarder http://www.youtube.com/watch ? v = bvp7CuBWVgA par Guido Van Rossum (@Google)

— dev-vb
source