Memcached vs. Redis?

Question

Memcached vs. Redis?

Używamy aplikacji internetowej Ruby z serwerem Redis do buforowania. Czy istnieje sens testowania Memcached zamiast tego?

Co da nam lepsze wyniki? Jakieś plusy lub minusy między Redis i Memcached?

Punkty do rozważenia:

Prędkość Odczytu/Zapisu.
wykorzystanie pamięci.
dysk I/o dumping.
skalowanie.

1171

web-applications caching memcached redis

Author: Zeeshan Ali, 2012-05-12

Source

17 answers

Użyj Redis if

Wymagane jest selektywne usuwanie / wygasanie elementów w pamięci podręcznej. (Potrzebujesz tego)
Wymagana jest możliwość odpytywania kluczy określonego typu. eq. 'blog1: posts:*', ' blog2: categories: xyz: posts:*'. o tak! to bardzo ważne. Użyj tego do selektywnego unieważnienia niektórych typów elementów pamięci podręcznej. Można go również użyć do unieważnienia pamięci podręcznej fragmentów, pamięci podręcznej stron, tylko obiektów AR danego typu, itd.
Wytrwałość (będziesz potrzebujesz tego też, chyba że nie masz nic przeciwko, że twoja pamięć podręczna musi się rozgrzewać po każdym ponownym uruchomieniu. Bardzo istotne dla obiektów, które rzadko się zmieniają)

Użyj memcached if

Memcached daje Ci headached!
umm... grupowanie? meh. jeśli chcesz posunąć się tak daleko, użyj Varnish i Redis do buforowania fragmentów i obiektów AR.

Z mojego doświadczenia mam dużo lepszą stabilność z Redis niż Memcached

128

Author: SMathew,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-07-05 06:04:10

Memcached jest wielowątkowy i szybki.

Redis ma wiele funkcji i jest bardzo szybki, ale całkowicie ograniczony do jednego rdzenia, ponieważ opiera się na pętli zdarzeń.

Używamy obu. Memcached jest używany do buforowania obiektów, przede wszystkim zmniejszając obciążenie odczytu w bazach danych. Redis jest używany do rzeczy takich jak sortowane zestawy, które są przydatne do zwijania danych szeregów czasowych.

79

Author: W. Andrew Loe III,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-05-03 16:41:30

Jest to zbyt długie, aby być zamieszczonym jako komentarz do już zaakceptowanej odpowiedzi, więc umieszczam ją jako oddzielną odpowiedź

Jedną rzeczą do rozważenia jest to, czy spodziewasz się mieć twardy górny limit pamięci na instancji pamięci podręcznej.

Ponieważ redis jest bazą danych nosql z mnóstwem funkcji, a buforowanie jest tylko jedną z opcji, do której może być używany, przydziela pamięć tak, jak jej potrzebuje - im więcej obiektów w niej umieścisz, tym więcej pamięci używa. Opcja maxmemory nie wymusza ściśle użycie górnego limitu pamięci. Podczas pracy z cache, klucze są eksmitowane i wygasły; są szanse, że klucze nie są tej samej wielkości, więc występuje fragmentacja pamięci wewnętrznej.

Domyślnie redis używa alokatora pamięci jemalloc , który stara się być zarówno Kompaktowy, jak i szybki, ale jest to alokator pamięci ogólnego przeznaczenia i nie może nadążyć z dużą ilością alokacji i usuwaniem obiektów z dużą szybkością. Z tego powodu na niektórych wzorcach obciążenia proces redis może najwyraźniej wyciekła pamięć z powodu wewnętrznej fragmentacji. Na przykład, jeśli masz serwer z 7 GB PAMIĘCI RAM i chcesz używać redis jako nietrwałej pamięci podręcznej LRU, może się okazać, że proces redis z maxmemory ustawionym na 5 GB z czasem zużywałby coraz więcej pamięci, ostatecznie osiągając całkowity limit pamięci RAM, dopóki zabójca poza pamięcią nie zakłóci.

