Kiedy ktoś użyje MongoDB (lub podobnego) w relacyjnym DBMS?

133

Jestem trochę zdezorientowany całą rzeczą NoSQL i tym podobne. Kiedy zdecydujesz się użyć czegoś takiego jak MongoDB zamiast czegoś takiego jak Oracle lub MySQL? Naprawdę nie rozumiem „różnicy”, jeśli chodzi o użycie między nimi.

Z mojego zrozumienia bazy danych typu NoSQL nie mają na celu zastąpienia RDBMS, ale co dokładnie mają robić?

Glorfindel
źródło
Co czytałeś Czy możesz podać nam oferty, linki lub inne informacje? Nie wiemy, ile wiesz - ani nie wiesz.
S.Lott,
3
Do momentu przeniesienia tutaj, o StackOverflow istnieje kilka bardzo podobnych pytań , w tym Kiedy używać MongoDB lub innych systemów baz danych zorientowanych na dokumenty?
Nicole,
1
To jest mongodb-is-web-scale.com / s na skalę internetową
Froome
3
Cynicznie: Ponieważ jest to hype słowo i wiele osób lubi podążać za hiper.
Sjoerd
@Pace: Myślę, że trudno będzie pokonać ten post .
Robert Harvey

Odpowiedzi:

33

Użyłem CouchDB wcześniej do trzech projektów domowych.

  • System mikro blogów.
  • Za zapisanie informacji dla małej aplikacji do robienia notatek, którą zrobiłem.
  • Aplikacja burzy mózgów ogólnego przeznaczenia.

Głównym powodem, dla którego wybrałem to w porównaniu z MSSQL lub MySQL, jest elastyczność, którą uzyskujesz podczas korzystania z niego. Brak sztywnego schematu. Jeśli trzy miesiące później potrzebujesz określonego stołu, aby mieć dodatkowe pole, i to i tamto, po prostu je zmienisz, a ono zacznie falować odtąd.

Użyłem Beginning CouchDB firmy Apress, aby nauczyć się go używać.

Na przykład CouchDB używa json do komunikacji z bazą danych. Jeśli Twój język może przesyłać dane POST, możesz użyć go do komunikacji z bazą danych.

Przeczytaj także: Dlaczego powinienem używać baz danych opartych na dokumentach zamiast relacyjnych baz danych? na StackOverflow

Społeczność
źródło
31
Pierwsze dwa przykłady brzmią jak dobra domena dla tradycyjnego relacyjnego DBMS.
Jonas
4
@yati: Ten rodzaj aplikacji brzmi podobnie do StackOverflow.com i uważam, że działa bardzo dobrze z tradycyjną relacyjną bazą danych.
Jonas,
4
@yatisagade: Nie mówimy o dynamicznych serwisach społecznościowych. Ale mała aplikacja do robienia notatek i system mikro blogów .
Jonas,
2
Jak zdefiniowanie schematu nigdy nie jest zaletą? W przypadku relacyjnej bazy danych, jeśli trzy miesiące później potrzebujesz dodatkowego pola, po prostu dodajesz to pole. Z relacyjną bazą danych nie można dynamicznie dodawać pola, ale nie można również dynamicznie zmieniać kodu aplikacji, aby działał z polem dodawanym dynamicznie.
Tajny Solomonoff
11
Ta odpowiedź wydaje się sugerować, że nie można zmienić schematu relacyjnej bazy danych. Nie jestem w stanie zrozumieć, ile nieporozumień może doprowadzić do uwierzenia w to. Dodawanie nowej kolumny do relacyjnej bazy danych jest banalne. Zazwyczaj jest to przyjemny interfejs użytkownika, a jeśli wolisz go napisać, możesz to zrobić za pomocą pojedynczej instrukcji SQL.
JacquesB,
23

Przykro nam, że dodałem kolejną odpowiedź, ale żadna z odpowiedzi tutaj nie jest bardzo zadowalająca. Ta odpowiedź jest specyficzna dla MongoDB (w przeciwieństwie do szerokiej gamy innych opcji przechowywania danych, które nie są relacyjnymi bazami danych).

Plusy:

  • MongoDB ma mniejsze opóźnienie na zapytanie i spędza mniej czasu procesora na zapytanie, ponieważ wykonuje znacznie mniej pracy (np. Brak złączeń, transakcji). W rezultacie może obsłużyć większe obciążenie pod względem liczby zapytań na sekundę, a zatem jest często używane, jeśli masz ogromną liczbę użytkowników.
  • MongoDB jest łatwiejszy do podzielenia (użycia w klastrze), ponieważ nie musi martwić się o transakcje i spójność.
  • MongoDB ma większą prędkość zapisu, ponieważ nie musi się martwić transakcjami ani wycofaniami (a zatem nie musi się martwić blokowaniem).
  • MongoDB nie ma schematu na wypadek, gdybyś miał specjalny przypadek użycia, który mógłby z tego skorzystać.

