Dlaczego Redis pokonuje Memcached w zakresie buforowania

Memcached czy Redis? Jest to pytanie, które prawie zawsze pojawia się w każdej dyskusji na temat wyciskania większej wydajności z nowoczesnej aplikacji internetowej opartej na bazie danych. Gdy wydajność wymaga poprawy, buforowanie jest często pierwszym krokiem, a Memcached lub Redis są zwykle pierwszymi miejscami, w których należy się zwrócić.

Te znane silniki pamięci podręcznej mają wiele podobieństw, ale mają też istotne różnice. Redis, nowszy i bardziej wszechstronny z tych dwóch, jest prawie zawsze lepszym wyborem.

Redis vs. Memcached do buforowania

Zacznijmy od podobieństw. Zarówno Memcached, jak i Redis służą jako magazyny danych klucz-wartość w pamięci, chociaż Redis jest dokładniej opisywany jako magazyn struktury danych. Zarówno Memcached, jak i Redis należą do rodziny rozwiązań do zarządzania danymi NoSQL i oba są oparte na modelu danych klucz-wartość. Obaj przechowują wszystkie dane w pamięci RAM, co oczywiście czyni je niezwykle przydatnymi jako warstwa pamięci podręcznej. Pod względem wydajności oba magazyny danych są również niezwykle podobne, wykazując prawie identyczne cechy (i metryki) w odniesieniu do przepustowości i opóźnienia.

Zarówno Memcached, jak i Redis są dojrzałymi i niezwykle popularnymi projektami open source. Memcached został pierwotnie opracowany przez Brada Fitzpatricka w 2003 roku dla serwisu LiveJournal. Od tego czasu Memcached został przepisany w języku C (oryginalna implementacja znajdował się w Perlu) i udostępniony publicznie, gdzie stał się kamieniem węgielnym nowoczesnych aplikacji internetowych. Obecny rozwój Memcached koncentruje się na stabilności i optymalizacji, a nie na dodawaniu nowych funkcji.

Redis został stworzony przez Salvatore Sanfilippo w 2009 roku, a Sanfilippo pozostaje głównym deweloperem projektu. Redis jest czasami opisywany jako „Memcached na sterydach”, co nie jest zaskakujące, biorąc pod uwagę, że części Redis zostały zbudowane w odpowiedzi na wnioski wyciągnięte z używania Memcached. Redis ma więcej funkcji niż Memcached, dzięki czemu jest bardziej wydajny i elastyczny.

Używane przez wiele firm iw niezliczonych środowiskach produkcyjnych o znaczeniu krytycznym, zarówno Memcached, jak i Redis są obsługiwane przez biblioteki klienckie w każdym możliwym języku programowania i są zawarte w wielu pakietach dla programistów. W rzeczywistości jest to rzadki stos sieciowy, który nie obejmuje wbudowanej obsługi Memcached ani Redis.

Dlaczego Memcached i Redis są tak popularne? Są nie tylko niezwykle skuteczne, ale także stosunkowo proste. Rozpoczęcie pracy z Memcached lub Redis jest uważane za łatwą pracę dla programisty. Konfiguracja i uruchomienie aplikacji zajmuje tylko kilka minut. W związku z tym niewielka inwestycja czasu i wysiłku może mieć natychmiastowy, dramatyczny wpływ na wydajność - zwykle o rzędy wielkości. Proste rozwiązanie z ogromną korzyścią; to jest tak bliskie magii, jak tylko możesz.

Kiedy używać Memcached

Memcached może być preferowanym rozwiązaniem w przypadku buforowania stosunkowo małych i statycznych danych, takich jak fragmenty kodu HTML. Zarządzanie pamięcią wewnętrzną Memcached, chociaż nie jest tak wyrafinowane jak w przypadku Redis, jest bardziej wydajne w najprostszych przypadkach użycia, ponieważ zużywa stosunkowo mniej zasobów pamięci na metadane. Ciągi znaków (jedyny typ danych obsługiwany przez Memcached) są idealne do przechowywania danych, które są tylko odczytywane, ponieważ nie wymagają one dalszego przetwarzania.

Duże zestawy danych często obejmują dane serializowane, które zawsze wymagają więcej miejsca do przechowywania. Podczas gdy Memcached ogranicza się do przechowywania danych w postaci serializowanej, struktury danych w Redis mogą przechowywać każdy aspekt danych natywnie, zmniejszając w ten sposób narzut serializacji.

Drugi scenariusz, w którym Memcached ma przewagę nad Redis, dotyczy skalowania. Ponieważ Memcached jest wielowątkowy, możesz łatwo skalować w górę, udostępniając mu więcej zasobów obliczeniowych, ale stracisz część lub całość danych w pamięci podręcznej (w zależności od tego, czy używasz spójnego haszowania). Usługa Redis, która jest głównie jednowątkowa, może skalować się w poziomie za pomocą klastrowania bez utraty danych. Tworzenie klastrów jest skutecznym rozwiązaniem skalującym, ale jego konfiguracja i obsługa jest stosunkowo bardziej skomplikowana.

