MongoDB vs. Cassandra [zamknięte]

738

Oceniam, jaka może być najlepsza opcja migracji.

Obecnie korzystam z dzielonego MySQL (partycja pozioma), a większość moich danych jest przechowywana w obiektach blob JSON. Nie mam żadnych złożonych zapytań SQL (już migrowałem po tym, jak partycjonowałem moją bazę danych).

W tej chwili wydaje się, że zarówno MongoDB, jak i Cassandra byłyby prawdopodobnymi opcjami. Moja sytuacja:

  • Dużo odczytów w każdym zapytaniu, mniej regularne zapisy
  • Nie martwi się o „ogromną” skalowalność
  • Bardziej zaniepokojony prostą konfiguracją, konserwacją i kodem
  • Zminimalizuj koszty sprzętu / serwera
ming yeow
źródło
4
Dostępne są oficjalne statystyki testu wydajności. Cassandra vs MongoDB vs HBase
Ravi
1
> Wiele odczytów w każdym zapytaniu, mniej regularnych zapisów => Poszukaj CQRS (oddziel odczyty od zapisów prawdopodobnie bez pozyskiwania zdarzeń, ale sprawdź, czy możesz zaktualizować asynchronię modelu odczytu. Synchronizacja też może działać .. to zależy od twojego użycia -cases)
bodrin
2
To naprawdę świetne pytanie. Zastanawiam się, czy jest zaktualizowana wersja? Ten jest już bardzo stary
slashdottir

Odpowiedzi:

584

Wiele odczytów w każdym zapytaniu, mniej regularnych zapisów

Obie bazy danych działają dobrze w odczytach, w których zestaw gorących danych mieści się w pamięci. Oba podkreślają również modele danych bez łączenia (i zamiast tego zachęcają do denormalizacji) i oba zapewniają indeksy dokumentów lub wierszy , chociaż indeksy MongoDB są obecnie bardziej elastyczne.

Silnik pamięci Cassandra zapewnia ciągłe zapisywanie, bez względu na to, jak duży jest Twój zestaw danych. Zapisy są bardziej problematyczne w MongoDB, częściowo z powodu silnika pamięci masowej opartego na b-drzewie, ale bardziej z powodu blokowania wielu granulacji .

W przypadku analiz MongoDB zapewnia niestandardową implementację mapowania / zmniejszania; Cassandra zapewnia natywną obsługę Hadoop, w tym Hive (hurtownia danych SQL zbudowana na mapie Hadoop map / redukcja) i Pig (specyficzny dla Hadoop język analizy, który zdaniem wielu osób lepiej nadaje się do mapowania / zmniejszania obciążeń niż SQL). Cassandra obsługuje także Spark .

Nie martwi się o „ogromną” skalowalność

Jeśli patrzysz na pojedynczy serwer, MongoDB jest prawdopodobnie lepszym rozwiązaniem. Dla osób bardziej zainteresowanych skalowaniem architektura Cassandry bez pojedynczego punktu awarii będzie łatwiejsza do skonfigurowania i bardziej niezawodna. (Globalna blokada zapisu MongoDB również staje się coraz bardziej bolesna.) Cassandra daje również znacznie większą kontrolę nad tym, jak działa Twoja replikacja, w tym obsługę wielu centrów danych.

Bardziej zaniepokojony prostą konfiguracją, konserwacją i kodem

Oba są łatwe do skonfigurowania, z rozsądnymi domyślnymi ustawieniami domyślnymi dla pojedynczego serwera. Cassandra jest łatwiejsza do skonfigurowania w konfiguracji z wieloma serwerami, ponieważ nie trzeba się martwić o węzły o specjalnej roli.

Jeśli obecnie używasz obiektów blob JSON, MongoDB jest niesamowicie dobrym rozwiązaniem dla twojego przypadku użycia, biorąc pod uwagę, że używa BSON do przechowywania danych. Będziesz mógł mieć bogatsze i bardziej dostępne dane, niż w obecnej bazie danych. To byłaby najbardziej znacząca wygrana dla Mongo.

