Dopasowanie NoSQL do urazów: MongoDB kontra serwer Couchbase

Wybór odpowiedniej bazy danych do danego zadania może być trudnym zadaniem, szczególnie jeśli korzystasz z pełnej przestrzeni opcji SQL i NoSQL. Jeśli szukasz elastycznej, uniwersalnej opcji, która umożliwia tworzenie schematów płynnych i złożonych zagnieżdżonych struktur danych, baza danych dokumentów może być właśnie dla Ciebie. MongoDB i Couchbase Server to dwie popularne opcje. Jak wybrać?

MongoDB łączy w sobie zalety ogromnej popularności, obsługę prostego wyszukiwania wykresów oraz możliwość wykonywania zapytań SQL za pośrednictwem łącznika BI. Couchbase ma własną dużą społeczność użytkowników, wydajną architekturę klucz-wartość i podobny do SQL język zapytań, który umożliwia nawigację po zagnieżdżonych strukturach dokumentów.

Krótko mówiąc, zarówno MongoDB, jak i Couchbase to potężne i elastyczne bazy danych zorientowane na dokumenty z wieloma dodatkami. To powiedziawszy, mają ważne różnice, które przechylają równowagę w jedną lub drugą stronę, w zależności od twoich potrzeb. Aby pomóc Ci w podjęciu decyzji, poprowadzimy te bazy danych przez próbę kluczowych zagadnień, obejmujących sposób działania każdej z nich w zakresie instalacji i konfiguracji, administracji, łatwości użytkowania, skalowalności i dokumentacji.

Ta dyskusja jest oparta na MongoDB 3.4 i Couchbase Server 4.6. Możesz również sprawdzić moje niezależne recenzje MongoDB 3.4 i Couchbase Server 4.0.

Instalacja i konfiguracja

Instalację i konfigurację można rozpatrywać z dwóch perspektyw: deweloperów pracujących na lokalnym wystąpieniu i inżynierów infrastruktury konfigurujących początkowy klaster produkcyjny. Wiele baz danych NoSQL ma mocne historie dotyczące przyjazności dla programistów, zwiększających szanse na wypróbowanie produktu przez programistę i wprowadzenie go do swoich systemów. Prosta lokalna konfiguracja to mocny punkt sprzedaży. Z drugiej strony baza danych ostatecznie udowodni swoją wartość w środowisku produkcyjnym, więc konfiguracja produkcyjna jest równie ważna, aby ją uzyskać.

Konfiguracja programisty

Zamiast korzystać z plików binarnych działających w środowisku fizycznym, przyjrzymy się, co jest potrzebne do skonfigurowania tych dwóch baz danych w środowisku Dockera. Konfiguracja Dockera zarówno dla MongoDB, jak i Couchbase jest dość prosta. Couchbase wymaga kilku dodatkowych portów do odsłonięcia, ale jest to prosta sprawa. Po ściągnięciu obrazów i uruchomieniu kontenerów zauważalna jest różnica w doświadczeniu programisty. Z MongoDB to wszystko. Możesz połączyć się przez aplikację lub powłokę Mongo i od razu zabrać się do pracy. Z kolei Couchbase prowadzi Cię przez obowiązkowy proces konfiguracji za pośrednictwem interfejsu użytkownika, w którym masz do czynienia z wieloma opcjami konfiguracyjnymi skierowanymi do inżynierów infrastruktury. Jako programista możesz zachować wybrane opcje i użyć domyślnego zasobnika, ale dodaje to tarcia do doświadczenia.

MongoDB wygrywa to, ale nie bez zastrzeżenia. To, że lokalne wdrożenie było łatwe, nie oznacza, że ​​możesz zrobić to samo w środowisku produkcyjnym. Może się wydawać oczywiste, że środowiska produkcyjne wymagają więcej uwagi i konfiguracji, ale powszechne ataki okupu na niezabezpieczone, publicznie dostępne instancje MongoDB na początku tego roku sugerują, że wiele sklepów idzie na niebezpieczne skróty.

Zwycięzca rundy: MongoDB.

Konfiguracja produkcji