Cons:

  • MongoDB nie obsługuje transakcji . W ten sposób uzyskuje większość swoich korzyści.
  • Ogólnie MongoDB tworzy więcej pracy (np. Większy koszt procesora) dla serwera klienta . Na przykład, aby połączyć dane, należy wykonać wiele zapytań i wykonać połączenie na kliencie.
  • Nawet tutaj, w 2017 roku, obsługa narzędzi MongoDB jest mniejsza niż w przypadku relacyjnych baz danych tylko dlatego, że jest nowsza. Jest też mniej ekspertów MongoDB niż ich relacyjnych odpowiedników.

Punkty często źle rozumiane:

  • Zarówno MongoDB, jak i relacyjne bazy danych obsługują indeksowanie. Ich wydajność zapytań jest podobna pod względem wykonywania dużych zapytań .
  • MongoDB nie eliminuje potrzeby migracji, a ściślej aktualizując istniejące dane w miarę ewolucji schematu. Na przykład: jeśli masz aplikację, która opiera się na tabeli użytkowników zawierającej określone dane, i modyfikujesz tę tabelę, aby zawierała inne dane (powiedzmy, że dodajesz pole zdjęcia profilowego), nadal będziesz musiał:
    • Napisz swoją aplikację do obsługi obiektów, dla których ta właściwość jest niezdefiniowana LUB
    • Napisz jednorazową migrację, aby wprowadzić wartość domyślną dla tej właściwości LUB
    • Napisz kod, aby podać wartość domyślną w czasie zapytania, jeśli to pole nie jest obecne LUB
    • Postępuj z brakującym polem w inny sposób