Michał
źródło
86
Zupełnie inaczej, komentarz nie jest wystarczająco duży, ale ... Cassandra to liniowo skalowalna (zamortyzowana stała liczba odczytów i zapisów) hybryda dynamo / google bigtable, która oferuje szybkie zapisywanie niezależnie od wielkości danych. Zestaw funkcji jest minimalistyczny, niewiele więcej niż w przypadku uporządkowanego magazynu wartości klucza. MongoDB to bogato wyposażony (i szybki) magazyn dokumentów kosztem trwałości i gwarancji trwałego zapisu (ponieważ nie są one natychmiast zapisywane na dysk). To różne bestie o różnych filozofiach, MongoDB jest bliżej zamiennika RDMS ...
Michael
28
podczas gdy Cassandra ma niższy poziom, ale pozwala na skalowanie ubera (patrz Twitter / Digg / Facebook), ale będziesz musiał rozmyślnie rozłożyć dane, budować indeksy wtórne itp., ponieważ żadne elastyczne zapytania nie są dozwolone.
Michael
11
Ponieważ wszyscy wspominali tutaj o twitterze w odniesieniu do Cassandry: nie używają Cassandry do utrzymywania tweetów, nadal używają MySQL tutaj ( engineering.twitter.com/2010/07/cassandra-at-twitter-today.html ). Ok, ale mogę sobie wyobrazić, że wciąż przechowują wiele danych do innych celów w Cassandrze.
H6.
7
Wygląda na to, że globalna blokada zapisu mogła zostać usunięta w Mongo 2.2 ...
Matt Farmer, 18'12
16
Jeszcze zanim mój projekt został zrealizowany, odczuwam bolące punkty Mongodb. Kopia zapasowa na gorąco jest podstawowym wymogiem. Aby wykonać kopię zapasową na gorąco na serwerze Linux, musisz najpierw skonfigurować partycję LVM (nie tak powszechną) i wykonać migawkę przed każdą sesją tworzenia kopii zapasowej. Innym łatwym sposobem jest skorzystanie z płatnej usługi tworzenia kopii zapasowych Mongodb. Ale ta usługa jest droga (2,3 USD / GB / miesiąc). Wkrótce będziesz potrzebować repliki dla odporności na uszkodzenia. W wersji open source węzły mogą wymieniać dane tylko jako czysty tekst. W przypadku SSL musisz przejść do edycji Entprise. A to jest 10.000 $. Do widzenia Mongodb. Refaktoryzuję mój kod do Cassandry.
Karthik Sankar
146

Używałem MongoDB intensywnie (przez ostatnie 6 miesięcy), budując hierarchiczny system zarządzania danymi, i mogę ręczyć za łatwość instalacji (zainstaluj, uruchom, użyj!) I szybkość. Tak długo, jak dokładnie myślisz o indeksach, może absolutnie krzyczeć szybko.

Rozumiem, że Cassandra, ze względu na wykorzystanie w dużych projektach, takich jak Twitter, ma lepszą funkcjonalność skalowania, chociaż zespół MongoDB pracuje tam na zasadzie parzystości. Powinienem zaznaczyć, że nie użyłem Cassandry poza etapem próbnym, więc nie mogę mówić o szczegółach.

Prawdziwym swingerem dla mnie, gdy ocenialiśmy bazy danych NoSQL, były zapytania - Cassandra to po prostu gigantyczny magazyn kluczy / wartości, a zapytania są nieco kłopotliwe (przynajmniej w porównaniu z MongoDB), więc dla wydajności musiałbyś powielać całkiem sporo danych jako rodzaj indeksu ręcznego. Z kolei MongoDB korzysta z modelu „zapytanie według przykładu”.

Załóżmy na przykład, że masz kolekcję (Monlista DB dla odpowiednika tabeli RDMS) zawierającą użytkowników. MongoDB przechowuje rekordy jako Dokumenty, które są w zasadzie binarnymi obiektami JSON. na przykład:

{
   FirstName: "John",
   LastName: "Smith",
   Email: "[email protected]",
   Groups: ["Admin", "User", "SuperUser"]
}