Wdrażanie rozproszonej bazy danych w środowisku produkcyjnym zwykle obejmuje wiele etapów i wystarczający stopień koordynacji; MongoDB i Couchbase nie różnią się od siebie. W obu przypadkach trudność konfiguracji będzie zależeć od wymagań wdrożenia, z różnymi kompromisami wydajnościowymi obejmującymi różne poziomy złożoności.  

Klastry MongoDB będą składać się z zestawu replik lub klastra podzielonego na fragmenty. Zestaw replik to grupa serwerów MongoDB, które zawierają te same dane, podczas gdy podzielony na fragmenty klaster dystrybuuje dane w wielu zestawach replik. Zestawy replik są proste w konfiguracji i składają się z jednego typu serwera do wdrożenia. Klastry podzielone na fragmenty są bardziej zaangażowane i wymagają wdrożenia trzech różnych typów serwerów, z których każdy jest replikowany. Klastry można konfigurować za pomocą flag wiersza polecenia, plików konfiguracyjnych i poleceń bazy danych.

Klastry Couchbase mogą składać się z jednego typu serwera lub z wielu typów serwerów, w zależności od wymaganych parametrów wydajnościowych klastra. Architektura Couchbase składa się z różnych usług, które można włączać i wyłączać dla każdego węzła. W prostym scenariuszu włączasz wszystkie usługi we wszystkich węzłach. Jeśli jednak wymagane jest dostrojenie do potrzeb każdej usługi lub chcesz niezależnie skalować każdą usługę, będziesz musiał rozpocząć konfigurację różnych typów serwerów, przydzielić sprzęt do obsługi danych, dyski SSD do usługi indeksowania, zoptymalizować procesor pod kątem usługa zapytań i tak dalej. Klastry można konfigurować za pośrednictwem wbudowanego interfejsu WWW, interfejsu wiersza poleceń i interfejsu API REST.

Jeśli chodzi o konfigurację produkcyjną infrastruktury danych, zarówno MongoDB, jak i Couchbase są dość jasne. Oczywiście, możesz zagłębić się w opcje konfiguracji i dostrajania i nigdy nie wyjdą, ale w większości przypadków będą one łatwiejsze dla inżynierów infrastruktury.

Zwycięzca rundy: remis. 

Administracja

Gdy baza danych jest uruchomiona w środowisku produkcyjnym i przyjmuje ruch, administracja staje się kluczowym problemem. Aby ocenić łatwość administrowania, przyjrzę się procesowi tworzenia kopii zapasowych, aktualizacjom baz danych i podejściom do monitorowania.

Kopie zapasowe

Kopie zapasowe są ważnym elementem higieny produkcyjnej bazy danych, a uruchamianie baz danych w wysoce dostępny, rozproszony sposób nie zmienia tego ani trochę.

MongoDB oferuje kilka opcji tworzenia kopii zapasowych danych uruchomionego klastra. Jeśli podstawowy system operacyjny obsługuje migawki z określonego punktu w czasie, możesz polegać na tej funkcji, aby przechwycić kopię zapasową w określonym momencie. Jest to trochę trudne w przypadku tworzenia kopii zapasowych podzielonych na fragmenty klastrów, ponieważ będziesz musiał wykonać migawkę wtórną każdego fragmentu i serwera konfiguracji w tym samym czasie.

Narzędzia na poziomie systemu, takie jak cp lub rsync, mogą służyć do kopiowania plików bazy danych do innej lokalizacji, ale zapisy muszą być wstrzymane podczas procesu ze względu na charakter tych narzędzi. Chociaż MongoDB jest dostarczany z narzędziami wiersza polecenia do tworzenia kopii zapasowych i przywracania baz danych, narzędzia te nie są zalecane w przypadku większych klastrów. Alternatywnie możesz zapłacić za Cloud Manager lub Ops Manager lub wdrożyć za pośrednictwem platformy MongoDB Atlas DBaaS, aby uzyskać narzędzia oparte na interfejsie użytkownika, które zajmą się tworzeniem kopii zapasowych i przywracaniem.