Kiedy używać Redis

Prawie zawsze będziesz chciał używać Redis ze względu na jego struktury danych. Korzystając z Redis jako pamięci podręcznej, zyskujesz dużą moc (na przykład możliwość dostrojenia zawartości pamięci podręcznej i trwałości) i ogólną większą wydajność. Po użyciu struktur danych wzrost wydajności staje się ogromny w przypadku określonych scenariuszy aplikacji.

Przewaga Redis jest widoczna w prawie każdym aspekcie zarządzania pamięcią podręczną. Pamięci podręczne wykorzystują mechanizm zwany eksmisją danych, aby zrobić miejsce na nowe dane, usuwając stare dane z pamięci. Mechanizm eksmisji danych Memcached wykorzystuje algorytm najmniej ostatnio używanych i nieco arbitralnie eksmituje dane, które mają podobny rozmiar do nowych danych.

Z kolei Redis umożliwia precyzyjną kontrolę nad eksmisją, umożliwiając wybór spośród sześciu różnych zasad eksmisji. Redis stosuje również bardziej wyrafinowane podejście do zarządzania pamięcią i selekcji kandydatów do eksmisji. Redis obsługuje zarówno leniwą, jak i aktywną eksmisję, w której dane są eksmitowane tylko wtedy, gdy potrzeba więcej miejsca lub aktywnie. 

Redis zapewnia znacznie większą elastyczność w zakresie obiektów, które można buforować. Podczas gdy Memcached ogranicza nazwy kluczy do 250 bajtów i działa tylko ze zwykłymi ciągami, Redis pozwala na to, aby nazwy kluczy i wartości były tak duże, jak 512 MB każdy, i są one bezpieczne binarnie. Ponadto Redis ma do wyboru pięć podstawowych struktur danych, otwierając przed twórcami aplikacji świat możliwości dzięki inteligentnemu buforowaniu i manipulowaniu danymi w pamięci podręcznej.

Redis dla trwałości danych

Korzystanie ze struktur danych Redis może uprościć i zoptymalizować kilka zadań - nie tylko podczas buforowania, ale nawet wtedy, gdy chcesz, aby dane były trwałe i zawsze dostępne. Na przykład zamiast przechowywać obiekty jako ciągi serializowane, programiści mogą używać skrótu Redis do przechowywania pól i wartości obiektu oraz zarządzać nimi przy użyciu jednego klucza. Redis Hash oszczędza programistom konieczności pobierania całego ciągu, deserializacji go, aktualizowania wartości, ponownego zerializowania obiektu i zastępowania całego ciągu w pamięci podręcznej nową wartością dla każdej trywialnej aktualizacji - oznacza to mniejsze zużycie zasobów i zwiększoną wydajność.

Inne struktury danych oferowane przez Redis (takie jak listy, zbiory, posortowane zbiory, hiperlogogi, mapy bitowe i indeksy geoprzestrzenne) mogą być używane do wdrażania jeszcze bardziej złożonych scenariuszy. Posortowane zestawy do pozyskiwania i analizy danych szeregów czasowych to kolejny przykład struktury danych Redis, która oferuje znacznie zmniejszoną złożoność i mniejsze zużycie przepustowości.

Inną ważną zaletą Redis jest to, że przechowywane dane nie są nieprzezroczyste, więc serwer może nimi bezpośrednio manipulować. Znaczna część z ponad 180 poleceń dostępnych w Redis jest poświęcona operacjom przetwarzania danych i osadzaniu logiki w samym magazynie danych za pośrednictwem skryptów Lua po stronie serwera. Te wbudowane polecenia i skrypty użytkownika zapewniają elastyczność obsługi zadań przetwarzania danych bezpośrednio w Redis, bez konieczności przesyłania danych przez sieć do innego systemu w celu przetworzenia.

Redis oferuje opcjonalną i dostosowywalną trwałość danych, zaprojektowaną w celu załadowania pamięci podręcznej po planowanym zamknięciu lub nieplanowanej awarii. Chociaż zwykle traktujemy dane w pamięci podręcznej jako ulotne i przejściowe, utrwalanie danych na dysku może być bardzo cenne w scenariuszach buforowania. Posiadanie danych pamięci podręcznej dostępnych do załadowania natychmiast po ponownym uruchomieniu pozwala na znacznie krótsze rozgrzewanie pamięci podręcznej i usuwa obciążenie związane z ponownym zapełnianiem i przeliczaniem zawartości pamięci podręcznej z podstawowego magazynu danych.

Replikacja danych w pamięci Redis 