Jeśli chcesz znaleźć wszystkich użytkowników o nazwie Smith, którzy mają uprawnienia administratora, po prostu utwórz nowy dokument (w konsoli administracyjnej za pomocą Javascript lub w wersji produkcyjnej w wybranym języku):

{
   LastName: "Smith",
   Groups: "Admin"
}

... a następnie uruchom zapytanie. Otóż ​​to. Dodano operatorów do porównań, filtrowania RegEx itp., Ale wszystko jest dość proste, a dokumentacja oparta na Wiki jest całkiem dobra.

Richard K.
źródło
54
Aktualizacja (8 sierpnia 2011 r.): Centrum danych Amazon EC2 w Amazon w Irlandii miało wczoraj incydent z piorunem, a podczas sortowania odzyskiwania serwerów odkryłem jeden bardzo ważny punkt: jeśli masz zestaw replikacji dwóch serwerów (i są łatwe do skonfigurowania), upewnij się, że masz węzeł Arbiter, więc jeśli jeden się zepsuje, drugi nie wpadnie w panikę i nie utknie w trybie pomocniczym! Zaufaj mi, trudno jest rozwiązać problem z dużą bazą danych.
Richard K.,
8
aby dodać to, co powiedział @Richard K, powinieneś mieć węzeł arbitra, gdy masz parzystą liczbę węzłów (pierwotną + wtórną) w zestawie replik.
Amareswar
Dodane do tego rozważ mongodb, gdy więcej agregacji należy wykonać na analizie danych.
user1503117,
As long as you think about indexes carefully, it can absolutely scream along, speed-wise.Poczekaj, aż pamięć fizyczna zapełni się, a system operacyjny zacznie
powodować
117

Dlaczego warto wybierać między tradycyjną bazą danych a magazynem danych NoSQL? Używać obu! Problem z rozwiązaniami NoSQL (wykraczający poza początkową krzywą uczenia się) polega na braku transakcji - wykonujesz wszystkie aktualizacje MySQL, a MySQL wypełnia magazyn danych NoSQL do odczytu - wtedy czerpiesz korzyści z zalet każdej technologii. To dodaje jeszcze większej złożoności, ale masz już stronę MySQL - po prostu dodaj do miksu MongoDB, Cassandra itp.

Magazyny danych NoSQL generalnie skalują się znacznie lepiej niż tradycyjny DB dla tych samych specyfikacji - istnieje powód, dla którego Facebook, Twitter, Google i większość nowych firm korzysta z rozwiązań NoSQL. Nie tylko maniacy mają mocne podejście do nowych technologii.

Jason Grant Taylor
źródło
8
W pełni się zgadzam. Używam mongodb + mysql w jednym z nadchodzących produktów, które tworzę. To nadchodząca chmura produktów finansowych. mysql jest używany tam, gdzie absolutnie potrzebujemy możliwości transakcyjnych. mongodb służy do przechowywania skomplikowanych struktur danych, które nie wymagają obliczeń, które w razie potrzeby należy tylko wyciągnąć. jak dotąd działa dobrze. :)
Ram on Rails-n-React,
Takiego podwójnego podejścia użyłem również w większości moich projektów, aw niektórych innych system plików zamontowany w systemie plików NFS był używany razem z PostgreSQL dla sejsmicznych obiektów blob zbliżonych do 1 Gb. Ścieżka jest rodzajem zapytania do bazy danych wartości klucza.
Audrius Meskauskas
1
Oto link do pytania, które zadałem na temat architektury zarówno bazy danych sql, jak i nosql: dba.stackexchange.com/questions/102053 /... Przydałby mi się pewien wgląd
j
Uciekł już z transakcji na dobre => teraz nieskończona skalowalność może być możliwa .. w przeciwnym razie -> nie :)
bodrin
1
To nie jest dobre rozwiązanie, jeśli Twoje dane są dystrybuowane
Esteban Verbel
60

Prawdopodobnie będę dziwnym człowiekiem, ale myślę, że musisz pozostać przy MySQL. Nie opisałeś prawdziwego problemu, który musisz rozwiązać, a MySQL / InnoDB jest doskonałym zapleczem pamięci nawet dla danych blob / json.

