Cassandra kontra MongoDB

Czy rozważasz Cassandra lub MongoDB jako magazyn danych dla swojego następnego projektu? Czy chcesz porównać te dwie bazy danych? Cassandra i MongoDB to bazy danych „NoSQL”, ale w rzeczywistości bardzo się różnią. Mają bardzo różne mocne strony i propozycje wartości – więc każde porównanie musi być zniuansowane. Zacznijmy od wstępnych wymagań… Żadna z tych baz nie zastępuje RDBMS, ani nie są bazami „ACID”. Jeśli więc masz obciążenie transakcyjne, w którym normalizacja i spójność są podstawowymi wymaganiami, żadna z tych baz danych nie będzie dla Ciebie odpowiednia. Lepiej jest trzymać się tradycyjnych relacyjnych baz danych, takich jak MySQL, PostgreSQL, Oracle itp. Teraz, gdy mamy już relacyjne bazy danych, rozważmy główne różnice między Cassandrą a MongoDB, które pomogą Ci podjąć decyzję. W tym poście nie zamierzam omawiać konkretnych funkcji, ale wskażę pewne strategiczne różnice wysokiego poziomu, które pomogą Ci dokonać wyboru.

1. Ekspresyjny model obiektowy

MongoDB obsługuje bogaty i ekspresyjny model obiektów. Obiekty mogą mieć właściwości, a obiekty mogą być zagnieżdżane w sobie (na wielu poziomach). Ten model jest bardzo „zorientowany obiektowo” i może z łatwością reprezentować dowolną strukturę obiektów w Twojej domenie. Możesz także zindeksować właściwość dowolnego obiektu na dowolnym poziomie hierarchii – to uderzająco potężne! Z drugiej strony Cassandra oferuje dość tradycyjną strukturę tabeli z wierszami i kolumnami. Dane są bardziej uporządkowane, a każda kolumna ma określony typ, który można określić podczas tworzenia.

Werdykt:jeśli problematyczna domena wymaga rozbudowanego modelu danych, hosting MongoDB jest dla Ciebie lepszym rozwiązaniem.

2. Indeksy dodatkowe

Indeksy dodatkowe są konstrukcją pierwszej klasy w MongoDB. Ułatwia to indeksowanie dowolnej właściwości obiektu przechowywanego w MongoDB, nawet jeśli jest ona zagnieżdżona. Ułatwia to wykonywanie zapytań na podstawie tych indeksów pomocniczych. Cassandra obsługuje tylko pobieżne indeksy wtórne. Indeksy pomocnicze są również ograniczone do pojedynczych kolumn i porównań równości. Jeśli najczęściej będziesz wysyłać zapytania za pomocą klucza podstawowego, Cassandra będzie dla Ciebie odpowiednia.

Werdykt:  Jeśli Twoja aplikacja wymaga indeksów dodatkowych i elastyczności modelu zapytań, MongoDB jest dla Ciebie lepszym rozwiązaniem.

3. Wysoka dostępność

MongoDB obsługuje model „single master”. Oznacza to, że masz węzeł główny i pewną liczbę węzłów podrzędnych. W przypadku, gdy pan upadnie, jeden z niewolników zostaje wybrany na pana. Ten proces odbywa się automatycznie, ale zajmuje trochę czasu, zwykle 10-40 sekund. W czasie wyborów nowego lidera twój zestaw replik nie działa i nie może wykonywać zapisów. Działa to w przypadku większości aplikacji, ale ostatecznie zależy od Twoich potrzeb. Cassandra obsługuje model „wielu mistrzów”. Utrata pojedynczego węzła nie wpływa na zdolność klastra do przyjmowania zapisów – dzięki czemu możesz osiągnąć 100% czasu sprawności dla zapisów.

Werdykt:Jeśli potrzebujesz 100% dostępności, Cassandra jest dla Ciebie lepszym rozwiązaniem.

4. Skalowalność zapisu

MongoDB z modelem „single master” może wykonywać zapisy tylko na podstawowym. Serwery pomocnicze mogą być używane tylko do odczytów. Zasadniczo więc, jeśli masz zestaw replik z trzema węzłami, tylko master wykonuje zapisy, a pozostałe dwa węzły są używane tylko do odczytu. To znacznie ogranicza skalowalność zapisu. Możesz wdrożyć wiele fragmentów, ale zasadniczo tylko 1/3 węzłów danych może wykonywać zapisy. Cassandra dzięki modelowi „multiple master” może wykonywać zapisy na dowolnym serwerze. Zasadniczo skalowalność zapisu jest ograniczona liczbą serwerów w klastrze. Im więcej serwerów masz w klastrze, tym lepiej będzie się skalował.

Werdykt:Jeśli skalowalność zapisu jest twoją sprawą, Cassandra będzie dla ciebie lepszym rozwiązaniem.