Redis może również replikować dane, którymi zarządza. Replikację można wykorzystać do wdrożenia konfiguracji pamięci podręcznej o wysokiej dostępności, która jest odporna na awarie i zapewnia nieprzerwaną obsługę aplikacji. Awaria pamięci podręcznej jest tylko nieznacznie niższa od awarii aplikacji pod względem wpływu na wrażenia użytkownika i wydajność aplikacji, więc posiadanie sprawdzonego rozwiązania, które gwarantuje zawartość pamięci podręcznej i dostępność usług, jest w większości przypadków główną zaletą.

Wreszcie, jeśli chodzi o widoczność operacyjną, Redis zapewnia mnóstwo wskaźników i bogactwo introspektywnych poleceń, za pomocą których można monitorować i śledzić użycie i nietypowe zachowanie. Statystyki w czasie rzeczywistym dotyczące każdego aspektu bazy danych, wyświetlanie wszystkich wykonywanych poleceń, lista i zarządzanie połączeniami klientów - Redis ma to wszystko i więcej.

Gdy programiści zdają sobie sprawę z efektywności trwałości i możliwości replikacji w pamięci Redis, często używają jej jako bazy danych pierwszego reagowania, zwykle do analizowania i przetwarzania danych o dużej szybkości oraz udzielania odpowiedzi użytkownikowi, podczas gdy pomocnicza (często wolniejsza) baza danych utrzymuje historyczny zapis tego, co się wydarzyło. Użyty w ten sposób Redis może być również idealny do zastosowań analitycznych.

Redis do analizy danych

Natychmiast przychodzą na myśl trzy scenariusze analityczne. W pierwszym scenariuszu, gdy używasz czegoś takiego jak Apache Spark do iteracyjnego przetwarzania dużych zestawów danych, możesz użyć Redis jako warstwy obsługującej dane wcześniej obliczone przez Spark. W drugim scenariuszu użycie Redis jako współdzielonego, rozproszonego magazynu danych w pamięci może przyspieszyć szybkość przetwarzania Spark o współczynnik 45 do 100. Wreszcie, zbyt powszechnym scenariuszem jest taki, w którym raporty i analizy muszą być dostosowywane przez użytkownika, ale pobieranie danych z wewnętrznych magazynów danych wsadowych (takich jak Hadoop lub RDBMS) trwa zbyt długo. W takim przypadku magazyn struktury danych w pamięci, taki jak Redis, jest jedynym praktycznym sposobem uzyskania czasu stronicowania i odpowiedzi poniżej milisekundy.

W przypadku korzystania z bardzo dużych zestawów danych operacyjnych lub obciążeń analitycznych uruchamianie wszystkiego w pamięci może nie być opłacalne. Aby osiągnąć wydajność poniżej milisekundy przy niższych kosztach, Redis Labs stworzył wersję Redis, która działa w połączeniu z pamięcią RAM i pamięcią flash, z opcją konfigurowania proporcji pamięci RAM do pamięci flash. Otwiera to kilka nowych możliwości przyspieszenia przetwarzania obciążenia, ale daje programistom możliwość prostego uruchomienia „pamięci podręcznej na pamięci flash”.

Oprogramowanie typu open source nadal zapewnia jedne z najlepszych dostępnych obecnie technologii. Jeśli chodzi o zwiększanie wydajności aplikacji poprzez buforowanie, Redis i Memcached są najbardziej uznanymi i sprawdzonymi w produkcji kandydatami. Jednak biorąc pod uwagę bogatszą funkcjonalność Redis, bardziej zaawansowany projekt, wiele potencjalnych zastosowań i większą efektywność kosztową na dużą skalę, Redis powinien być pierwszym wyborem w prawie każdym przypadku.

---

Itamar Haber (@itamarhaber) jest głównym rzecznikiem programistów w Redis Labs, która oferuje Memcached i Redis jako w pełni zarządzane usługi chmurowe dla programistów. Jego różnorodne doświadczenie obejmuje tworzenie oprogramowania i zarządzanie nimi oraz role kierownicze w Xeround, Etagon, Amicada i MNS Ltd. Itamar posiada tytuł Master of Business Administration na wspólnym programie Kellogg-Recanati na uniwersytetach Northwestern i Tel-Aviv, a także tytuł licencjata nauk ścisłych w dziedzinie informatyki.

New Tech Forum to miejsce, w którym można badać i omawiać pojawiające się technologie dla przedsiębiorstw na niespotykaną dotąd skalę i dogłębnie. Wybór jest subiektywny, oparty na naszym wyborze technologii, które uważamy za ważne i najbardziej interesujące dla czytelników. nie przyjmuje marketingowych materiałów reklamowych do publikacji i zastrzega sobie prawo do edycji wszystkich przesłanych treści. Wszelkie zapytania należy kierować na adres [email protected]