Memcached lepiej pasuje do scenariusza opisanego powyżej, ponieważ zarządza swoją pamięcią w zupełnie inny sposób. memcached przydziela jeden duży kawałek pamięci - wszystko, czego kiedykolwiek będzie potrzebował-a następnie zarządza tą pamięcią samodzielnie, używając własnego zaimplementowanego alokatora slab. Ponadto memcached stara się utrzymać wewnętrzną fragmentację na niskim poziomie, ponieważ w rzeczywistości używa algorytmu LRU per-slab, gdy eksmisje LRU są wykonywane z uwzględnieniem rozmiaru obiektu.

Mając to na uwadze, memcached nadal ma silną pozycję w środowiskach, w których użycie pamięci musi być wymuszone i / lub przewidywalne. Próbowaliśmy użyć najnowszego stabilnego redis (2.8.19) jako drop-in non-persistent Memcached oparty na LRU w obciążeniu 10-15K op / s, i wyciekła pamięć dużo; to samo obciążenie było upaść Amazon elasticache redis instancji w ciągu dnia lub tak z tych samych powodów.

70

Author: artyom,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-03-02 11:22:00

Memcached jest dobry w byciu prostym przechowywaniem kluczy / wartości i jest dobry w robieniu key = > STRING. To sprawia, że jest to naprawdę dobre dla przechowywania sesji.

Redis jest dobry w robieniu key => SOME_OBJECT.

To naprawdę zależy od tego, co zamierzasz tam umieścić. Rozumiem, że pod względem wydajności są one całkiem równe.

Również powodzenia w znalezieniu obiektywnych benchmarków, jeśli znajdziesz jakieś uprzejmie wyślij je w moją stronę.

45

Author: Erik Petersen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-05-11 23:32:37

Jeśli nie masz nic przeciwko kiepskiemu stylowi pisania, Redis vs Memcached na blogu Systoilet warto przeczytać z punktu widzenia użyteczności, ale pamiętaj, aby przeczytać back & forth w komentarzach przed wyciągnięciem jakichkolwiek wniosków na temat wydajności; istnieją pewne problemy metodologiczne( jednowątkowe testy pętli zajętości), a Redis wprowadził pewne ulepszenia od czasu napisania artykułu.

I żaden link benchmark nie jest kompletny bez trochę zamieszania, więc sprawdź też kilka w 2011 roku w Dormondo został wybrany na lidera w kategorii Najlepszy aktor drugoplanowy.

Edit -- jak zaznacza Antyrez, Analiza Systoilet jest raczej nieprzemyślana. Nawet poza niedoborem pojedynczych wątków, duża różnica w wydajności w tych benchmarkach może być przypisana bibliotekom klienckim, a nie przepustowości serwera. Benchmarki na The Antirez Weblog{[2] } rzeczywiście prezentują znacznie więcej jabłek do jabłek (z tymi samymi ustami) porównanie.

37

Author: Paul Smith,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-01-03 14:02:19

Dostałem możliwość korzystania zarówno memcached i redis razem w pamięci podręcznej proxy , nad którym pracowałem, pozwól mi podzielić się gdzie dokładnie użyłem co i powód tego samego....

Redis >

1) używany do indeksowania zawartości pamięci podręcznej nad klastrem . Mam ponad miliard kluczy rozłożonych na klastrach redis, czas reakcji redis jest znacznie mniejszy i stabilny .

2) zasadniczo jest to magazyn klucza / wartości, więc gdzie kiedykolwiek w aplikacji masz coś podobnie, można użyć redis z przeszkadza dużo.

3) Redis persistency, failover i backup (AoF ) ułatwi Ci pracę .

Memcache >

1) tak, zoptymalizowana pamięć, która może być używana jako pamięć podręczna . Używałem go do przechowywania zawartości pamięci podręcznej uzyskiwanej bardzo często (z 50 odsłon / sekundę) o rozmiarze mniejszym niż 1 MB .

2) przydzielałem tylko 2 GB z 16 GB na memcached, że też, gdy mój rozmiar pojedynczej zawartości był >1MB .

3) Gdy zawartość rośnie w pobliżu limity, czasami zaobserwowałem wyższe czasy reakcji w statystykach (Nie w przypadku redis).

Jeśli poprosisz o ogólne doświadczenie Redis jest dużo zielony, ponieważ jest łatwy w konfiguracji, dużo elastyczny ze stabilnymi, solidnymi funkcjami.

Dalej, pod tym linkiem , poniżej kilka z tych samych,

