Głównym powodem, dla którego widzę dziś zastosowanie memcached w porównaniu z Redis, jest doskonała wydajność pamięci, którą powinieneś być w stanie uzyskać dzięki buforowaniu zwykłych fragmentów HTML (lub podobnych aplikacji). Jeśli chcesz przechowywać różne pola obiektów w różnych kluczach memcached, skróty Redis będą bardziej wydajne w pamięci, ale gdy masz dużą liczbę par kluczy -> simple_string, memcached powinien być w stanie dać ci więcej elementów megabajt.
Inne zalety memcached:
- Jest to bardzo prosty fragment kodu, więc jeśli potrzebujesz tylko funkcjonalności, którą zapewnia, jest to chyba rozsądna alternatywa, ale nigdy nie użyłem go w produkcji.
- Jest wielowątkowy, więc jeśli potrzebujesz skalować w konfiguracji single-box, jest to dobra rzecz i musisz rozmawiać tylko z jedną instancją.
Uważam, że Redis jako pamięć podręczna ma coraz większy sens, gdy ludzie przechodzą w kierunku inteligentnego buforowania lub gdy próbują zachować strukturę danych w pamięci podręcznej za pośrednictwem struktur danych Redis.
Porównanie Redis LRU i memcached LRU.
Zarówno memcached, jak i Redis nie wykonują prawdziwych eksmisji LRU, a jedynie przybliżenie tego.
Eksmisja Memcache jest zależna od klasy rozmiaru i zależy od szczegółów implementacji alokatora płyty. Na przykład, jeśli chcesz dodać element, który pasuje do danej klasy rozmiaru, memcached spróbuje usunąć elementy tej klasy, które wygasły / nie były ostatnio używane, zamiast tego spróbować globalnej próby zrozumienia, czym jest obiekt, niezależnie od jego rozmiar, który jest najlepszym kandydatem.
Zamiast tego Redis próbuje wybrać dobry obiekt jako kandydata do eksmisji po osiągnięciu maxmemorylimitu, patrząc na wszystkie obiekty, niezależnie od klasy wielkości, ale jest w stanie zapewnić tylko w przybliżeniu dobry obiekt, a nie najlepszy obiekt z większym bezczynnością czas.
Sposób, w jaki Redis to robi, polega na próbkowaniu kilku obiektów, wybierając ten, który był bezczynny (bez dostępu) przez najdłuższy czas. Od wersji Redis 3.0 (obecnie w wersji beta) algorytm został ulepszony i bierze również dobre pule kandydatów z eksmisji, więc przybliżenie uległo poprawie. W dokumentacji Redis można znaleźć opis i wykresy ze szczegółowymi informacjami o tym, jak to działa .
Dlaczego memcached ma lepszy ślad pamięci niż Redis dla prostych map ciągów -> ciągów.
Redis jest bardziej złożonym oprogramowaniem, więc wartości w Redis są przechowywane w sposób bardziej podobny do obiektów w języku programowania wysokiego poziomu: mają skojarzony typ, kodowanie, zliczanie referencji do zarządzania pamięcią. To sprawia, że wewnętrzna struktura Redis jest dobra i łatwa w zarządzaniu, ale ma narzut w porównaniu z memcached, który zajmuje się tylko ciągami.
Kiedy Redis zaczyna działać wydajniej pod kątem pamięci
Redis jest w stanie przechowywać małe zagregowane typy danych w specjalny sposób oszczędzający pamięć. Na przykład mały skrót Redis Hash reprezentujący obiekt jest przechowywany wewnętrznie nie w tabeli skrótów, ale jako binarny unikalny obiekt blob. Zatem ustawienie wielu pól na obiekt w hash jest bardziej wydajne niż przechowywanie N oddzielnych kluczy w memcached.
W rzeczywistości możesz przechowywać obiekt w memcached jako pojedynczy obiekt blob JSON (lub zakodowany binarnie), ale w przeciwieństwie do Redis nie pozwoli to na pobieranie ani aktualizowanie niezależnych pól.
Zaleta Redis w kontekście inteligentnego buforowania.
Ze względu na struktury danych Redis, zwykły wzorzec używany w memcached do niszczenia obiektów, gdy pamięć podręczna jest unieważniona, w celu późniejszego odtworzenia jej z bazy danych, jest prymitywnym sposobem korzystania z Redis.
Na przykład, wyobraź sobie, że musisz zapisać w pamięci podręcznej najnowsze wiadomości publikowane w witrynie Hacker News w celu zapełnienia sekcji „Najnowsze” witryny. To, co robisz w Redis, to tworzenie listy (ograniczonej do pozycji M) z wstawionymi najnowszymi wiadomościami. Jeśli używasz innego magazynu dla swoich danych, a Redis jako pamięci podręcznej, wystarczy wypełnić oba widoki (Redis i DB), gdy zostanie opublikowany nowy element. Nie ma unieważnienia pamięci podręcznej.
Jednak aplikacja może zawsze mieć logikę, więc jeśli okaże się, że lista Redis jest pusta, na przykład po uruchomieniu, początkowy widok można ponownie utworzyć z bazy danych.
Korzystając z inteligentnego buforowania, można wykonać buforowanie w Redis w bardziej efektywny sposób w porównaniu z memcached, ale nie wszystkie problemy są odpowiednie dla tego wzorca. Na przykład buforowanie fragmentów HTML może nie przynosić korzyści z tej techniki.