Kiedy powinniśmy używać MongoDB?

MongoDB to baza danych NoSQL, którą uważam za dość łatwą w użyciu. Niedawno musiałem opracować prostą aplikację, która musiała zbierać niektóre dane za pomocą żądań HTTP i przechowywać niektóre wyniki po przetworzeniu danych, i próbowałem użyć MongoDB.

Z tego doświadczenia wynika, że ​​korzystanie z niego jest dużo przyjemniejsze niż tradycyjnych relacyjnych baz danych, a ponieważ jestem programistą, a nie DBA, moja praca została znacznie uproszczona.

Mimo to czasami nie jestem pewien, kiedy powinienem używać MongoDB zamiast tradycyjnej relacyjnej bazy danych, takiej jak SQL Server lub MySQL.

W takim przypadku, kiedy możemy użyć MongoDB zamiast relacyjnych baz danych? Czy istnieje jakieś naprawdę duże zastrzeżenie dotyczące MongoDB, które sprawia, że ​​jest niewłaściwe w niektórych sytuacjach?

Gruntownie:

• Jeśli możesz reprezentować swoje dane w postaci zestawu dokumentów, MongoDB może być dobrym wyborem.

• Jeśli wolisz wyobrazić sobie swoje dane jako zestaw połączonych ze sobą tabel, MongoDB może nie być dobrym wyborem.

Oto dwa przykłady, które uważam za ilustrujące:

• Kilka lat temu stworzyłem silnik blogów. Jego celem jest prowadzenie artykułów na blogu, a dla każdego artykułu przechowywanie różnych wersji, niektórych metadanych, statystyk odwiedzin itp.

  Można to zapisać jako zbiór tabel, ale przy próbie zbudowania modelu rośnie bardzo szybko do kilkunastu tabel, jeśli nie więcej. Niektóre zapytania SQL mogą być brzydkie przy wielu joins i ... cóż, masz obraz.

  Problem polega na tym, że istnieje centralna rzecz - artykuł na blogu - i wszystkie te rzeczy wokół tego artykułu, co sprawia, że ​​dobrze nadaje się do baz danych opartych na dokumentach. W MongoDB modelowanie bazy danych było niezwykle łatwe: jedna kolekcja zawiera artykuły na blogu, a druga niewielka kolekcja zawiera listę użytkowników, którzy mogą pisać artykuły. Każdy dokument w pierwszej kolekcji zawierałby wszystkie informacje, których potrzebuję, aby wyświetlić artykuł, czy to nazwisko autora, czy tagi.

• Teraz wyobraź sobie zupełnie inny projekt. Niektórzy użytkownicy mogą pisać i udostępniać treści napisane przez innych użytkowników. Na stronie użytkownika można oczekiwać zarówno tego, co napisał ten użytkownik, jak i tych, które udostępniła. Jest jedno ograniczenie: gdy ktoś edytuje to, co napisał w przeszłości, zmiana pojawia się wszędzie tam, gdzie udostępniono oryginalny tekst.

  Przy podejściu opartym na dokumencie trudno jest znaleźć dokument. Może użytkownik? To dobry początek. Dokument użytkownika zawierałby wszystkie rzeczy napisane przez tego użytkownika. Ale co z rzeczami, które udostępniła?

  Możliwym sposobem jest umieszczenie tych rzeczy w tym samym dokumencie. Problem z tym podejściem polega na tym, że jeśli ktoś edytuje wpis, aplikacja powinna przejść przez każdy dokument użytkownika w bazie danych w celu edycji każdego wystąpienia starego wpisu. Nie licząc duplikacji danych.

  Alternatywą byłoby przechowywanie w dokumencie użytkownika tylko listy wpisów udostępnionych przez tego użytkownika (z identyfikatorem poleconego użytkownika i wpisu). Ale teraz pojawiłby się inny problem: gdyby użytkownik udostępnił tysiące wpisów od tysięcy użytkowników, otwarcie tych dokumentów wymagałoby otwarcia tysięcy dokumentów.

  Lub możemy modelować naszą kolekcję wokół samych wpisów, każdy z nich odnosi się do autora i ma listę użytkowników, którzy go udostępnili. Również w tym przypadku problemy z wydajnością mogą stać się zauważalne, gdy trzeba przejrzeć wszystkie dokumenty, aby pokazać te opublikowane przez danego użytkownika.

  Ile potrzebowałbyś tabel, gdybyś używał relacyjnej bazy danych? Racja trzy. Byłoby to łatwe do modelowania, a także łatwe w użyciu.

Każda technologia ma swoje zalety.

Zaletą relacyjnych baz danych jest to, że RDBMS robi dla Ciebie pewne rzeczy, takie jak:

• Egzekwowanie integralności referencyjnej (niedozwolone wstawianie szczegółów faktury, jeśli faktura, do której należy, nie istnieje)
• Unikaj redundancji: rzeczy są przechowywane tylko raz.
• Złożone zapytania można wykonywać za pomocą języka deklaratywnego (SQL), który jest dojrzały, sprawdzony i szeroko rozpowszechniony.

Wszystko sprowadza się do tego, że musisz napisać mniej kodu, ponieważ RDBMS wymusza dla ciebie pewne rzeczy.