Mam nadzieję, że to pomoże!!

19

Author: Jain Rach,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-06-29 06:57:26

Kolejną zaletą jest to, że może być bardzo jasne, jak memcache będzie zachowywał się w scenariuszu buforowania, podczas gdy redis jest zwykle używany jako trwały magazyn danych, chociaż może być skonfigurowany tak, aby zachowywał się tak, jak memcached aka eksmitowanie ostatnio używanych przedmiotów, gdy osiągnie maksymalną pojemność.

Niektóre aplikacje, nad którymi pracowałem, używają obu tylko po to, aby wyjaśnić, jak zamierzamy zachować dane - rzeczy w memcache, piszemy kod do obsługi przypadków, w których ich nie ma - rzeczy w redis, polegamy na jest tam.

Poza tym Redis jest ogólnie uważany za lepszy w większości przypadków użycia, ponieważ jest bardziej bogaty w funkcje, a tym samym elastyczny.

12

Author: Scott Schulthess,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-07-04 12:42:21

Test. Uruchom kilka prostych benchmarków. Przez długi czas uważałem się za starego nosorożca, ponieważ używałem głównie memcached i uważałem Redisa za nowego dzieciaka.

W mojej obecnej firmie Redis był używany jako główny cache. Kiedy poszperałem w statystykach wydajności i po prostu zacząłem testować, Redis był pod względem wydajności porównywalny lub minimalnie wolniejszy niż MySQL.

Memcached, choć uproszczony, wydmuchał Redisa z wody CAŁKOWICIE . Znacznie się przeskalował lepiej:

dla większych wartości (wymagana zmiana rozmiaru płyty, ale obrobiona)
dla wielu jednoczesnych żądań

Również Polityka eksmisji memcached jest moim zdaniem znacznie lepiej zaimplementowana, co skutkuje ogólnie bardziej stabilnym średnim czasem odpowiedzi przy obsłudze większej ilości danych niż może obsłużyć pamięć podręczna.

Niektóre analizy porównawcze wykazały, że Redis, w naszym przypadku, działa bardzo słabo. Myślę, że ma to związek z wieloma zmiennymi:

rodzaj sprzętu uruchamiasz Redis na
rodzaje przechowywanych danych
Ilość getów i zestawów
Jak wygląda Twoja aplikacja
do you need data structure storage

Osobiście nie podzielam poglądu autorów Redis na współbieżność i wielowątkowość.

12

Author: mdomans,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-11-13 08:14:27

Nie byłoby źle, gdybyśmy powiedzieli, że redis jest kombinacją (bufor + struktura danych), podczas gdy memcached jest tylko buforem.

9

Author: Atif Hussain,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-06-16 05:45:06

Główną różnicą, która nie została tutaj wskazana, jest to, że Memcache ma górny limit pamięci przez cały czas, podczas gdy Redis nie jest domyślnie (ale można go skonfigurować). Jeśli chcesz zawsze przechowywać klucz/wartość przez pewien czas (i nigdy nie usuwać go z powodu niskiej pamięci), chcesz skorzystać z Redis. Oczywiście ryzykujesz również problem braku pamięci...

7

Author: Ztyx,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-03-01 09:45:27

Bardzo prosty test do Ustawienia i uzyskania 100k unikalnych kluczy i wartości dla redis-2.2.2 i memcached. Oba działają na Linux VM (CentOS) i mój kod klienta (wklejony poniżej) działa na pulpicie windows.

Redis

Czas przechowywania 100000 wartości wynosi = 18954ms
Czas potrzebny na załadowanie wartości 100000 wynosi = 18328ms

Memcached

Czas przechowywania 100000 wartości wynosi = 797ms
Czas pobrane do pobrania wartości 100000 wynosi = 38984ms

Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");

startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");

6

Author: Prabhu Nandan Kumar,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-11-04 06:57:41

Pomyśleliśmy o Redis jako o starcie ładunku do naszego projektu w pracy. Myśleliśmy, że używając modułu w nginx o nazwie HttpRedis2Module lub czegoś podobnego, będziemy mieli niesamowitą prędkość, ale podczas testowania z AB-test udowodniliśmy, że się mylimy.