Couchbase jest dostarczany z narzędziami wiersza poleceń do tworzenia kopii zapasowych danych z różnych usług, które można skonfigurować do wykonywania pełnych kopii zapasowych lub dwóch rodzajów przyrostowych kopii zapasowych. Przyrostowe kopie zapasowe mogą być przyrostowe od ostatniej pełnej kopii zapasowej (skumulowana przyrostowa) lub przyrostowe od ostatniej kopii dowolnego rodzaju (różnicowe przyrostowe). Pozwala to na tworzenie złożonych struktur kopii zapasowych, które wymagają różnych poziomów przestrzeni dyskowej i obejmują różne poziomy złożoności przywracania.

Klienci korporacyjni mogą skorzystać z narzędzia cbbackupmgr, które wykorzystuje różne podstawowe struktury danych w celu uzyskania lepszej wydajności podczas tworzenia kopii zapasowych danych.

Zwycięzca rundy: Couchbase, ze względu na większą elastyczność i obsługę przyrostowych kopii zapasowych.

Aktualizacja

Długo działający klaster powinien mieć jasną i łatwą ścieżkę aktualizacji. Im trudniej jest uaktualnić, tym mniej prawdopodobne jest, że będzie aktualizowany. Oznacza to, że zarówno programiści, jak i administratorzy stracą dostęp do nowych funkcji.

Uaktualnienia MongoDB najlepiej zrozumieć z poziomu zestawu replik. Jeśli korzystasz z podzielonego na fragmenty klastra, najczęściej postępujesz zgodnie z instrukcjami uaktualniania zestawów replik na każdym fragmencie. W zestawie replik każda pomocnicza jest wyłączana, aktualizowana na miejscu i uruchamiana. Gdy części pomocnicze działają i są zgodne z podstawowym, następuje przełączenie awaryjne, a poprzednia podstawowa może zostać usunięta i zaktualizowana. Uruchomi się ponownie jako pomocniczy i nadrobi zaległości w zapisach, które przegapił w trybie offline. W związku z tym uaktualnienia są w większości procesem online, ale podstawowe przełączenie awaryjne prawdopodobnie spowoduje 10 do 20 sekund braku zapisów, więc wymagane jest okno obsługi z akceptowalnym czasem przestoju.

Couchbase podchodzi do aktualizacji w taki sam sposób, w jaki dodaje się lub usuwa węzeł z klastra. Wszystkie dane węzła uaktualniania muszą zostać ponownie zrównoważone w całym klastrze, a następnie ponownie zrównoważone po zakończeniu uaktualniania i ponownym połączeniu węzła z klastrem. Ten proces równoważenia musi nastąpić dla każdego węzła w klastrze, jeden po drugim. To zajmie dużo więcej czasu niż aktualizacja klastra MongoDB ze względu na wszystkie dane, które muszą zostać przeniesione. Inną opcją jest przełączenie całego klastra w tryb offline, uaktualnienie każdego węzła i przywrócenie ich wszystkich do trybu online.

Podczas gdy ścieżka aktualizacji Couchbase nie wymaga przestojów, proces jest długi i wymaga dużej ilości tasowania danych.

Zwycięzca rundy: remis. Tiebreaker: jeśli przestój konserwacyjny jest akceptowalny, wygrywa MongoDB. Jeśli nie, to Couchbase jest jedynym wyborem.

Monitorowanie

Widoczność działającego klastra jest oczywiście niezbędna do skutecznego administrowania bazą danych. Kiedy coś idzie nie tak, nic nie jest gorsze niż posiadanie ograniczonego poglądu na prawdę w klastrze.

MongoDB oferuje narzędzia i polecenia interfejsu wiersza polecenia w powłoce, które zapewniają metryki aktywności i wydajności instancji. Poza tym MongoDB z przyjemnością wskaże Ci narzędzia innych firm lub własne produkty korporacyjne (Cloud Manager, Ops Manager, Atlas).

Z drugiej strony Couchbase jest dostarczany z interfejsem internetowym, który zawiera statystyki i wizualizacje instancji, węzłów, wydajności zapytań i nie tylko. Ponadto Couchbase można skonfigurować tak, aby wysyłał powiadomienia e-mail, gdy określone statystyki wykraczają poza zakres.

Zwycięzca rundy: Couchbase, do wizualizacji gotowych do użycia i ostrzegania.

Łatwość użycia

Po skonfigurowaniu bazy danych i spełnieniu wszystkich naszych potrzeb administracyjnych, główny problem przesuwa się z operacji do użytkowania. Podzielę to na modelowanie danych, projektowanie indeksów, podstawowe zapytania i agregacje.

