Wprowadzenie do MongoDB
MongoDB został wprowadzony w 2009 roku przez firmę o nazwie 10gen. 10gen został później przemianowany na MongoDB Inc., firmę odpowiedzialną za rozwój oprogramowania i sprzedającą wersję Enterprise tej bazy danych. MongoDB Inc. zapewnia całodobowe wsparcie dzięki doskonałemu zespołowi wsparcia klasy korporacyjnej. Są zobowiązani do zapewnienia dożywotniego wsparcia, co oznacza, że klienci decydują się na korzystanie z dowolnej wersji MongoDB, a jeśli chcą uaktualnić, będzie ona obsługiwana w dowolnym momencie. Zapewnia im również możliwość synchronizacji ze wszystkimi poprawkami bezpieczeństwa, które firma oferuje przez całą dobę.
MongoDB to dobrze znane bazy danych NoSQL, które znacznie się rozrosły w ciągu ostatniej dekady, napędzane gwałtownym rozwojem aplikacji internetowych i mobilnych działających w chmurze. Ten nowy rodzaj aplikacji połączonych z Internetem wymaga szybkiego, odpornego na błędy i skalowalnego przechowywania danych bez schematów, które mogą zaoferować bazy danych NoSQL. MongoDB używa JSON do przechowywania danych, takich jak dokumenty, które mogą różnić się ofertą struktury, dynamicznym, elastycznym schematem. MongoDB zaprojektowany z myślą o wysokiej dostępności i skalowalności z automatycznym fragmentowaniem. MongoDB to jedna z popularnych baz danych typu open source, które powstają w ramach bazy danych NoSQL, która służy do przechowywania dużych ilości danych. MongoDB zawiera wiersze zwane dokumentami, które nie wymagają definiowania schematu, ponieważ pola są tworzone w locie. Model danych dostępny w MongoDB umożliwia bardziej wydajną reprezentację relacji hierarchicznych, przechowywanie tablic i innych bardziej złożonych struktur.
Wprowadzenie do Cassandry
Apache Cassandra to kolejny dobrze znany darmowy i otwarty, rozproszony sklep z szeroką kolumną. Cassandra została wprowadzona w 2008 roku przez kilku programistów z Facebooka, która później została wydana jako projekt open-source. Obecnie jest wspierany przez Apache Software Foundation, a Apache obecnie utrzymuje ten projekt w celu wprowadzenia dalszych ulepszeń.
Cassandra to system zarządzania bazami danych NoSQL zaprojektowany do obsługi dużych ilości danych na wielu popularnych serwerach i zapewnienia wysokiej dostępności bez pojedynczego punktu awarii. Cassandra oferuje bardzo solidną obsługę klastrów obejmujących wiele centrów danych, z asynchroniczną replikacją bez mastera, umożliwiającą operacje z małymi opóźnieniami dla wszystkich klientów. Cassandra obsługuje projekt dystrybucji Amazon Dynamo za pomocą modelu danych Bigtable firmy Google.
Podobieństwa między MongoDB i Cassandrą
Po krótkim wprowadzeniu do tych dwóch baz danych NoSQL przejrzyjmy niektóre podobieństwa między tymi dwiema bazami danych:
Zarówno MongoDB, jak i Cassandra są typami baz danych NoSQL i dystrybucją open-source.
- Żadna z tych baz danych nie zastępuje tradycyjnych typów baz danych RDBMS.
- Obie te bazy danych nie są zgodne z ACID (atomowość, spójność, izolacja, trwałość), który odnosi się do właściwości transakcji bazodanowych, które gwarantują niezawodne przetwarzanie transakcji w bazie danych.
- Obie te bazy danych obsługują sharding partycjonowanie poziome.
- Spójność i normalizacja to dwie koncepcje, których te dwa typy baz danych nie spełniają (ponieważ bardziej skłaniają się one ku typom baz danych RDBMS)
MongoDB kontra Cassandra:funkcje
Obie technologie odgrywają istotną rolę w swoich dziedzinach, a ich podobieństwa między MongoDB i Cassandrą pokazują ich wspólne cechy i różnice, które pokazują wyjątkowość tych technologii.
Rysunek 1 MongoDB kontra Cassandra – 8 głównych czynników różnicujących Ekspresywny model danych
MongoDB zapewnia bogaty i ekspresyjny model danych, który jest znany jako „zorientowany obiektowo” lub „zorientowany na dane”. Ten model danych może z łatwością obsługiwać i reprezentować dowolną strukturę danych w domenie użytkownika. Dane mogą mieć właściwości i mogą być zagnieżdżane w sobie na wielu poziomach. Cassandra jest bardziej tradycyjnym modelem danych ze strukturą tabeli, wierszami i kolumnami określonego typu danych. Ten typ jest definiowany podczas tworzenia tabeli. W każdym razie, kiedy porównujemy oba modele, MongoDB ma tendencję do zapewniania bogatego modelu danych. Poniższy rysunek opisuje typowe wysokopoziomowe architektury obu baz danych pod względem poziomów przechowywania i replikacji.
Rysunek 2:Diagram architektury MongoDB vs. Cassandra Węzeł główny wysokiej dostępności
MongoDB obsługuje jeden węzeł główny w klastrze, który kontroluje zestaw węzłów podrzędnych. Jeśli węzeł nadrzędny ulegnie awarii, niewolnik zostanie wybrany jako nadrzędny i zajmuje to około 20-30 sekund. W tym czasie klaster będzie wyłączony i nie będzie w stanie zaakceptować żadnych danych wejściowych. Cassandra obsługuje wiele węzłów głównych w klastrze, a w przypadku, gdy jeden z węzłów głównych zostanie wyłączony, jego miejsce zajmie inny węzeł główny. Dla porównania Cassandra obsługuje wyższą dostępność przez MongoDB, ponieważ nie wpływa na klaster i jest zawsze dostępna.
Indeksy dodatkowe
MongoDB ma więcej zalet w porównaniu z Cassandrą, jeśli aplikacja wymaga indeksów dodatkowych wraz z elastycznością modelu danych. Z tego powodu MongoDB znacznie łatwiej indeksuje dowolną właściwość danych przechowywanych w bazie danych. Ta właściwość ułatwia wykonywanie zapytań. Cassandra obsługuje kursor dla indeksów pomocniczych, które są ograniczone do pojedynczych kolumn i porównań równości
Skalowalność zapisu
MongoDB obsługuje tylko jeden węzeł główny. Ten węzeł główny w MongoDB akceptuje tylko dane wejściowe, a pozostałe węzły w MongoDB są używane jako dane wyjściowe; w związku z tym, jeśli dane mają być zapisane w węzłach podrzędnych i przepuścić je przez węzeł nadrzędny. Cassandra obsługuje wiele węzłów głównych w klastrze, co czyni ją odpowiednią w przypadku skalowalności.
Obsługa języka zapytań
Obecnie MongoDB nie obsługuje języka zapytań. Zapytania w MongoDB mają strukturę fragmentów JSON. Natomiast Cassandra ma przyjazny dla użytkownika zestaw zapytań, który jest znany jako CQL (Cassandra Query Language) i jest łatwy do dostosowania przez programistów, którzy mają wcześniejszą wiedzę na temat SQL. Czym różnią się ich zapytania?
Wybieranie rekordów z tabeli klientów:
Cassandra:
SELECT * FROM customer;MongoDB:
db.customer.find()Wstawianie rekordów do tabeli klientów:
Cassandra:
INSERT INTO customer (custid, branch, status) VALUES('appl01', 'headquarters', 'A');MongoDB:
db.customer.insert({ cust_id: 'appl01', branch: 'headquarters', status: 'A' })Aktualizowanie rekordów w tabeli klientów:
Cassandra:
UPDATE Customer SET branch = ‘headquarters' WHERE custage > 2;MongoDB:
db.customer.update( { custage: { $gt: 2 } }, { $set: { branch: 'headquarters' } }, { multi: true } )Agregacja natywna
MongoDB ma wbudowaną strukturę agregacji, która służy do uruchamiania potoku ETL w celu przekształcania danych przechowywanych w bazie danych, a także obsługuje zarówno mały, jak i średni ruch danych. W przypadku zwiększonej złożoności struktura staje się również trudniejsza do debugowania, podczas gdy Cassandra nie ma zintegrowanej struktury agregacji. Cassandra korzystała z zewnętrznych narzędzi, takich jak Hadoop, Apache Spark itp. Dlatego MongoDB jest lepszy niż Cassandra, jeśli chodzi o wbudowaną platformę agregacji.
Model bez schematu
MongoDB umożliwia użytkownikowi zmianę egzekwowania dowolnego schematu w bazie danych. Każda baza danych może mieć inną strukturę. Wszystko zależy od programu lub aplikacji do interpretacji danych. Zważywszy, że Cassandra nie oferuje możliwości zmiany schematów, ale zapewnia statyczne pisanie, w którym użytkownik musi zdefiniować typ kolumny na początku.
Wzorzec wydajności
Cassandra rozważa lepszą wydajność w aplikacjach wymagających dużego obciążenia danymi, ponieważ może obsługiwać wiele węzłów głównych w klastrze. Natomiast MongoDB nie będzie idealnym rozwiązaniem dla aplikacji o dużym obciążeniu danymi, ponieważ nie można go skalować wraz z wydajnością. Na podstawie standardowego testu porównawczego stworzonego przez Yahoo! zwany YCSB, MongoDB zapewnia większą wydajność niż Cassandra we wszystkich testach, które wykonali, w niektórych przypadkach nawet 25x. Po zoptymalizowaniu pod kątem równowagi przepustowości i trwałości między Cassandra i MongoDB, MongoDB zapewnia ponad 50% większą przepustowość w mieszanych obciążeniach i 2,5-krotnie większą przepustowość w obciążeniach z dominacją odczytu w porównaniu z Cassandra.
MongoDB zapewnia największą elastyczność w zapewnianiu trwałości dla określonych operacji:użytkownicy mogą wybrać konfigurację zoptymalizowaną pod kątem trwałości dla określonych operacji, które są uważane za krytyczne, ale dla których dodatkowe opóźnienie jest akceptowalne. W przypadku Cassandry ta zmiana wymaga edycji pliku konfiguracyjnego serwera i pełnego ponownego uruchomienia bazy danych.
Wnioski
MongoDB jest najlepiej znany z obciążeń z dużą ilością danych o dużej nieustrukturyzowanej strukturze. Skala i typy danych, z którymi będziesz pracować z elastycznymi strukturami danych MongoDB, będą Ci odpowiadać lepiej niż Cassandra. Aby efektywnie korzystać z MongoDB, będziesz musiał poradzić sobie z możliwością przestoju w przypadku awarii węzła głównego, a także z ograniczoną prędkością zapisu. I nie zapominaj, że będziesz musiał także nauczyć się nowego języka zapytań. W MongoDB złożonymi danymi można łatwo zarządzać przy użyciu funkcji obsługi formatu JSON. Jest to kluczowy wyróżnik MongoDB w porównaniu z Cassandrą. W niektórych sytuacjach Cassandra może być uważana za najlepszą bazę danych do wdrożenia w przypadku dużych ilości danych, optymalizacji szybkości i wykonywania zapytań. Porównując wyniki Cassandry i MongoDB, przekonamy się, że mają one swoje zalety w zależności od wymagań implementacyjnych i ilości danych, którymi należy się zająć.