Może moduł był zły lub nasz layout, ale było to bardzo proste zadanie i jeszcze szybciej było pobierać dane za pomocą php, a następnie wrzucać je do MongoDB. Używamy APC jako systemu buforowania i z tym php i MongoDB. To było o wiele szybciej niż Nginx Redis moduł.

Moja rada jest, aby przetestować go samodzielnie, robi to pokaże wyniki dla Twojego środowiska. Uznaliśmy, że używanie Redis jest niepotrzebne w naszym projekcie, ponieważ nie ma to żadnego sensu.

5

Author: Ms01,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-07-05 11:48:40

Największym pozostałym powodem jest specjalizacja.

Redis może robić wiele różnych rzeczy, a jednym ze skutków ubocznych jest to, że deweloperzy mogą zacząć używać wielu różnych zestawów funkcji na tej samej instancji. Jeśli używasz funkcji LRU Redis dla pamięci podręcznej wzdłuż bocznego twardego przechowywania danych, który nie jest LRU, całkowicie możliwe jest wyczerpanie pamięci.

Jeśli zamierzasz skonfigurować dedykowaną instancję Redis, która będzie używana tylko jako instancja LRU, aby uniknąć tego konkretnego scenariusza więc nie ma naprawdę żadnego przekonującego powodu, aby używać Redis nad Memcached.

Jeśli potrzebujesz niezawodnej pamięci podręcznej LRU "never goes down"...Memcached będzie pasował do rachunku, ponieważ nie jest możliwe, aby zabrakło mu pamięci z założenia, a funkcjonalność specialize uniemożliwia programistom próbę uczynienia go czymś, co mogłoby temu zagrozić. Proste rozdzielenie obaw.

4

Author: brightball,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-11-20 21:32:31

Redis jest lepszy Plusy Redis to:

1.It has a lot of data storage options such  as  string  , sets , sorted sets ,  hashes ,  bitmaps
2.Disk Persistence of records 
3.Stored Procedure (LUA acripting)  support
4.Can act as a Message Broker using PUB/SUB

Podczas gdy Memcache jest systemem typu Cache wartości klucza w pamięci.

Brak wsparcia dla różnych typów danych jak listy, zestawy jak w redis.
głównym przekrętem jest to, że Memcache nie ma trwałości dysku .

2

Author: athavan kanapuli,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-03-22 04:22:12

Memcached będzie szybszy, jeśli jesteś zainteresowany wydajnością, nawet dlatego, że Redis wymaga sieci (wywołań TCP). Również wewnętrznie Memcache jest szybszy.

Redis ma więcej funkcji, o których wspominały inne odpowiedzi.

1

Author: Denys,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-06-19 20:55:47

Cóż, głównie używałem zarówno z moimi aplikacjami, Memcache do buforowania sesji i redis do obiektów doctrine / ORM queries. Pod względem wydajności oba są prawie takie same.

0

Author: Muhammad Taqi,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-10-31 21:08:55

score 1684 · Accepted Answer

Summary (TL; DR)

Zaktualizowano 3 czerwca, 2017

Redis jest potężniejszy, bardziej popularny i lepiej obsługiwany niż memcached. Memcached może zrobić tylko niewielką część rzeczy, które może zrobić Redis. Redis jest lepszy nawet tam, gdzie ich funkcje nakładają się na siebie.

Do czegokolwiek nowego, użyj Redis.

Memcached vs Redis: bezpośrednie porównanie

Oba narzędzia są potężnymi, szybkimi magazynami danych w pamięci, które są przydatne jako pamięć podręczna. Oba mogą pomóc przyspieszyć aplikację poprzez buforowanie wyników bazy danych, fragmentów HTML lub czegokolwiek innego, co może być kosztowne w generowaniu.

Punkty do rozważenia

Gdy używane do tego samego, oto jak porównują używając oryginalnych "punktów do rozważenia" pytania:

Prędkość Odczytu/Zapisu : obie są niezwykle szybkie. Benchmarki różnią się w zależności od obciążenia, wersji i wielu innych czynników, ale generalnie pokazują, że Redi jest tak szybki lub prawie tak szybki jak memcached. Polecam redis, ale nie dlatego, że memcached jest powolny. Nie jest.
użycie pamięci : Redis jest lepszy.
- memcached: określasz rozmiar pamięci podręcznej, a gdy wstawiasz elementy, Demon szybko rośnie do nieco więcej niż ten rozmiar. Nigdy nie ma sposobu na odzyskanie żadnej z tych przestrzeni, bez ponownego uruchomienia memcached. Wszystkie Twoje klucze mogą być wygasłe, możesz spłukać bazę danych i nadal będzie używać pełnego fragmentu pamięci RAM, z którą ją skonfigurowałeś.
- redis: ustawienie maksymalnego rozmiaru zależy od Ciebie. Redis nigdy użyj więcej niż musi i zwróci ci pamięć, której już nie używa.
- zapisałem 100.000 ~ 2KB ciągów (~200MB) losowych zdań do obu. Wykorzystanie pamięci RAM Memcached wzrosło do ~225MB. Użycie pamięci RAM Redis wzrosło do ~228mb. Po spłukaniu obu, redis spadł do ~29MB, a memcached pozostał na ~225MB. Są one równie wydajne w sposobie przechowywania danych, ale tylko jeden jest w stanie je odzyskać.
Disk i/o dumping: wyraźna Wygrana redisa, ponieważ robi to przez domyślnie i ma bardzo konfigurowalną trwałość. Memcached nie ma mechanizmów do zrzucania na dysk bez narzędzi innych firm.
skalowanie: oba zapewniają mnóstwo miejsca na głowie, zanim Potrzebujesz więcej niż jednej instancji jako pamięci podręcznej. Redis zawiera narzędzia, które pomogą Ci wyjść poza to, podczas gdy memcached nie.

Memcached

Memcached jest prostym serwerem pamięci podręcznej. Pozwala na przechowywanie par klucz / wartość, w których wartość jest ograniczona do 1MB.

Jest w tym dobry, ale to wszystko. Można uzyskać dostęp do tych wartości za pomocą ich klucza z bardzo dużą prędkością, często nasycając dostępną przepustowość sieci lub nawet pamięci.

Po ponownym uruchomieniu memcached Twoje dane znikną. To jest dobre dla pamięci podręcznej. Nie powinieneś tam przechowywać niczego ważnego.

Jeśli potrzebujesz wysokiej wydajności lub wysokiej dostępności, dostępne są Narzędzia, Produkty i usługi innych firm.

Redis

Redis może wykonywać te same zadania co memcached może, i może zrobić je lepiej. Redis może również działać jako pamięć podręczna. Może również przechowywać pary klucz / wartość. W redis mogą mieć nawet do 512MB.

Możesz wyłączyć persistence i z radością straci również Twoje dane przy ponownym uruchomieniu. Jeśli chcesz, aby Twoja pamięć podręczna przetrwała restart, pozwala ci to również zrobić. W rzeczywistości, to jest domyślne.

Jest też super szybki, często ograniczony przepustowością sieci lub pamięci.

Jeśli jedna instancja redis / memcached nie wystarczy wydajność dla Twojego obciążenia, redis jest oczywistym wyborem. Redis zawiera obsługę klastra i jest wyposażony w narzędzia wysokiej dostępności (redis-sentinel ) bezpośrednio "w pudełku". W ciągu ostatnich kilku lat redis stał się również wyraźnym liderem w narzędziach stron trzecich. Firmy takie jak Redis Labs, Amazon i inne oferują wiele przydatnych narzędzi i usług redis. Ekosystem wokół redis jest znacznie większy. Liczba wdrożeń na dużą skalę jest obecnie prawdopodobnie większa niż w przypadku memcached.

The Redis Superset

Redis to coś więcej niż pamięć podręczna. Jest to serwer struktury danych w pamięci. Poniżej znajdziesz Szybki przegląd rzeczy, które Redis może zrobić poza byciem prostym kluczem / wartością cache, takim jak memcached. Większość funkcji redisa to rzeczy, których memcached nie potrafi.

Dokumentacja

Redis jest lepiej udokumentowany niż memcached. Chociaż może to być subiektywne, wydaje się być coraz bardziej prawdziwe przez cały czas.

Redis.io jest fantastyczny, łatwy w nawigacji zasób. Pozwala ona wypróbować redis w przeglądarce , a nawet daje interaktywne przykłady na żywo za pomocą każdego polecenia w dokumentach.

