MongoDB z Redis

Czy ktoś może podać przykładowe przypadki użycia, w których przydałoby się używanie Redis i MongoDB w połączeniu ze sobą?

Redis i MongoDB mogą być używane razem z dobrymi wynikami. Firmą znaną z prowadzenia MongoDB i Redis (wraz z MySQL i Sphinx) jest Craiglist. Zobacz prezentację Jeremy'ego Zawodnego.

MongoDB jest interesujący ze względu na trwałe, zorientowane na dokumenty dane indeksowane na różne sposoby. Usługa Redis jest bardziej interesująca w przypadku danych nietrwałych lub półtrwałych danych wrażliwych na opóźnienia.

Oto kilka przykładów konkretnego wykorzystania Redis w połączeniu z MongoDB.

• MongoDB w wersji starszej niż 2.2 nie ma jeszcze mechanizmu wygaśnięcia. Kolekcje ograniczone nie mogą być używane do implementacji prawdziwego TTL. Redis ma mechanizm wygaśnięcia oparty na TTL, co ułatwia przechowywanie ulotnych danych. Na przykład sesje użytkowników są zwykle przechowywane w Redis, podczas gdy dane użytkownika będą przechowywane i indeksowane w MongoDB. Należy zauważyć, że MongoDB 2.2 wprowadził mechanizm utraty ważności o niskiej dokładności na poziomie zbierania danych (np. Do czyszczenia danych).

• Redis zapewnia wygodny zestaw typów danych i powiązane z nim operacje (suma, przecięcie, różnica w wielu zestawach itp.). Dość łatwo jest zaimplementować podstawowy, aspektowy mechanizm wyszukiwania lub tagowania oprócz tej funkcji, co jest interesującym dodatkiem do bardziej tradycyjnych funkcji indeksowania MongoDB.

• Redis obsługuje wydajne blokowanie operacji typu pop na listach. Można to wykorzystać do zaimplementowania rozproszonego systemu kolejkowania ad hoc. Jest bardziej elastyczny niż kursory IMO w MongoDB, ponieważ aplikacja zaplecza może nasłuchiwać kilku kolejek z przekroczeniem limitu czasu, niepodzielnie przesyłać elementy do innej kolejki itp. Jeśli aplikacja wymaga kolejkowania, warto przechowywać kolejkę w Redis i przechowuj trwałe dane funkcjonalne w MongoDB.

• Redis oferuje również mechanizm pub / sub. W aplikacji rozproszonej przydatny może być system propagacji zdarzeń. To znowu doskonały przypadek użycia Redis, podczas gdy trwałe dane są przechowywane w MongoDB.

Ponieważ zaprojektowanie modelu danych w MongoDB jest znacznie łatwiejsze niż w przypadku Redis (Redis jest bardziej niskopoziomowy), warto skorzystać z elastyczności MongoDB dla głównych trwałych danych oraz z dodatkowych funkcji zapewnianych przez Redis (małe opóźnienie , wygaśnięcie pozycji, kolejki, pub / sub, bloki atomowe itp.). To rzeczywiście dobra kombinacja.

Pamiętaj, że nigdy nie powinieneś uruchamiać serwera Redis i MongoDB na tym samym komputerze. Pamięć MongoDB jest przeznaczona do wymiany, Redis nie. Jeśli MongoDB uruchomi jakąś aktywność wymiany, wydajność Redis będzie katastrofalna. Powinny być izolowane w różnych węzłach.

Oczywiście różnic jest znacznie więcej, ale dla bardzo wysokiego przeglądu:

Do przypadków użycia:

• Redis jest często używany jako warstwa pamięci podręcznej lub udostępniona tablica do obliczeń rozproszonych.
• MongoDB jest często używany jako zamiennik dla tradycyjnych baz danych SQL.

Technicznie:

• Redis to baza danych w pamięci z trwałością dysku (cała baza danych musi mieścić się w pamięci RAM).
• MongoDB to baza danych oparta na dysku, która potrzebuje tylko wystarczającej ilości pamięci RAM dla indeksów.

Istnieje pewne nakładanie się, ale niezwykle powszechne jest używanie obu. Dlatego:

• MongoDB może przechowywać więcej danych taniej.
• Redis jest szybszy dla całego zbioru danych.
• Kultura MongoDB to „przechowywanie wszystkiego, później ustalanie wzorców dostępu”
• Kultura Redis polega na „uważnym rozważeniu sposobu uzyskiwania dostępu do danych, a następnie ich przechowywania”
• Oba mają narzędzia open source, które są od nich zależne, a wiele z nich jest używanych razem.

Redis może być używany jako zamiennik dla tradycyjnego magazynu danych, ale najczęściej jest używany z innym normalnym „długim” magazynem danych, takim jak Mongo, Postgresql, MySQL itp.

