MongoDB vs. Cassandra [zamknięte]

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

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.

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.

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.

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.).

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.

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.