Jest teraz 2x więcej wyników stoskoverflow dla redis niż memcached. 2x tyle wyników Google. Łatwiej dostępne przykłady w większej liczbie języków. Bardziej aktywny rozwój. Bardziej aktywny rozwój klienta. Pomiary te mogą nie wiele znaczyć indywidualnie, ale w połączeniu tworzą wyraźny obraz, który wspiera i dokumentacja redis jest większa i znacznie bardziej aktualna.

Trwałość

Domyślnie redis przechowuje dane na dysku za pomocą mechanizmu zwanego snapshotting. Jeśli masz wystarczającą ilość dostępnej pamięci RAM, możesz zapisać wszystkie dane na dysk prawie bez pogorszenia wydajności. To prawie za darmo!

W trybie migawki istnieje szansa, że nagła awaria może spowodować niewielką ilość utraconych danych. Jeśli koniecznie musisz upewnić się, że żadne dane nie zostaną utracone, nie martw się, redis ma też swoje plecy z trybem AoF (Dołącz tylko plik). W tym trybie trwałości DANE mogą być synchronizowane z dyskiem w trakcie zapisu. Może to zmniejszyć maksymalną przepustowość zapisu do prędkości zapisu na dysku, ale nadal powinna być dość szybka.

Istnieje wiele opcji konfiguracyjnych, aby dostroić trwałość, jeśli potrzebujesz, ale domyślne ustawienia są bardzo rozsądne. Te opcje ułatwiają konfigurację redis jako bezpiecznego, nadmiarowego miejsca do przechowywania danych. To jest prawdziwe baza danych.

Wiele Typów Danych

Memcached jest ograniczony do łańcuchów znaków, ale Redis jest serwerem struktury danych, który może obsługiwać wiele różnych typów danych. Zapewnia również polecenia potrzebne do maksymalnego wykorzystania tych typów danych.

Strings (commands )

Proste wartości tekstowe lub binarne, które mogą mieć rozmiar do 512 MB. Jest to jedyny typ danych redis i Memcached share, chociaż Memcached strings są ograniczone do 1MB.

Redis daje więcej narzędzi do wykorzystania tego typu danych poprzez oferowanie poleceń dla operacji bitowych, manipulacji na poziomie bitowym, obsługi przyrostu/zmniejszania zmiennoprzecinkowego, zapytań zakresowych i operacji z wieloma kluczami. Memcached nie obsługuje żadnego z nich.

Łańcuchy są użyteczne dla różnego rodzaju przypadków użycia, dlatego memcached jest dość przydatny tylko dla tego typu danych.

Hashes (komendy )

Hasze są czymś w rodzaju magazynu wartości klucza wewnątrz magazynu wartości klucza. Mapa między strunami pola i wartości łańcuchowe. Field - >maps value using a hash są nieco bardziej przestrzenne niż key - >maps value using regular strings.

Hasze są przydatne jako przestrzeń nazw lub gdy chcesz logicznie grupować wiele kluczy. Dzięki hashowi możesz skutecznie przechwycić wszystkich członków, wygasnąć wszystkich członków razem, usunąć wszystkich członków razem, itp. Świetnie nadaje się do każdego przypadku użycia, w którym masz kilka par klucz/wartość, które muszą być pogrupowane.

Jednym z przykładów użycia hasha jest przechowywanie użytkownika profile między aplikacjami. Skrót redis przechowywany z identyfikatorem użytkownika jako kluczem pozwoli Ci przechowywać tyle bitów danych o użytkowniku, ile potrzebujesz, zachowując je pod jednym kluczem. Zaletą używania skrótu zamiast serializacji profilu w ciąg jest to, że różne aplikacje mogą odczytywać/zapisywać różne pola w profilu użytkownika bez martwienia się o to, że jedna aplikacja nadpisuje zmiany dokonane przez inne (co może się zdarzyć, jeśli serializujesz stare pola danych).

Lists ( commands )

Listy Redis są uporządkowanymi zbiorami łańcuchów. Są one zoptymalizowane pod kątem wstawiania, odczytu lub usuwania wartości z górnej lub dolnej części listy.

Redis dostarcza wiele poleceń do wykorzystania list, w tym poleceń push/pop elementów, push/pop między listami, obcinania list, wykonywania zapytań zakresu, itp.