5. Obsługa języka zapytań

Cassandra obsługuje język zapytań CQL, który jest bardzo podobny do SQL. Jeśli masz już zespół analityków danych, będą oni w stanie przenieść większość swoich umiejętności SQL, co jest bardzo ważne dla dużych organizacji. Jednak CQL nie jest w pełni rozwiniętym ANSI SQL – ma kilka ograniczeń (brak obsługi łączenia, brak klauzul OR) itp. MongoDB w tym momencie nie obsługuje języka zapytań. Zapytania mają strukturę fragmentów JSON.

Werdykt:jeśli potrzebujesz obsługi języka zapytań, Cassandra jest dla Ciebie lepszym rozwiązaniem.

6. Testy wydajności

Porozmawiajmy o wydajności. W tym momencie prawdopodobnie oczekujesz porównania wydajności baz danych. Celowo nie uwzględniłem w porównaniu testów wydajności. W każdym porównaniu musimy upewnić się, że robimy porównanie jabłek do jabłek.

1.  Model bazy danych - Model/schemat bazy danych testowanej aplikacji robi dużą różnicę. Niektóre schematy są dobrze dopasowane do MongoDB, a inne do Cassandry. Dlatego przy porównywaniu baz danych ważne jest, aby użyć modelu, który działa dość dobrze dla obu baz danych.
2.  Charakterystyka obciążenia – Bardzo ważne są charakterystyki obciążenia wzorcowego. Np. W testach porównawczych z dużą ilością zapisu, spodziewałbym się, że Cassandra będzie paliła MongoDB. Jednak w testach z dużym obciążeniem odczytu, MongoDB i Cassandra powinny mieć podobną wydajność.
3. Wymagania dotyczące spójności - To jest podchwytliwe. Musisz upewnić się, że określone wymagania dotyczące spójności odczytu/zapisu są identyczne w obu bazach danych i nie są stronnicze w stosunku do jednego uczestnika. Bardzo często w wielu benchmarkach „marketingowych” pokrętła są dostrajane tak, aby działały na niekorzyść drugiej strony. Dlatego zwracaj szczególną uwagę na ustawienia spójności.

Ostatnią rzeczą, o której należy pamiętać, jest to, że obciążenie testu porównawczego może, ale nie musi odzwierciedlać wydajności Twojej aplikacji. Aby testy porównawcze były przydatne, bardzo ważne jest znalezienie obciążenia testu porównawczego, które odzwierciedla charakterystykę wydajności aplikacji. Oto kilka testów porównawczych, na które warto się przyjrzeć:
- Wskaźniki wydajności NoSQL
- Cassandra vs. MongoDB vs. Couchbase vs. HBase

7. Łatwość użycia

Gdybyś zadał to pytanie kilka lat temu, MongoDB byłby bezkompromisowym zwycięzcą. To dość proste zadanie, aby uruchomić MongoDB. Jednak w ciągu ostatnich kilku lat Cassandra poczyniła wielkie postępy w tym aspekcie produktu. Wraz z przyjęciem CQL jako głównego interfejsu dla Cassandry, posunęło się to o krok dalej – bardzo ułatwiło wielu programistom SQL bardzo łatwe korzystanie z Cassandry.

Werdykt:oba są dość łatwe w użyciu i rozwijają się.

8. Agregacja natywna

MongoDB ma wbudowaną strukturę agregacji do uruchamiania potoku ETL w celu przekształcenia danych przechowywanych w bazie danych. Jest to świetne rozwiązanie w przypadku małych i średnich zadań, ale gdy potrzeby związane z przetwarzaniem danych stają się bardziej skomplikowane, struktura agregacji staje się trudna do debugowania. Cassandra nie ma wbudowanej struktury agregacji. Używane są do tego zewnętrzne narzędzia, takie jak Hadoop, Spark.

9. Modele bez schematu

W MongoDB możesz zdecydować, aby nie wymuszać żadnego schematu w swoich dokumentach. Chociaż było to domyślne ustawienie we wcześniejszych wersjach, w nowszej wersji możesz wymusić stosowanie schematu dla swoich dokumentów. Każdy dokument w MongoDB może mieć inną strukturę i od Twojej aplikacji zależy interpretacja danych. Chociaż nie dotyczy to większości zastosowań, w niektórych przypadkach ważna jest dodatkowa elastyczność. Cassandra w nowszych wersjach (z CQL jako językiem domyślnym) zapewnia pisanie statyczne. Musisz zdefiniować typ samej kolumny z góry.

Podsumujmy tutaj ważne różnice w formie tabeli:
Jeśli chcesz zobaczyć pełną infografikę, możesz odwiedzić naszą stronę porównawczą Cassandra i MongoDB.