Właśnie zauważyłem, że to pytanie jest dość stare. Niemniej jednak uważam, że warto dodać następujące aspekty:

• Użyj MongoDB, jeśli nie wiesz jeszcze, w jaki sposób chcesz odpytywać swoje dane.

  MongoDB nadaje się do hackathonów, startupów lub za każdym razem, gdy nie wiesz, jak odpytywać wprowadzone dane. MongoDB nie przyjmuje żadnych założeń dotyczących podstawowego schematu. Chociaż MongoDB jest bez schematów i nie relacyjny, nie oznacza to, że nie ma schematu w wszystkie. Oznacza to po prostu, że twój schemat musi być zdefiniowany w aplikacji (np. za pomocą mangusty). Poza tym MongoDB świetnie nadaje się do prototypowania lub testowania. Jego wydajność nie jest tak wielka i nie może być porównywana do Redis.

• Użyj Redis, aby przyspieszyć istniejącą aplikację.

  Redis można łatwo zintegrować jako LRU cache. Bardzo rzadko używa się Redis jako samodzielnego systemu bazodanowego (niektórzy wolą nazywać go "key-value" - store). Strony takie jak Craigslist używają Redis obok swojej podstawowej bazy danych. Antirez (twórca Redis) zademonstrował przy użyciu Lamernews, że rzeczywiście możliwe jest użycie Redis jako samodzielnego systemu bazodanowego.

• Redis nie przyjmuje żadnych założeń na podstawie Twoich danych.

  Redis dostarcza kilka przydatnych struktur danych( np. zestawów, skrótów, list), ale musisz wyraźnie określić, w jaki sposób chcesz przechowywać dane. Krótko mówiąc, Redis i MongoDB może być używany w celu osiągnięcia podobnych rzeczy. Redis jest po prostu szybszy, ale nie nadaje się do prototypowania. To jeden przypadek użycia, w którym zazwyczaj preferujesz MongoDB. Poza tym Redis jest naprawdę elastyczny. Podstawowe struktury danych, które dostarcza, są elementami składowymi wysokowydajnych systemów DB.

Kiedy stosować Redis?

• Buforowanie

  Buforowanie przy użyciu MongoDB po prostu nie ma sensu. Byłoby zbyt powoli.

• Jeśli masz wystarczająco dużo czasu, aby pomyśleć o DB design.

  Nie możesz po prostu wrzucić swoich dokumentów do Redis. Musisz pomyśleć o tym, w jaki sposób chcesz przechowywać i organizować swoje dane. Jednym z przykładów są skróty w Redis. Różnią się one znacznie od "tradycyjnych" obiektów zagnieżdżonych, co oznacza, że musisz przemyśleć sposób przechowywania zagnieżdżonych dokumentów. Jednym z rozwiązań byłoby przechowywanie odniesienia wewnątrz hash do innego hash (coś w rodzaju klucza : [id drugiego hasha] ). Innym pomysłem byłoby przechowywanie go jako JSON, co wydaje się sprzeczne z intuicją dla większości osób z * SQL-tle.

• Jeśli potrzebujesz naprawdę wysokiej wydajności.

  Pokonanie wydajności Redis jest prawie niemożliwe. Wyobraź sobie, że baza danych jest tak szybka jak pamięć podręczna. To jest to, jak to jest używać Redis jako prawdziwej bazy danych.

• Jeśli cię to nie obchodzi to wiele o skalowaniu.

  Skalowanie Redis nie jest tak trudne, jak kiedyś. Na przykład można użyć pewnego rodzaju serwera proxy do dystrybucji danych między wieloma instancjami Redis. Replikacja Master-slave nie jest skomplikowana , ale Dystrybucja kluczy między wieloma instancjami Redis musi być wykonana w miejscu aplikacji(np. za pomocą funkcji hash, Modulo itp.). Skalowanie MongoDB przez porównanie jest znacznie prostsze.