Listy sprawiają, że wielkie, trwałe, atomowe, kolejki. Świetnie sprawdzają się w kolejkach do pracy, dzienniki, bufory i wiele innych przypadków użycia.

Sets ( commands )

Zbiory są nieuporządkowanymi zbiorami unikalnych wartości. Są one zoptymalizowane, aby umożliwić szybkie sprawdzenie, czy wartość znajduje się w zestawie, szybkie dodawanie/usuwanie wartości i mierzenie nakładania się z innymi zestawami.

Są świetne do takich rzeczy, jak listy kontroli dostępu, unikalne trackery odwiedzających i wiele innych rzeczy. Większość języków programowania ma coś podobnego (zwykle nazywa się to zestawem). To jest tak, tylko rozproszone.

Redis dostarcza kilka poleceń do zarządzania zestawami. Oczywiste, takie jak dodawanie, usuwanie i sprawdzanie zestawu są obecne. Podobnie są mniej oczywiste polecenia, takie jak popping/czytanie losowego elementu i polecenia do wykonywania połączeń i przecięć z innymi zestawami.

Sortowane Zestawy ( polecenia )

Sortowane zbiory są również zbiorami unikalnych wartości. Te, jak sama nazwa wskazuje, są uporządkowane. Są one uporządkowane według wyniku, a następnie leksykograficznie.

Ten typ danych jest zoptymalizowany do szybkiego wyszukiwania według wyniku. Uzyskanie najwyższego, najniższego lub dowolnego zakresu wartości pomiędzy nimi jest niezwykle szybkie.

Jeśli dodasz użytkowników do sortowanego zestawu wraz z ich wysokim wynikiem, masz idealną tablicę liderów. Gdy pojawią się nowe wysokie wyniki, po prostu dodaj je ponownie do zestawu z ich wysokim wynikiem, a to ponownie uporządkuje Twoją tablicę liderów. Świetnie nadaje się również do śledzenia ostatnio odwiedzanych użytkowników i tego, kto jest aktywny w Twoim podanie.

Przechowywanie wartości z tym samym wynikiem powoduje, że są one uporządkowane leksykograficznie (myśl Alfabetycznie). Może to być przydatne w przypadku funkcji automatycznego uzupełniania.

Wiele poleceń sortowanego zestawu jest podobnych do poleceń dla zestawów, czasami z dodatkowym parametrem score. Dołączone są również polecenia do zarządzania wynikami i zapytań według wyniku.

Geo

Redis posiada kilka poleceń do przechowywania, pobierania i pomiar danych geograficznych. Obejmuje To zapytania o Promień i pomiar odległości między punktami.

Technicznie Dane geograficzne w redis są przechowywane w posortowanych zestawach, więc nie jest to naprawdę oddzielny typ danych. Jest to bardziej rozszerzenie na górze sortowanych zestawów.

Bitmap i Hyperlog

Podobnie jak geo, nie są to całkowicie oddzielne typy danych. Są to polecenia, które pozwalają traktować dane ciągów tak, jakby były bitmapą lub hiperlogiem.

Bitmapy to co operatory poziomu bitowego, o których wspomniałem w Strings, są dla. Ten typ danych był podstawowym budulcem dla niedawnego wspólnego projektu artystycznego reddit: r / Place {62]}.

HyperLogLog pozwala na wykorzystanie stałej, bardzo małej ilości miejsca do liczenia niemal nieograniczonych unikalnych wartości z szokującą dokładnością. Używając tylko ~16KB możesz skutecznie policzyć liczbę unikalnych użytkowników twojej witryny, nawet jeśli liczba ta jest w milionach.

Transakcje i Atomicity

Polecenia w redis są atomowe, co oznacza, że możesz być pewien, że gdy tylko napiszesz wartość do redis, wartość ta będzie widoczna dla wszystkich klientów podłączonych do redis. Nie ma czekania na propagację tej wartości. Technicznie memcached jest również atomowy, ale z redis dodając wszystkie te funkcje poza memcached, warto zauważyć i nieco imponujące, że wszystkie te dodatkowe typy danych i funkcje są również atomowe.

