When to Use MongoDB: Benefits and Use Cases
Łatwo jest złapać się na najnowsze buzzwords i używać innowacyjnej technologii, ale może to prowadzić do bólu głowy, jeśli używasz niewłaściwego narzędzia do swojego zadania. MongoDB wszedł na gorąco i ustanowił dominację w świecie NoSQL Database, kiedy weszli na giełdę w 2018 roku. W tym artykule omówimy, czym są bazy danych NoSQL i jak różnią się od baz danych SQL. Następnie dotkniemy tego, co odróżnia MongoDB w krajobrazie NoSQL. Zakończymy kilkoma przypadkami użycia MongoDB i omówimy typowe pułapki podczas korzystania z tej technologii bazy danych.
Aby uzyskać więcej informacji na temat natywnego konektora MongoDB Xplenty, odwiedź naszą stronę integracji.
Table of Contents
- NoSQL vs SQL Databases
- MongoDB: A Big Fish In a Small Pond
- MongoDB Use Cases
MongoDB 
Amazon Redshift 
DOWIEDZ SIĘ, CZY MOŻEMY ZINTEGROWAĆ TWOJE DANE
ZAUFAŁY NAM FIRMY NA CAŁYM ŚWIECIE
.
Czy podoba Ci się ten artykuł?
Otrzymuj wspaniałą zawartość co tydzień dzięki biuletynowi Xplenty!
NoSQL vs. Bazy danych SQL
MongoDB jest bazą danych NoSQL. Oznacza to, że nie używasz SQL do interakcji z danymi w bazie danych. Zamiast tego używasz NoSQL.
Pierwszą różnicą, którą należy omówić, jest słownictwo. W SQL używamy tabel. W NoSQL używamy kolekcji. W SQL, tabele składają się z rekordów/wierszy, w NoSQL, kolekcje są dokumentami.
Aby wykonać zapytanie do MongoDB, musisz użyć składni NoSQL. Oto przykład zapytania SQL i odpowiadającego mu zapytania NoSQL:
SQL:
SELECT * FROM users WHERE age > 65;
NoSQL:
users.find({age: {$gt: 65} });
Zauważysz, że język zapytań traktuje kolekcję jako obiekt, na którym stosujesz akcje. Dzieje się tak, ponieważ MongoDB jest bezschematyczną bazą danych i zakłada, że nie będzie potrzeby interakcji z innymi kolekcjami. Składnia SQL oczekuje, że użytkownicy będą JOIN na innych relacjach w bazie danych, a więc składnia ta to umożliwia. Podobny schemat występuje przy próbie INSERT:
SQL:
INSERT INTO users (id, age) VALUES (1, 70);
NoSQL:
users.insert({id: 1, age: 70});
Ważność zdefiniowanego schematu jest jasna w SQL INSERT, ponieważ kolumny, które wybierasz, muszą istnieć w tabeli users. W przypadku instrukcji NoSQL, kolumny id i wiek nie muszą istnieć w kolekcji wcześniej. W rzeczywistości, możesz wykonać inny INSERT do tej kolekcji z innymi polami. Na przykład, możemy wykonać następujące polecenie na tej samej kolekcji users, której użyliśmy powyżej:
users.insert({first_name: "Annie", zip_code: "10005"})
MongoDB, oraz inne bazy danych NoSQL, są bazami bezschematycznymi. Oznacza to, że użytkownicy mogą przechowywać niestrukturalne dane. Ta funkcjonalność jest zarówno błogosławieństwem, jak i przekleństwem – elastyczność ułatwia przechowywanie danych, ale również utrudnia ich porządkowanie.
Dogłębną analizę krytycznych różnic między bazami SQL i NoSQL można znaleźć w tym wpisie na blogu.
Amazon Redshift 
DOWIEDZ SIĘ, CZY MOŻEMY ZINTEGROWAĆ TWOJE DANE
ZAUFAŁY NAM FIRMY NA CAŁYM ŚWIECIE
.
Cieszysz się tym artykułem?
Otrzymuj świetne treści co tydzień dzięki biuletynowi Xplenty!
Kto powinien używać MongoDB
Przez kilka lat MongoDB było synonimem NoSQL w wielu kręgach. Dzięki agresywnym kampaniom marketingowym i możliwości nawiązania kontaktu z kilkoma wpływowymi osobami z branży technologicznej, udało im się zdobyć dużą część tego „nowego” rynku. W miarę jak baza danych stawała się coraz bardziej powszechna, ludzie wytykali dziury w jej przydatności do pewnych zastosowań. Stał się przydatnym narzędziem dla ludzi, którzy „po prostu chcieli dostać swoją aplikację i uruchomić” i martwić się o analizę danych później.
To było akceptowalne podejście i miało sens dla wielu twórców oprogramowania. Ostatecznie, kurczaki wróciły do domu i okazało się, że MongoDB nie jest najlepszą opcją dla wszystkich. Niektórzy inżynierowie, którzy wcześnie zaadoptowali MongoDB, mogli oprzeć się na tej technologii i dostosować się do jej ulepszeń, podczas gdy wielu innych przeszło ogromne wysiłki, aby się od niej uwolnić. Jak w przypadku każdego oprogramowania, Your Mileage May Vary (YMMV), więc konieczne jest krytyczne myślenie o usługach, z których korzystasz.
Inne opcje pojawiły się w świecie baz danych dokumentów. Postgres, na przykład, odsłonił typ kolumny JSON. Pozwoliło to użytkownikom Postgresa na przechowywanie niestrukturalnych danych wewnątrz relacyjnej bazy danych. Redis również pojawił się jako użyteczna alternatywa dla użytkowników, którzy potrzebowali magazynu wartości kluczowych. Więcej o różnicach pomiędzy MongoDB i Redis można dowiedzieć się tutaj. I, jak to się dzieje z większością udanych projektów oprogramowania, AWS wydało swoją własną bazę danych dokumentów o nazwie DocumentDB, która jest przydatna dla ludzi, którzy chcą trzymać się natywnych aplikacji AWS.
Mimo rosnącej konkurencji, MongoDB wciąż króluje w świecie NoSQL/Document-database i wciąż ulepsza swoje usługi, takie jak uczynienie go zgodnym z ACID. Ponadto, wspierając aplikacje w chmurze, MongoDB dokłada starań, aby wspierać rozproszone bazy danych i jeziora danych.
Przypadki użycia MongoDB
MongoDB jest świetną bazą danych dla aplikacji internetowych, szczególnie jeśli aplikacja obsługuje wielu użytkowników, którzy nie wchodzą ze sobą w interakcje. Pomyśl o aplikacjach usług finansowych, gdzie użytkownicy potrzebują tylko dostępu do własnych danych. Albo aplikacja do blogowania, gdzie użytkownicy chcą się logować i tworzyć/edytować własne blogi. Użytkownicy nie wchodzący ze sobą w interakcje to kluczowy wniosek. W przypadku relacyjnej bazy danych, trzeba by było przechowywać informacje o użytkowniku w kilku tabelach. Kiedy ten użytkownik się zaloguje, aplikacja musiałaby wykonać kilka zapytań lub złożonych zapytań JOIN, aby uzyskać dostęp do wszystkich informacji dla tego użytkownika. Dzięki bezschematowej bazie dokumentów MongoDB, możesz przechowywać wszystkie informacje o użytkowniku razem. Pozwoliłoby to na pojedyncze zapytanie do pojedynczej kolekcji, a front-end może zająć się wyświetlaniem/edytowaniem danych.
Innym doskonałym przypadkiem użycia MongoDB jest próba włączenia wielu zbiorów danych. Jego bezschematowa konstrukcja pozwala na elastyczność w sposobie przechowywania danych. Możesz więc przechowywać dane z kilku źródeł danych (strony internetowe, bazy danych, kanały RSS, itp.) w jednym miejscu, a następnie tworzyć usługi na szczycie swojej nowej bazy danych, aby analizować je wszystkie. Na przykład, Xplenty oferuje taką integrację dla MongoDB.
MongoDB jest świetną bazą danych do integracji danych geoprzestrzennych z innymi typami danych. Na przykład, jeśli „lokalizacja” jest częścią metadanych, z którymi pracujesz, MongoDB obsługuje typy GeoJSON, dzięki czemu możesz efektywnie przechowywać szerokość i długość geograficzną. Co więcej, MongoDB obsługuje indeksy 2DSphere, które optymalizują obliczenia geometryczne na sferach.
Wnioski
MongoDB jest potężną bazą danych z wieloma możliwościami. Jako firma przodują w popularyzacji baz danych NoSQL i Document. Jako baza danych, rozszerzyła nasze zrozumienie najlepszych praktyk przechowywania danych, a także zasiała swoją drogę do wielu aplikacji na całym świecie.
MongoDB oferuje również darmową wersję open-source, która jest doskonałą opcją dla zespołów z ograniczonym budżetem, które mogą postawić serwer bazy danych w siedzibie firmy lub w chmurze. Jeśli chciałbyś uzyskać wsparcie w tym zakresie, Xplenty może Ci pomóc. Znamy wyzwania związane z przechowywaniem, integracją i analizą danych. Niezależnie od tego, czy potrzebujesz pomocy w wyborze odpowiednich narzędzi do przechowywania danych, czy pomocy w migracji danych do nowego rozwiązania, zaplanuj rozmowę z Xplenty i dowiedz się, jak nasze przyjazne dla użytkownika rozwiązanie ETL może pracować dla Ciebie.