• Prototypowanie, Startupy, Hackathony

  MongoDB doskonale nadaje się do szybkiego prototypowania. Niemniej jednak wydajność nie jest tak dobra. Należy również pamiętać, że najprawdopodobniej będziesz musiał zdefiniować jakiś schemat w swojej aplikacji.

• Kiedy trzeba szybko zmienić schemat.

  Ponieważ nie ma schematu! Zmiana tabel w tradycyjnych, relacyjnych systemach DBMS jest boleśnie kosztowna i powolna. MongoDB rozwiązuje ten problem, nie wprowadzając wielu założeń na temat podstawowych danych. Niemniej jednak, stara się zoptymalizować tak dalece, jak to możliwe, bez konieczności definiowania schematu.

TL; DR - Użyj Redis, jeśli wydajność jest ważna i chcesz poświęcić czas na optymalizację i organizowanie danych. - Użyj MongoDB, jeśli chcesz zbudować prototyp, nie martwiąc się zbytnio o swój DB.

Czytaj dalej:

• interesujące aspekty, które należy wziąć pod uwagę przy użyciu Redis jako podstawowego magazynu danych

Redis. Załóżmy, że napisałeś stronę w php; z jakiegokolwiek powodu staje się popularna i wyprzedza swój czas lub ma na niej porno. Zdajesz sobie sprawę, że to php jest tak cholernie wolne, " stracę swoich fanów, bo po prostu nie będą czekać 10 sekund na stronę."Nagle zdajesz sobie sprawę, że strona internetowa ma stały adres url (nigdy się nie zmienia, whoa), klucz podstawowy, jeśli chcesz, a potem przypominasz sobie, że pamięć jest szybka, podczas gdy dysk jest wolny, a php jest jeszcze wolniejszy. : (Wtedy można modyfikować magazyn mechanizm wykorzystujący pamięć i ten adres URL, który wywołujesz "kluczem", podczas gdy zawartość strony internetowej decydujesz się wywołać " wartość."To wszystko, co masz - klucz i treść. Nazywacie to " meme cache."Lubisz Richarda Dawkinsa, bo jest niesamowity. Buforujesz swój html jak wiewiórki buforują swoje orzechy. Nie musisz przepisywać swojego gównianego kodu php. Jesteś szczęśliwa. Potem widzisz, że inni to zrobili - ale wybierasz Redis, ponieważ drugi ma mylące obrazy kotów, niektóre z kłami.

Mongo. Masz napisał stronę. Heck napisałeś wiele, i w dowolnym języku. Zdajesz sobie sprawę, że większość czasu poświęcasz na pisanie tych śmierdzących klauzul SQL. Nie jesteś dba, a jednak piszesz głupie wypowiedzi sql... nie jeden, ale wszędzie. "wybierz to, wybierz tamto". Ale w szczególności pamiętasz irytującą klauzulę WHERE. Gdzie ostatnie imię równa się "thornton", a film równa się " Zły Mikołaj."Urgh. Myślisz: "dlaczego ci dba nie wykonają swojej pracy i nie dadzą mi procedur przechowywanych?" Potem zapominasz o jakimś podrzędnym polu, takim jak middleename, a następnie musisz upuścić tabelę, wyeksportować wszystkie 10g dużych danych i utworzyć kolejne z tym nowym polem, i zaimportować dane-i to dzieje się 10 razy w ciągu następnych 14 dni, gdy pamiętasz bzdury, takie jak pozdrowienie, tytuł, Plus dodanie obcego klucza z adresami. Wtedy domyślasz się, że lastname powinno być lastName. Prawie jedna zmiana dziennie. Więc mówisz darnit. Muszę się dostać i napisać stronę / system, nieważne ten model danych bs. Więc google, "nienawidzę pisać SQL, proszę nie SQL, sprawiają, że stop "ale wyskakuje "nosql", a następnie przeczytać kilka rzeczy i mówi, że po prostu zrzuca dane bez żadnego schematu. Pamiętasz zeszłotygodniowe fiasko zrzucające więcej stolików i uśmiechające się. Następnie wybierasz mongo, ponieważ niektórzy wielcy faceci, tacy jak "airbud", używają go w wypożyczalni apt. Słodko. Koniec ze zmianami modelu danych, ponieważ masz model, który po prostu ciągle się zmienia.

Być może ten zasób jest przydatny, pomagając zdecydować między nimi. Omawia również kilka innych baz danych NoSQL i oferuje krótką listę cech, wraz z wyjaśnieniem "do czego bym go użył" dla każdej z nich.

Http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Trudne pytanie do odpowiedzi-jak w przypadku większości rozwiązań technologicznych, tak naprawdę zależy to od twojej sytuacji, a ponieważ nie opisałeś problemu, który próbujesz rozwiązać, jak ktoś może zaproponować rozwiązanie?

Musisz przetestować je oba, aby zobaczyć, które z nich zaspokoiły twoje {4]} potrzeby.

