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

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ć?

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

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

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

Używanie RDBMS zamiast innych typów:

• Przeczytaj o „NoSQL” i innych typach DB:
  • NoSQL: Gdyby to było takie proste
  • (powyższe jest powiązane z) Kiedy używać MongoDB lub innych systemów baz danych zorientowanych na dokumenty? ^{obecnie usunięty na SO} ( więcej )
  • https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • Kiedy stosować CouchDB vs RDBMS
• RDBMS często korzystają z indeksowania w celu zwiększenia wydajności. W bardzo dużych bazach danych może to mieć negatywny wpływ na wydajność, a nawet zmniejszyć optymalną liczbę wierszy na DB / Odłamek wymagającą więcej sprzętu
• Nie tak idealne, jeśli przechowujesz ogromną ilość danych, ale odczytujesz rzadziej
• Jeśli nie masz wielu relacji zagranicznych, relacyjne bazy danych mogą nie być idealne (przechowywanie dokumentów)

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).

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.

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.

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ń.

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

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.