Dodatkowo niezależność danych: często, jeśli używasz standardowych struktur SQL, a nie struktur specyficznych dla dostawcy, możesz migrować dane z jednego RDBMS do drugiego przy minimalnym wysiłku, podczas gdy bazy danych NOSQL wcale nie są standaryzowane.

Z drugiej strony jedną z zalet baz danych NOSQL jest to, że skalują one lepiej utrzymując wydajność dla milionów wierszy. Lepiej nadają się do przechowywania dokumentów, tj. Danych nieustrukturyzowanych. Ale większość aplikacji nie potrzebuje tych funkcji.

W twoim przypadku MongoDB wydaje się dobrym wyborem, ale istnieje wiele scenariuszy (prawdopodobnie większość z nich), w których nie byłby to najlepszy wybór.

MongoDB jest bardziej odpowiedni w scenariuszach, które wymagają odczytu / zapisu dużej ilości danych, bez większego nacisku na bezpieczeństwo transakcji (jeśli niektóre dane czasami gubią się w wyniku awarii serwera, nie jest to wielka sprawa), spodziewaj się dużej skali i nie naprawdę mają stabilny schemat.

MongoDB nie nadaje się do scenariuszy, które wymagają:

1. Silne gwarancje ACID: MongoDB pozwala na przechowywanie duplikatów danych, niespójne odczyty, a nawet utratę danych. Te rzeczy są dobre w niektórych aplikacjach, ale nie w większości.
2. Transakcje z wieloma obiektami: MongoDB obsługuje transakcje ACID, ale tylko dla jednego obiektu / dokumentu. To po prostu nie ograniczy go do bardziej złożonych operacji, takich jak przelewy bankowe, dokonywanie rezerwacji itp.
3. Tradycyjne BI: istnieje wiele narzędzi BI, które działają dobrze tylko z tradycyjnym SQL.
4. SQL: MongoDB ma bardzo specyficzny język zapytań, podczas gdy SQL jest bardzo dobrze znany przez wiele osób (może być ważnym aspektem do rozważenia), może robić wiele skomplikowanych rzeczy (podczas gdy z MongoDB miałbyś problemy z wykonaniem prostego dołącz) i można go przenosić w wielu implementacjach.

MongoDB jest szybszy i pozwoli ci wyciszyć większą wydajność z systemu, eliminując wiele rzeczy, które domyślnie wymuszają RDBMS, takich jak kontrole integralności (pamiętaj, że i tak możesz dostosowywać RDBMS do takich celów), ale prawda jest taka, że w większości scenariuszy jest to po prostu niepotrzebne. Ponadto kompromisem jest niezawodność i elastyczność (będziesz mieć problemy, jeśli później zdecydujesz, że musisz wykonywać bardziej złożone operacje z istniejącymi danymi).

Wszystko zależy od potrzeb tworzonej aplikacji. Czy to szybkość i dostępność, czy bezpieczeństwo, niezawodność i elastyczność. Musisz wiedzieć, gdzie w Twoich danych (i połączeniach danych) leży większa wartość. Jeśli jeszcze tego nie wiesz, prawdopodobnie najlepiej jest wybrać coś, co nie spowoduje, że wpadniesz w zakręt w przyszłości i pozwoli Ci dodać funkcje i wykonać operacje, których potrzebuje Twoja aplikacja.

MongoDB jest świetny, gdy możesz reprezentować swoje dane jako niezależne „paczki” informacji. Masz kody pocztowe Google Maps, w kodzie pocztowym osadzone są firmy, a wewnątrz firm są pracownicy. Wszystkie kody pocztowe są od siebie niezależne, a wszystkie informacje można uzyskać w prosty, ładny i szybki sposób. To dobry scenariusz dla rozwiązania innego niż SQL.

Powiedziawszy to, całkowicie nie zgadzam się z obecnym trendem, który wyglądam, co sugeruje, że MongoDB jest rodzajem postu i doskonałego rozwiązania dla RDBMS, a noSQL musi być domyślnie twoim rozwiązaniem. Wszystko to jest absurdalne. MongoDB jest niszową bazą danych, a 90% projektów jest relacyjnych i potrzebuje opcji RDBMS, ponieważ chcesz potężnego rozwiązania do zapytań, takiego jak SQL, do generowania raportów i szukania rozproszonych danych: „dołączenia” są pro, a nie oszustwem. Poza tym współczesne RDBMS obsługuje kolekcje BSON i integrację geoprzestrzenną, więc może nisza dla noSQL jest teraz jeszcze węższa.

MongoDB jest przydatny do przechowywania wszystkich danych strukturalnych potrzebnych do zbudowania danego wystąpienia strony internetowej. Możesz pobrać dane dla danej strony, przekazać je do aplikacji klienckiej, która następnie je wyrenderuje.

W takim kontekście MongoDB jest bardzo szybki i niezawodny. Ale nigdy nie zapominaj, że nie masz informacji o relacjach w swojej bazie danych. Co oznacza, że ​​jeśli zmienisz coś w strukturze strony, możesz nie być w stanie wypełnić dziur w już przechowywanych stronach, ponieważ nie masz danych potrzebnych do tego. Więcej na ten temat tutaj: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/