Biorąc to pod uwagę, MongoDB nie wymaga żadnego drogiego sprzętu. Jak każde inne rozwiązanie bazodanowe, będzie działać lepiej z większą ilością procesora i pamięci, ale z pewnością nie jest to wymóg - szczególnie do wczesnych celów rozwojowych.

Redis to w pamięcimagazyn danych, który może persist to stan na dysku (aby włączyć odzyskiwanie po ponownym uruchomieniu). Jednak jako magazyn danych w pamięci oznacza to, że rozmiar magazynu danych (na pojedynczym węźle) nie może przekraczać całkowitej przestrzeni pamięci w systemie (fizyczna PAMIĘĆ RAM + przestrzeń wymiany). W rzeczywistości będzie to znacznie mniej, ponieważ Redis dzieli tę przestrzeń z wieloma innymi procesami w systemie, a jeśli wyczerpie przestrzeń pamięci systemowej, prawdopodobnie zostanie zabity przez system operacyjny.

Mongo jest dyskowy magazyn danych, który jest najbardziej wydajny, gdy roboczy zestaw mieści się w fizycznej pamięci RAM (jak wszystkie programy). Jako dane oparte na dysku oznacza, że nie ma wewnętrznych ograniczeń co do wielkości bazy danych Mongo, jednak opcje konfiguracyjne, dostępne miejsce na dysku i inne problemy mogą oznaczać, że rozmiary baz danych powyżej określonego limitu mogą stać się niepraktyczne lub nieefektywne.

Zarówno Redis, jak i Mongo mogą być grupowane dla wysokich dostępność, tworzenie kopii zapasowych i zwiększenie ogólnego rozmiaru magazynu danych.

Wszystkie odpowiedzi (w momencie pisania tego tekstu) zakładają, że każda z Redis, MongoDB i być może relacyjna baza danych oparta na SQL są zasadniczo tym samym narzędziem: "przechowuj dane". W ogóle nie biorą pod uwagę modeli danych.

MongoDB: Złożone Dane

MongoDB jest magazynem dokumentów. Aby porównać z relacyjną bazą danych opartą na SQL: relacyjne bazy danych upraszczają do zindeksowanych plików CSV, każdy plik jest tabelą; przechowuje dokumenty upraszczają do zindeksowanych plików JSON, każdy plik jest dokument, z wieloma plikami zgrupowanymi razem.

Pliki JSON są podobne w strukturze do plików XML i YAML oraz do słowników jak w Pythonie, więc pomyśl o swoich danych w tego rodzaju hierarchii. Podczas indeksowania struktura jest kluczem: dokument zawiera nazwane klucze, które zawierają kolejne dokumenty, tablice lub wartości skalarne. Rozważ poniższy dokument.

{
  _id:  0x194f38dc491a,
  Name:  "John Smith",
  PhoneNumber:
    Home: "555 999-1234",
    Work: "555 999-9876",
    Mobile: "555 634-5789"
  Accounts:
    - "379-1111"
    - "379-2574"
    - "414-6731"
}