Inżynierowie internetowi często podchodzą do próby użycia większej ilości NoSQL, gdy tylko zorientuje się, że nie wszystkie funkcje RDBMS są używane. Samo to nie jest dobrym powodem, ponieważ najczęściej bazy danych NoSQL mają raczej słabe silniki danych (co MySQL nazywa silnikiem pamięci).

Teraz, jeśli nie jesteś tego rodzaju, określ to, czego brakuje w MySQL, a szukasz w innej bazie danych (np. Automatyczne dzielenie, automatyczne przełączanie awaryjne, replikacja z wieloma wzorcami, słabsza gwarancja spójności danych w klaster opłaca się w wyższej przepustowości zapisu itp.).

Kostja
źródło
13
Korzysta z shardingu, co oznacza, że ​​jego dane są dzielone ręcznie na serwery. Mongodb może zautomatyzować dzielenie fragmentów, co może być zaletą.
fabspro
18
Przechowuje również głównie obiekty BLS JSON w RDBMS - czyniąc projekt (funkcje) relacyjnym bezużytecznym.
Damir Sudarevic
4
Model danych i automatyczne sharding rzeczywiście są różne, ale przy wyborze bazy danych, trzeba patrzeć na silniku przechowywania pierwszy , a reszta wodotryski sekund. Jak będzie działał silnik pamięci masowej pod skokiem obciążenia? Jak działa funkcja autowykrywania w przypadku gwałtownego wzrostu napływu danych? Zanim zrezygnujesz z kontroli nad bazą danych w odniesieniu do tych ważnych aspektów, lepiej upewnij się, że będzie w stanie wykonać to zadanie.
Kostja
7
Model relacyjny jest jednym z najbardziej przemyślanych, wydajnych do wdrożenia i oszczędnych modeli danych. „Renderowanie funkcji projektowania relacji bezużytecznych” może odnosić się do ograniczeń, wyzwalaczy lub integralności referencyjnej - ale wszystkie są płatne za użycie.
Kostja
20

Nie korzystałem z Cassandry, ale użyłem MongoDB i uważam, że to niesamowite.

Jeśli szukasz prostej konfiguracji, oto ona: Po prostu rozpakuj MongoDB i uruchom demona mongod i to wszystko ... działa.

Oczywiście to tylko początek, ale na początek jest to łatwe.

dalton
źródło
22
AFAIK, to samo dotyczy również Cassandry. Untar, uruchom demona. Klaster testowy jest skonfigurowany i gotowy do produkcji!
asgs
13

Wczoraj widziałem prezentację na temat mongodb. Mogę zdecydowanie powiedzieć, że konfiguracja była „prosta”, tak prosta jak rozpakowanie i uruchomienie. Gotowy.

Wierzę, że zarówno mongodb, jak i cassandra będą działać na praktycznie każdym zwykłym sprzęcie linuxowym, więc nie powinieneś znaleźć zbyt dużej bariery w tym obszarze.

Myślę, że w tym przypadku pod koniec dnia sprowadzi się do tego, z czym osobiście czujesz się bardziej komfortowo i który ma zestaw narzędzi, który wolisz. Jeśli chodzi o prezentację na mongodb, prezenter wskazał, że zestaw narzędzi dla mongodb był dość lekki i że nie było wielu (jak twierdzą, naprawdę) narzędzi podobnych do tego, co jest dostępne dla MySQL. To było oczywiście ich doświadczenie, więc YMMV. Jedną z rzeczy, które podobały mi się w mongodb, było to, że wydawało się, że jest w nim dużo wsparcia językowego (Python i .NET to dwa, których przede wszystkim używam).

Lista stron używających mongodb jest dość imponująca i wiem, że Twitter zmienił się na używanie Cassandry.

GrayWizardx
źródło
4
Na koniec dnia porównujemy jabłka z pomarańczami. Obie bazy danych mają swoje mocne strony. Oto kilka rzeczy do rozważenia - model obiektowy, indeksy wtórne, skalowalność zapisu, wysoka dostępność itp. Mają post na blogu, który wyjaśnia strategiczne różnice na wysokim poziomie między mongodb i cassandra tutaj - scalegrid.io/blog/cassandra-vs-mongodb
Dharshan