Redis doskonale współpracuje z MongoDB jako serwerem buforującym. Oto, co się dzieje.

Za każdym razem, gdy mangusta wysyła zapytanie do pamięci podręcznej, najpierw przechodzi do serwera pamięci podręcznej.

Serwer pamięci podręcznej sprawdzi, czy dokładnie to zapytanie zostało kiedykolwiek wysłane.

Jeśli tak nie jest, serwer pamięci podręcznej przyjmie zapytanie, wyśle ​​je do mongodb, a Mongo wykona zapytanie.

Następnie weźmiemy wynik tego zapytania, a następnie wrócimy do serwera pamięci podręcznej, serwer pamięci podręcznej zapisze wynik zapytania na sobie.

Powie za każdym razem, gdy wykonam to zapytanie, otrzymam tę odpowiedź, a więc zachowa zapis między wysłanymi zapytaniami a odpowiedziami, które wrócą z tych zapytań.

Serwer pamięci podręcznej przyjmie odpowiedź i odeśle ją z powrotem do mangusty, mongoose da ją do wyrażenia i ostatecznie trafi do aplikacji.

Za każdym razem, gdy ponownie zostanie wysłane to samo dokładne zapytanie, mongoose wyśle ​​to samo zapytanie do serwera pamięci podręcznej, ale jeśli serwer pamięci podręcznej zobaczy, że to zapytanie zostało wysłane przed wysłaniem zapytania do mongodb, zamiast tego przyjmie odpowiedź do zapytanie, które otrzymało ostatnim razem i natychmiast odeślij je z powrotem do mangusty. Nie ma tu indeksów, pełnego skanu tabeli, nic.

Robimy proste wyszukiwanie, aby stwierdzić, czy to zapytanie zostało wykonane? Tak? OK, weź prośbę i odeślij ją natychmiast i nie wysyłaj niczego do mongo.

Mamy serwer mongoose, serwer cache (Redis) i Mongodb.

Na serwerze pamięci podręcznej może istnieć magazyn danych z magazynem danych typu klucz-wartość, w którym wszystkie klucze są pewnego rodzaju zapytaniem wysłanym wcześniej, a wartość jest wynikiem tego zapytania.

Może więc szukamy kilku postów na blogu autorstwa _id.

Więc może klucze tutaj są _id rekordów, które szukaliśmy wcześniej.

Wyobraźmy sobie więc, że mongoose wysyła nowe zapytanie, w którym próbuje znaleźć post na blogu o identyfikatorze _id równym 123, zapytanie przepływa do serwera pamięci podręcznej, serwer pamięci podręcznej sprawdza, czy ma wynik dla dowolnego zapytania szukającego identyfikatora _id z 123.

Jeśli nie istnieje na serwerze pamięci podręcznej, to zapytanie jest pobierane i wysyłane do instancji mongodb. Mongodb wykona zapytanie, otrzyma odpowiedź i odeśle ją z powrotem.

Wynik ten jest przesyłany z powrotem do serwera pamięci podręcznej, który pobiera ten wynik i natychmiast przesyła go z powrotem do mangusty, abyśmy otrzymali możliwie najszybszą odpowiedź.

Zaraz po tym serwer pamięci podręcznej również przyjmie wysłane zapytanie i doda je do swojego zbioru zapytań, które zostały wysłane, a następnie przyjmie wynik zapytania i zapisze go bezpośrednio w zapytaniu.

Możemy więc sobie wyobrazić, że w przyszłości ponownie wysyłamy to samo zapytanie, trafia ono do serwera pamięci podręcznej, sprawdza wszystkie posiadane przez niego klucze i mówi oh, już znalazłem ten post na blogu, nie dociera do mongo, wystarczy wynik zapytania i wysyła go bezpośrednio do mangusty.

Nie wykonujemy skomplikowanej logiki zapytań, żadnych indeksów, nic takiego. Jest tak szybko, jak to możliwe. Jest to proste wyszukiwanie wartości klucza.

To jest przegląd tego, jak serwer pamięci podręcznej (Redis) współpracuje z MongoDB.

Teraz są inne obawy. Czy przechowujemy dane na zawsze? Jak aktualizujemy rekordy?

Nie chcemy zawsze przechowywać dane w pamięci podręcznej i czytać z pamięci podręcznej.

Serwer pamięci podręcznej nie jest używany do żadnych działań zapisu. Warstwa pamięci podręcznej służy tylko do odczytu danych. Jeśli kiedykolwiek zapiszemy dane, zapis zawsze przejdzie do instancji mongodb i musimy upewnić się, że za każdym razem, gdy zapisujemy dane, usuwamy wszelkie dane przechowywane na serwerze pamięci podręcznej, które są powiązane z rekordem, który właśnie zaktualizowaliśmy w Mongo.