Powyższy dokument ma klucz PhoneNumber.Mobile, który ma wartość 555 634-5789. Możesz przeszukać kolekcję dokumenty, w których klucz PhoneNumber.Mobile ma pewną wartość; są indeksowane.

Posiada również tablicę Accounts, która zawiera wiele indeksów. Możliwe jest Zapytanie o dokument, w którym Accounts zawiera dokładnie jakiś podzbiór wartości, wszystkie jakiegoś podzbioru wartości lub dowolne jakiegoś podzbioru wartości. Oznacza to, że możesz szukać Accounts = ["379-1111", "379-2574"], a nie znaleźć powyższego; możesz szukać Accounts includes ["379-1111"] i znaleźć powyższy dokument; możesz szukać Accounts includes any of ["974-3785","414-6731"] i znaleźć powyższy i niezależnie od tego, jaki dokument zawiera konto "974-3785", jeśli istnieje.

Dokumenty idą tak głęboko, jak chcesz. PhoneNumber.Mobile może zawierać tablicę, a nawet pod-dokument (PhoneNumber.Mobile.Work i PhoneNumber.Mobile.Personal). Jeśli Twoje dane są wysoce ustrukturyzowane, dokumenty są dużym krokiem naprzód w stosunku do relacyjnych baz danych.

Jeśli Twoje dane są w większości płaskie, relacyjne i sztywno ustrukturyzowane, lepiej korzystać z relacyjnej bazy danych. Ponownie dużym znakiem jest to, czy twoje modele danych najlepiej nadają się do zbioru powiązanych ze sobą plików CSV, czy zbiór plików XML / JSON / YAML.

W przypadku większości projektów będziesz musiał pójść na kompromis, akceptując drobne obejście w niektórych małych obszarach, w których sklepy SQL lub dokumenty nie pasują; w przypadku niektórych dużych, złożonych projektów przechowujących szeroką gamę danych (wiele kolumn; wiersze są nieistotne), sensowne będzie przechowywanie niektórych danych w jednym modelu, A innych danych w innym modelu. Facebook używa zarówno bazy danych SQL, jak i grafu (gdzie dane są wprowadzane do węzłów, a węzły są połączone z innymi węzłami); Craigslist używał MySQL i MongoDB, ale szukał przejścia całkowicie na MongoDB. Są to miejsca, w których rozpiętość i zależność danych napotyka znaczne utrudnienia, jeśli zostaną one uwzględnione w jednym modelu.

Redis: Klucz-Wartość

Redis jest w większości magazynem wartości klucza. Redis pozwala nadać mu klucz i wyszukać pojedynczą wartość. Sam Redis może przechowywać ciągi znaków, listy, Skróty i kilka innych rzeczy; jednak wygląda tylko po nazwie.

Cache invalidation jest jednym z trudnych problemów informatyki, drugim jest nazywanie rzeczy. Oznacza to, że będziesz używać Redis, gdy chcesz uniknąć setek nadmiernych poszukiwań na zapleczu, ale musisz dowiedzieć się, kiedy potrzebujesz nowego wyszukiwania.

Najbardziej oczywistym przypadkiem unieważnienia jest aktualizacja przy zapisie: jeśli przeczytasz user:Simon:lingots = NOTFOUND, możesz SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon i zapisać wynik, 100, jako SET user:Simon:lingots = 100. Gdy przyznasz Szymonowi 5 lingotów, czytasz user:Simon:lingots = 100, SET user:Simon:lingots = 105, i UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon. Teraz masz 105 w bazie i w Redis i może uzyskać user:Simon:lingots bez odpytywania bazy danych.

Drugi przypadek to aktualizacja informacji zależnej. Załóżmy, że generujesz fragmenty strony i buforujesz ich dane wyjściowe. Nagłówek pokazuje doświadczenie gracza, poziom i kwotę pieniędzy; strona profilu gracza ma blok, który pokazuje jego statystyki; i tak dalej. Gracz zdobywa doświadczenie. Cóż, teraz masz kilka templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simon, i tak dalej pola, w których buforowałeś wyjście z pół tuzina zapytania do bazy danych są uruchamiane przez silnik szablonów. Zwykle, gdy wyświetlasz te strony, mówisz:

$t = GetStringFromRedis("templates:StatsBox:" + $playerName);
if ($t == null) {
  $t = BuildTemplate("StatsBox.tmpl",
                     GetStatsFromDatabase($playerName));
  SetStringInRedis("Templates:StatsBox:" + $playerName, $t);
}
print $t;

Ponieważ właśnie zaktualizowałeś wyniki GetStatsFromDatabase("Simon"), musisz wyrzucić templates:*:Simon z pamięci podręcznej wartości klucza. Gdy spróbujesz renderować któryś z tych szablonów, Twoja aplikacja przestanie pobierać dane z twojej bazy danych (PostgreSQL, MongoDB) i wstawić je do Twojego szablonu; następnie zapisze wynik w Redis i, mam nadzieję, nie będzie kłopotać się tworzeniem zapytań do bazy danych i renderowaniem szablony następnym razem, gdy wyświetli ten blok wyjścia.

Redis pozwala również na wykonywanie kolejek wiadomości subskrybowanych przez wydawców itp. To zupełnie inny temat. Punkt tutaj jest Redis to klucz-wartość cache, który różni się od relacyjnej bazy danych lub magazynu dokumentów.

Podsumowanie

Wybierz Narzędzia w zależności od potrzeb. Największą potrzebą jest zazwyczaj model danych, który określa, jak skomplikowany i podatny na błędy jest Twój kod. Specjalistyczne aplikacje będą opierać się na wydajność, miejsca, w których piszesz wszystko w mieszance C i Assembly; większość aplikacji po prostu obsługuje uogólniony przypadek i korzysta z systemu buforowania, takiego jak Redis lub Memcached, który jest o wiele szybszy niż wysokowydajna baza danych SQL lub magazyn dokumentów.

I nie powinieneś używać, jeśli masz dużo pamięci RAM. Redis i MongoDB wchodzą w cenę narzędzia ogólnego przeznaczenia. To wprowadza wiele kosztów.

Było powiedzenie, że Redis jest 10 razy szybszy niż Mongo. To może już nie być prawda. MongoDB (jeśli dobrze pamiętam) twierdził, że pokonał memcache do przechowywania i buforowania dokumentów, o ile konfiguracje pamięci są takie same.

W każdym razie. Redis jest dobry, MongoDB jest dobry. Jeśli zależy ci na podbudowach i potrzebujesz agregacji dla MongoDB. Jeśli przechowywanie kluczy i wartości jest twoim głównym zmartwieniem, chodzi o Redis. (lub inny magazyn wartości klucza).

Redis i MongoDB są nie relacyjnymi bazami danych, ale należą do różnych kategorii.

Redis jest bazą danych klucza/wartości i używa pamięci w pamięci, co czyni ją super szybką. Jest to dobry kandydat do buforowania rzeczy i tymczasowego przechowywania danych(w pamięci), a ponieważ większość platform w chmurze (takich jak Azure, AWS) go obsługuje, jego użycie pamięci jest skalowalne.Ale jeśli masz zamiar używać go na swoich maszynach z ograniczonymi zasobami, rozważ, że to zużycie pamięci.

MongoDB na drugą ręką jest Baza dokumentów. Jest to dobra opcja do przechowywania dużych tekstów, obrazów, filmów itp.i prawie wszystkiego, co robisz z bazami danych, z wyjątkiem transakcji.Na przykład, jeśli chcesz stworzyć blog lub sieć społecznościową, MongoDB jest właściwym wyborem. Jest skalowalny dzięki strategii scale-out. Używa dysku jako nośnika pamięci, więc dane będą przechowywane.

Jeśli twój projekt pozwala na posiadanie wystarczającej ilości pamięci RAM w Twoim środowisku-odpowiedzią jest Redis. Szczególnie biorąc pod uwagę Nowy Redis 3.2 z funkcjonalnością klastra.