Modelowanie danych

Jako bazy danych dokumentów, ani MongoDB, ani Couchbase nie mogą uniknąć problemu związanego z przetwarzaniem danych relacyjnych. Oba oferują możliwość przechowywania danych relacyjnych jako zagnieżdżonych, zdenormalizowanych danych, a także w postaci odniesień do innych dokumentów najwyższego poziomu. Takie podejście do przechowywania danych okazuje się być głównym punktem do rozważenia przy modelowaniu danych dla obu baz danych, mimo że każda z nich obsługuje coraz większy zakres przypadków użycia, funkcji i wzorców zapytań.

Zwycięzca rundy: remis.

Projekt indeksu

Indeksy pełnią tę samą funkcję w bazach danych dokumentów, co w relacyjnych bazach danych. Oznacza to, że reprezentują pewne dane w bardziej efektywny sposób, aby zwiększyć wydajność zapytań. MongoDB i Couchbase mają bardzo różne podejścia do projektowania i tworzenia indeksów.

MongoDB obsługuje tworzenie indeksów dla jednego lub więcej pól w dokumencie, umożliwiając określenie kolejności i kierunku (rosnąco lub malejąco) standardowych indeksów. Możliwe jest również uwzględnienie specjalnych indeksów geoprzestrzennych i indeksów pełnotekstowych jako części tej samej składni. Silnik zapytań użyje tych indeksów, prefiksów tych indeksów lub kombinacji kilku indeksów w celu przyspieszenia żądań.

Couchbase wykorzystuje dwa różne mechanizmy poprawiające wydajność zapytań: widoki MapReduce i Global Secondary Index (GSI). Widoki MapReduce składają się ze zdefiniowanego przez użytkownika kodu JavaScript, który przetwarza dane w trakcie ich przechodzenia przez system, podobnie jak przyrostowa agregacja wstępna. Widoki MapReduce mogą być tak proste, jak umożliwienie wyszukiwania dokumentów w polu wewnętrznym lub mogą obejmować bardziej złożoną logikę, która wykonuje obliczenia i agregacje danych w dokumentach.

Pisanie MapReduce w JavaScript do obsługi zapytań jest trochę nieporęczne, więc ogólnie będziesz chciał używać GSI tam, gdzie to możliwe. Indeksy w GSI są opisywane przy użyciu N1QL (wymawiane jako „nickel”), częściowej implementacji języka SQL na bazie Couchbase. Składnia N1QL jest dość przejrzysta, a zapytania N1QL są znacznie lepsze niż MapReduce, ale musisz umieścić indeks w określonym węźle. Jeśli chcesz, aby indeks był wysoce dostępny, musisz ręcznie utworzyć ten indeks w więcej niż jednym węźle.

Zwycięzca rundy: MongoDB, za skonsolidowane indeksowanie API i możliwość całkowitego uniknięcia MapReduce.

Podstawowe zapytania

Biorąc pod uwagę odpowiedni model danych, większość zapytań do bazy danych jest zwykle prosta. Poza operacjami CRUD, w których znany jest identyfikator danego dokumentu, ważne jest, aby móc wyrazić różne sposoby filtrowania dokumentów i wybrać, które pola nas interesują.

MongoDB opisuje zapytania w formacie JSON, udostępniając deklaratywną składnię do określania warunków i filtrów w polach. Dokument zapytania może składać się z dowolnej liczby selektorów zapytania, które opisują, jak powinien wyglądać zestaw wyników. Zakresy, równość, wyszukiwanie tekstowe i zapytania geoprzestrzenne można zdefiniować w tym dokumencie zapytania. Dokument wspiera operatorów logicznych, tak wiele klauzul zapytań można logicznie połączone ze sobą AND, ORi tak dalej. Dokument zapytania może szybko przekształcić się w mocno zagnieżdżony dokument JSON, który czasami może być przytłaczający i zdecydowanie wymaga przyzwyczajenia. Możliwe jest również wykorzystanie prognoz w zapytaniach, co pozwala zwracać tylko te pola, na których Ci zależy, i zmniejszać ogólny rozmiar wyniku w sieci.