Prawie już masz odpowiedź na swoje pierwsze pytanie: celem ADD
jest działanie tylko wtedy, gdy klucz jeszcze nie istnieje, podczas gdy SET
istnieje możliwość aktualizacji wartości, niezależnie od tego, czy już istnieje. Jeśli znasz SQL, to (z grubsza) przypomina różnicę między INSERT
zapytaniami ( ADD
) i UPDATE
( SET
).
Jeśli chodzi o twoje pytanie uzupełniające, użyłbyś tego, które odpowiada Twojemu celowi. Powiedziałbym, że SET
byłaby to bardziej powszechna operacja, ponieważ jest bardziej powszechne, że po prostu chcesz powiedzieć: „Chcę, aby klucz foo
miał wartość bar
, i nie obchodzi mnie, czy już tam był”. Zdarzałyby się jednak (rzadziej) sytuacje, w których trzeba byłoby wiedzieć, że klucza nie ma już w pamięci podręcznej.
Przykładem, który przychodzi mi na myśl, kiedy ADD
byłoby właściwe, jest przechowywanie sesji w memcache (które, nawiasem mówiąc, nie polecam) - jeśli generujesz identyfikatory sesji losowo (lub za pomocą skrótu), nie chcesz aby utworzyć nową sesję z takim samym kluczem jak istniejący, ponieważ zapewni to jednemu użytkownikowi dostęp do danych innego użytkownika. W takim przypadku, gdy utworzysz sesję, której będziesz używał ADD
, a jeśli zwróci stan awarii, musisz wygenerować nowy identyfikator sesji i spróbować ponownie. Oczywiście zaktualizowanie sesji przydałoby się wtedy, SET
gdy użytkownik przeglądał Twoją aplikację.
REPLACE
to nie jest nawet SQL ... to „język luźno zainspirowany SQL, który MySQL rozumie” (uśmiech)Oprócz powyższej odpowiedzi użytkownika „womble”, weź również pod uwagę następujące kwestie:
Możliwość wystąpienia warunków wyścigu z „set” w przeciwieństwie do „add”. Zobacz poniższy link do odpowiedzi Nick Johnson: /programming/13234556/using-memcache-add-instead-of-set
Jeśli wiesz, że zrobi to „dodaj”, nie używaj „set”. Ma to na celu uniknięcie wysyłania danych przez sieć, ponieważ są to połączenia RPC . I praktycznie prawie cały czas jest pochłaniany przez ruch sieciowy, w przeciwieństwie do szukania pary klucz-wartość w memcache. Jeśli więc możesz uniknąć ruchu sieciowego, najlepiej jak w takim przypadku, czas reakcji będzie krótszy.
Zobacz Appstats ( https://developers.google.com/appengine/docs/python/tools/appstats (przez Google)) i aby zrozumieć punkt 2 powyżej, zobacz http://www.youtube.com/watch ? v = bvp7CuBWVgA autor: Guido Van Rossum (@Google)
źródło