Tempo
źródło
2
Dodałbym ogromną rzecz, która w jakiś sposób jest pomijana w wielu dyskusjach NoSQL kontra RDBMS: bazy danych NoSQL są znacznie trudniejsze do tworzenia zapytań ad hoc (to jest „część bez SQL”. To prawda, czy jesteś programistą, czy nie. , są też znacznie trudniejsze do tworzenia raportów , co ma kluczowe znaczenie w każdym poważnym biznesie.
Michael
Heh, prawie nazwałbym to funkcją MongoDB, ponieważ zniechęcam do tego rodzaju interakcji z moimi bazami danych. Jednak Mongo ma język zapytań ad-hoc i graficzny klient ad-hoc (Compass). Nie jest tak bogaty w funkcje jak SQL, więc zgodzę się, że jest to potencjalna wada, ale dla mnie osobiście nigdy nie zrobi to różnicy, kiedy decyduję, której bazy danych użyć.
Tempo
1
Dlaczego miałbyś zniechęcać do eksploracji danych w bazie danych? Jeśli ta baza danych zawiera przydatne informacje dla firmy, powinna być jak najbardziej dostępna. Oczywiście nie dodając obciążenia do produkcji, po to właśnie przeczytałeś repliki.
Michael
Jest to prawdopodobnie samo w sobie interesujące pytanie i sądzę, że wiele osób miałoby inne punkty widzenia. Osobiście unikam tego, ponieważ staje się to problemem konserwacyjnym. Tworzę aplikacje internetowe i udostępniam interfejsy API REST, które zobowiązuję się utrzymywać i optymalizować pod kątem wydajności. Byłem w sytuacjach, w których nie mogę wprowadzać hurtowych zmian w bazie danych, ponieważ złamałoby to zbyt wiele skryptów zapytań inżynierów sprzedaży i staram się teraz unikać tego scenariusza. Np. Niedawno byłem częścią mojej bazy danych z PostgreSQL do Cassandry dla wysokiej wydajności i nie musiałem zmieniać mojego API.
Tempo
Ostatecznie zawsze będziesz mieć interesariuszy zainteresowanych przeglądaniem danych. Niezależnie od tego, czy jest to zapytanie SQL, skrypt skryptowy ipython, czy re: dash. Więc kiedy wprowadzasz zmiany w bazie danych, zawsze będziesz musiał upewnić się, że nie złamiesz tych zależności. SQL (nie RDBMS) sprawia, że ​​dane są bardziej dostępne, a to dobra rzecz dla firmy.
Michael
13

Aby bezwstydnie ukraść od Renesis (właściwie robię tę odpowiedź CW):


Używanie RDBMS zamiast innych typów:

Matthew Read
źródło
4
„RDBMS często wykorzystuje indeksowanie w celu zwiększenia wydajności” Czy indeksowanie nie jest również stosowane w MongoDB?
Rotareti,
Kiedy używać MongoDB lub innych systemów baz danych zorientowanych na dokumenty? obecnie usunięty na SO ... nie więcej .. ponownie otworzył pytanie i również je chronił. Nie jestem pewien uzasadnienia usunięcia.
Rahul
9

Gdy Twoje dane nie są relacyjne, korzystanie z baz danych NoSQL może przynieść znaczne korzyści, takie jak wydajność i skalowalność (oczywiście w zależności od okoliczności). Niektóre wzorce projektowe, takie jak CQRS, znacznie ułatwiają wykorzystanie danych nierelacyjnych w obszarach, które tradycyjnie wymagałyby wyłącznego korzystania z bazy danych SQL.

Często używane są bazy danych, takie jak mongo, dla danych w pamięci podręcznej. Na przykład, jeśli chcesz wygenerować raport, możesz wykonać skomplikowane zapytanie SQL, które łączy i agreguje wiązkę danych w locie, lub możesz po prostu pobrać pojedynczy dokument JSON z bazy danych Mongo, który ma już wszystko, czego potrzebujesz do wygenerowania raport. To sprawia, że ​​odczyt danych jest naprawdę łatwy (i szybki!), Ale może utrudnić zapisywanie danych (w tym miejscu pojawia się CQRS).

Graeme Hill
źródło
8

Bazy danych takie jak MongoDB są świetne, gdy zwykle wiesz, gdzie są twoje dane (w przeciwieństwie do konieczności pisania kilku skomplikowanych zapytań). W Mongo „powiązane” dane są albo zagnieżdżone w danych nadrzędnych, albo mają klucze podstawowe / obce. Jest to świetne, jeśli na przykład masz posty i komentarze; ogólnie rzecz biorąc, nie będziesz wyświetlać komentarzy poza kontekstem postu, więc sensowne jest, aby komentarze były zawarte w postie (w ten sposób otrzymujesz wszystkie komentarze do postu bez potrzeby przeszukiwania osobnej tabeli).

MongoDB jest bez schematów. Oznacza to, że w większości przypadków zajmie to dowolną strukturę danych.

Z drugiej strony, jeśli musisz korzystać z funkcji agregujących i odczuwasz potrzebę zapytania danych w skomplikowany sposób, którego nie można osiągnąć za pomocą osadzania lub prostych relacji w Mongo, wtedy wiesz, że nadszedł czas, aby użyć RDBMS, takiego jak MySQL lub PostgreSQL.

MongoDB nie ma zastąpić SQL. Po prostu spełnia różne potrzeby, a MongoDB i RDBMS mogą być używane łącznie. Moim zdaniem MongoDB nie jest wcale konieczne, jeśli nie potrzebujesz, aby Twoje dane były elastyczne lub osadzone w dokumencie nadrzędnym. Programowanie w MongoDB jest bardzo zabawne, ponieważ jest o wiele mniej kroków do uruchomienia projektu (powiedzmy w Railsach). Chcesz dokonać zmiany? Nie ma problemu. Po prostu dodaj atrybut do swojego modelu. Gotowy.

Nie mogę mówić o wielu innych bazach danych NoSQL, chociaż wiem, że są one zwykle podobnie zaprojektowane, aby zaspokoić konkretne potrzeby, których RDBMS nie może zaspokoić. Niektóre znajdują się całkowicie w pamięci lub można je bardzo łatwo odłamać lub skalować. Jestem prawie pewien, że Cassandra jest zaprojektowana tak, aby kontynuować działanie bez utraty danych, jeśli nastąpi awaria węzła. Redis jest w zasadzie kluczowym magazynem wartości, który znajduje się w pamięci (z okresowymi zapisami na dysku w celu utrwalenia), ale ma także możliwość przechowywania typów danych, takich jak zestawy i sortowania ich.

Krukon
źródło
6

Największą wygraną jest dzielenie danych lub posiadanie baz danych z wieloma wzorcami. Możesz odłamać dane w MySQL, ale zamienia się to w poważny ból. Jeśli robisz dużo zapisów, często przydatne jest dzielenie danych na wiele serwerów, problem polega na tym, że jeśli chcesz mieć silną spójność referencyjną podczas wykonywania tego, może być bardzo trudne, jeśli nie niemożliwe, sprawdzenie twierdzenia CAP.

Bazy danych SQL mają bardzo dobrą spójność, ale naprawdę kiepską obsługę partycjonowania, bazy danych NoSQL zwykle mają inną drogę. Łatwy do podziału, ale często nazywa się to spójnością. Jeśli budujesz witrynę do przesyłania wiadomości, która jest w porządku, dla banku prawdopodobnie nie jest OK.

Plusem jest to, że istnieje teraz wiele modeli przechowywania danych, więc istnieje wybór sposobu implementacji rzeczy, a przede wszystkim bazy danych SQL.

SE Radio miało kilka dobrych odcinków na ten temat.

Zachary K.
źródło
Należy pamiętać, że sharding jest silnie uzależniony od architektury twojego centrum danych. Jeśli masz szafę serwerową, jej wydajność jest niesamowita. Na rozproszonych DC, nie tak bardzo. Uzgodniono, co mówisz o ogólnej łatwości partycjonowania w bazach danych NoSql - ale niezawodność jest kluczowym problemem.
Apoorv Khurasia
Jeśli wykonujesz dużo zapisów, możesz po prostu mieć 2 modele: zdenormalizowany model odczytu indeksów indeksowych ORAZ nieindeksowany model zapisu. Oczywiście konieczna jest replikacja, co zwiększa złożoność. Będziesz musiał ocenić, co jest dla Ciebie bardziej niekorzystne: radzenie sobie z ograniczeniami NoSQL, tj. Zrób o wiele więcej pracy programistycznej, aby dopasować rekordy w domenie Java, lub poproś o pracę z istniejącą technologią replikacji DB, albo będziesz musiał zapłacić więcej na warunkach konfiguracji i sprzętu.
Lawrence
1

MongoDB działa dobrze, gdy piszesz dużo danych, a twoje potrzeby dotyczące zapytań nie są zbyt skomplikowane. Dlatego MongoDB dobrze pasuje, gdy wdrażasz CQRS z Event Sourcing po stronie Command - tzn. Twój sklep zdarzeń jest bazą danych MongoDB.

Po stronie zapytań nadal używamy bazy danych SQL Server z widokami i usługami danych WCF na wierzchu, ze względu na jego elastyczność. Myślę, że w większości przypadków naprawdę potrzebujesz mocy relacyjnej bazy danych do tworzenia zapytań.

Roy Dictus
źródło
Jeśli piszesz dużo danych, czy globalne blokady zapisu nie wpłyną negatywnie na Ciebie?
Apoorv Khurasia
1
Zauważ, że Mongodb nie używa już globalnej blokady zapisu (i została już zaktualizowana, aby nie wymagała jej, gdy powyższy komentarz został opublikowany).
Jules
1

Bezpośrednią i podstawową różnicą między MongoDB a RDBMS jest podstawowy model danych. Relacyjna baza danych porządkuje dane w tabelach i wierszach, a MongoDB porządkuje dane w kolekcje dokumentów JSON. JSON to samoopisujący się, czytelny dla człowieka format danych. Pierwotnie zaprojektowany do lekkich wymian między przeglądarką a serwerem, został powszechnie przyjęty do wielu rodzajów aplikacji.

Dokumenty JSON są szczególnie przydatne do zarządzania danymi z kilku powodów. Dokument JSON składa się z zestawu pól, które same są parami klucz-wartość. Oznacza to, że każdy dokument JSON ma własny projekt schematu czytelny dla człowieka, gdziekolwiek się znajduje, umożliwiając tym samym łatwe przenoszenie dokumentów między bazą danych a aplikacjami klienckimi bez utraty ich znaczenia.

JSON to także naturalny format danych do użytku w warstwie aplikacji. JSON obsługuje bogatszą i bardziej elastyczną strukturę danych niż tabele złożone z kolumn i wierszy. Oprócz obsługiwanych typów pól, takich jak liczba, łańcuch, wartość logiczna itp., Pola JSON mogą być tablicami lub zagnieżdżonymi podobiektami. Oznacza to, że możemy reprezentować zestaw wyrafinowanych relacji, które są bliższą reprezentacją obiektów, z którymi współpracują nasze aplikacje. Korzystanie z dokumentów JSON w naszej bazie danych oznacza, że ​​nie potrzebujemy mapowania obiektów relacyjnych między naszą bazą danych a obsługiwanymi przez nią aplikacjami. Możemy zachować nasze dane we właściwej formie

Diwakar upadhyay
źródło
1

Jeśli twoje dane wymagają wielu zapytań, to rozwiązanie NoSQL nie jest dobre, a gdy potrzebujesz wsparcia transakcyjnego (ACID), NoSql nie jest najlepszym rozwiązaniem. Myślę, że NoSQL świeci, gdy masz dużo odczytów, które muszą być szybkie, a gdy struktura jest nieco doraźna, pobierasz według dokumentu lub struktury strony, coś w tym rodzaju. Ale wiele rozwiązań NoSQL poprawia się dość szybko, więc niedociągnięcia mogą wkrótce zniknąć. W każdym razie myślę, że relacyjne bazy danych nadal dobrze pasują do większości aplikacji.

marko
źródło