Choć nie do końca takie same jak transakcje w relacyjnych baz danych, redis ma również transakcje {[62] } które używają "optymistycznego blokowania" (zobacz/MULTI/EXEC ).

Pipelining

Redis udostępnia funkcję o nazwie " pipelining ". Jeśli masz wiele poleceń redis, które chcesz wykonać, możesz użyć pipelining, aby wysłać je do redis all-at-once zamiast one-at-a-time.

Zwykle gdy wykonujesz polecenie redis lub memcached, każde polecenie jest oddzielnym cykl żądania / odpowiedzi. Dzięki pipelining, redis może buforować kilka poleceń i wykonywać je wszystkie jednocześnie, odpowiadając wszystkimi odpowiedziami na wszystkie Twoje polecenia w jednej odpowiedzi.

Pozwala to na osiągnięcie jeszcze większej przepustowości przy importowaniu zbiorczym lub innych akcjach obejmujących wiele poleceń.

Pub / Sub

Redis posiada komendy dedykowane do funkcji pub/sub, dzięki czemu redis może działać jako nadawca wiadomości o dużej prędkości. To pozwala pojedynczemu klientowi publikować wiadomości do wielu innych klientów podłączonych do kanału. Redis robi pub/sub, jak również prawie każde narzędzie. Dedykowane brokery wiadomości, takie jak RabbitMQ {62]} mogą mieć zalety w niektórych obszarach, ale fakt, że ten sam serwer może również zapewnić trwałe, trwałe kolejki i inne struktury danych, których prawdopodobnie potrzebujesz, Redis często okaże się najlepszym i najprostszym narzędziem do tego zadania.

Lua Scripting

Możesz pomyśl o skryptach lua , takich jak własny SQL redis lub procedury przechowywane. To i więcej, i mniej, ale analogia w większości działa.

Być może masz złożone obliczenia, które chcesz wykonać redis. Być może nie możesz sobie pozwolić na cofnięcie transakcji i potrzebujesz gwarancji, że każdy krok złożonego procesu wydarzy się atomicznie. Te i wiele innych problemów można rozwiązać za pomocą skryptów lua.

Cały skrypt jest wykonywany atomicznie, więc jeśli zmieścisz swój logika w skrypcie lua często można uniknąć bałaganu z optymistycznymi transakcjami blokującymi.

Skalowanie

Jak wspomniano powyżej, redis zawiera wbudowaną obsługę klastrowania i jest dostarczany z własnym narzędziem wysokiej dostępności o nazwie redis-sentinel.

Podsumowanie

Bez wahania polecam redis nad memcached dla nowych projektów lub istniejących projektów, które jeszcze nie używają memcached.

Powyższe może brzmieć tak, jakbym nie lubił memcached. Wręcz przeciwnie.: jest to potężne, proste, stabilne, dojrzałe i utwardzone narzędzie. Istnieją nawet przypadki użycia, w których jest to trochę szybsze niż redis. Uwielbiam memcached. Myślę, że to nie ma sensu dla przyszłego rozwoju.

Redis robi wszystko, co memcached, często lepiej. Każda przewaga wydajnościowa memcached jest niewielka i specyficzna dla danego obciążenia. Istnieją również obciążenia, dla których redis będzie szybszy, i wiele więcej obciążeń, które redis może zrobić, a memcached po prostu nie może. mała wydajność różnice wydają się niewielkie w obliczu gigantycznej przepaści w funkcjonalności i faktu, że oba narzędzia są tak szybkie i wydajne, że mogą być ostatnim elementem Twojej infrastruktury, o którą będziesz musiał się martwić.

Jest tylko jeden scenariusz, w którym Memcached ma większy sens: gdzie memcached jest już używany jako pamięć podręczna. Jeśli już buforujesz za pomocą memcached, używaj go dalej, jeśli spełnia Twoje potrzeby. Prawdopodobnie nie jest warte wysiłku, aby przejść do redis i jeśli jesteś korzystanie z redis tylko do buforowania może nie oferować wystarczających korzyści, aby było warte twojego czasu. Jeśli memcached nie spełnia Twoich potrzeb, prawdopodobnie powinieneś przejść do redis. Jest to prawdą niezależnie od tego, czy musisz skalować się poza memcached, czy potrzebujesz dodatkowej funkcjonalności.