Jakie są zalety korzystania z bazy danych bez schematu, takiej jak MongoDB, w porównaniu z relacyjną bazą danych?

Jestem przyzwyczajony do korzystania z relacyjnych baz danych, takich jak MySQL lub PostgreSQL, w połączeniu z frameworkami MVC, takimi jak Symfony, RoR lub Django i myślę, że działa świetnie.

Ale ostatnio dużo słyszałem o MongoDB, która jest nierelacyjną bazą danych lub, cytując oficjalną definicję ,

skalowalna, wydajna baza danych typu open source, wolna od schematów i zorientowana na dokumenty.

Jestem naprawdę zainteresowany byciem na krawędzi i chcę być świadomy wszystkich opcji, które będę miał dla następnego projektu i wybierać najlepsze dostępne technologie.

W jakich przypadkach używanie MongoDB (lub podobnych baz danych) jest lepsze niż używanie „klasycznych” relacyjnych baz danych? Jakie są ogólne zalety MongoDB w porównaniu z MySQL? A przynajmniej dlaczego jest tak inny?

Jeśli masz wskazówki do dokumentacji i / lub przykładów, byłoby to również bardzo pomocne.

Oto niektóre zalety MongoDB do tworzenia aplikacji internetowych:

1. Model danych oparty na dokumentach. Podstawowa jednostka pamięci jest analogiczna do JSON, słowników Pythona, skrótów Ruby itp. Jest to bogata struktura danych, która może przechowywać tablice i inne dokumenty. Oznacza to, że często można przedstawić w pojedynczej encji konstrukcję, która wymagałaby kilku tabel do prawidłowego przedstawienia w relacyjnej bazie danych. Jest to szczególnie przydatne, jeśli dane są niezmienne.
2. Możliwość głębokich zapytań. MongoDB obsługuje dynamiczne zapytania dotyczące dokumentów przy użyciu języka zapytań opartego na dokumentach, który jest prawie tak potężny jak SQL.
3. Brak migracji schematów. Ponieważ MongoDB nie zawiera schematów, Twój kod definiuje schemat.
4. Jasna droga do skalowalności w poziomie.

Będziesz musiał przeczytać więcej na ten temat i bawić się nim, aby uzyskać lepszy pomysł. Oto demo online:

http://try.mongodb.org/

Zalet jest wiele.

Na przykład schemat bazy danych będzie bardziej skalowalny, nie będziesz musiał martwić się o migracje, kod będzie przyjemniejszy do pisania ... Na przykład tutaj jest jeden z kodów mojego modelu:

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

Dodanie klucza to po prostu dodanie linii kodu!

Są też inne zalety, które pojawią się na dłuższą metę, takie jak lepsza skalowalność i szybkość.

... Pamiętaj jednak, że nierelacyjna baza danych nie jest lepsza niż relacyjna . Jeśli twoja baza danych ma wiele relacji i normalizacji, użycie czegoś takiego jak MongoDB może nie mieć sensu. Chodzi o znalezienie odpowiedniego narzędzia do pracy.

Aby dowiedzieć się więcej, polecam zajrzeć do " Dlaczego myślę, że Mongo jest dla baz danych tym, czym Railsy dla frameworków " lub ten post na stronie mongodb. Aby być podekscytowanym i jeśli mówisz po francusku, zapoznaj się z tym artykułem wyjaśniającym, jak skonfigurować MongoDB od podstaw.

Edycja: Prawie zapomniałem ci powiedzieć o tym railscastie przez Ryana . Jest to bardzo interesujące i sprawia, że ​​chcesz zacząć od razu!

Zaletą braku schematu jest to, że możesz zrzucić wszystko, co w nim jest, i nikt nigdy nie będzie miał podstaw do narzekania na to lub do mówienia, że ​​było źle.

Oznacza to również, że cokolwiek w nim wrzucisz, pozostaje całkowicie pozbawione znaczenia po tym, jak to zrobisz.

Niektórzy uznaliby to za poważną wadę, inni nie.

Fakt, że relacyjna baza danych ma ugruntowany schemat, jest konsekwencją tego, że ma ugruntowany zestaw predykatów ekstensjonalnych, które pozwalają nadać znaczenie temu, co jest zapisane w bazie, a które są jest to również dla nas konieczny warunek wstępny.

Bez ugruntowanego schematu, bez ekstensjonalnych predykatów i bez ekstensjonalnych prekatów, nie ma możliwości, aby użytkownik wyciągnął jakiekolwiek znaczenie z tego, co zostało w nim upchane.

MongoDB pojawiło się w tym tygodniu w FLOSS Weekly - http://twit.tv/floss105 Bazą danych wykorzystującą podobną koncepcję jest CouchDB, która pojawiła się w innym tygodniku FLOSS: http://twit.tv/floss36

Myślę, że warto posłuchać tych oprócz linków podanych przez @marcgg

Moje doświadczenie z Postgresem i Mongo po pracy z obydwoma bazami danych w moich projektach.

Postgres (RDBMS)

Postgres jest zalecany, jeśli twoje przyszłe aplikacje mają skomplikowany schemat, który wymaga wielu złączeń lub wszystkie dane mają relacje lub jeśli mamy ciężki zapis. Postgres jest open source, szybszy, zgodny z ACID i zużywa mniej pamięci na dysku, a także zapewnia dobrą wydajność w przypadku pamięci masowej JSON i obejmuje pełną serializowalność transakcji z 3 poziomami izolacji transakcji.

Największą zaletą pozostania z Postgresem jest to, że mamy to, co najlepsze z obu światów. Możemy przechowywać dane w JSONB z ograniczeniami, spójnością i szybkością. Z drugiej strony możemy używać wszystkich funkcji SQL dla innych typów danych. Podstawowy silnik jest bardzo stabilny i dobrze radzi sobie z szerokim zakresem wolumenów danych. Działa również na wybranym sprzęcie i systemie operacyjnym. Postgres zapewniający możliwości NoSQL wraz z pełną obsługą transakcji, przechowujący dokumenty JSON z ograniczeniami na danych pól.

Ogólne ograniczenia dla Postgres

Skalowanie Postgres w poziomie jest znacznie trudniejsze, ale wykonalne.

Szybkich operacji odczytu nie można w pełni osiągnąć za pomocą Postgres.

NO Bazy danych SQL

Mongo DB (Wired Tiger)

MongoDB może pokonać Postgres w wymiarze „skali poziomej”. Przechowywanie JSON jest tym, do czego Mongo jest zoptymalizowane. Mongo przechowuje swoje dane w formacie binarnym o nazwie BSONb, który jest (z grubsza) tylko binarną reprezentacją nadzbioru JSON. MongoDB przechowuje obiekty dokładnie tak, jak zostały zaprojektowane. Według MongoDB, w przypadku aplikacji intensywnie zapisujących, Mongo twierdzi, że nowy silnik (Wired Tiger) zapewnia użytkownikom nawet 10-krotny wzrost wydajności zapisu (powinienem spróbować), z 80-procentowym zmniejszeniem wykorzystania pamięci masowej, pomagając obniżyć koszty pamięci masowej osiągnąć większe wykorzystanie sprzętu.

Ogólne ograniczenia MongoDb

Użycie silnika pamięci masowej bez schematu prowadzi do problemu niejawnych schematów. Te schematy nie są definiowane przez nasz silnik pamięci masowej, ale zamiast tego są definiowane na podstawie zachowania i oczekiwań aplikacji.

Samodzielne technologie NoSQL nie spełniają standardów ACID, ponieważ poświęcają krytyczne zabezpieczenia danych na rzecz wysokiej przepustowości w aplikacjach nieustrukturyzowanych. Zastosowanie ACID w bazach danych NoSQL nie jest trudne, ale spowodowałoby to do pewnego stopnia powolność i brak elastyczności bazy danych. „Większość ograniczeń NoSQL została zoptymalizowana w nowszych wersjach i wydaniach, które w dużym stopniu przezwyciężyły poprzednie ograniczenia”.

Chodzi o kompromisy. MongoDB jest szybki, ale nie ACID, nie ma transakcji. W niektórych przypadkach jest lepszy niż MySQL, aw innych gorzej.

Bellow Lines Written in MongoDB: The Definitive Guide.

Jest kilka dobrych powodów:

1. Przechowywanie różnych rodzajów dokumentów w tej samej kolekcji może być koszmarem dla programistów i administratorów. Programiści muszą upewnić się, że każde zapytanie zwraca tylko dokumenty określonego rodzaju lub że kod aplikacji wykonujący zapytanie może obsługiwać dokumenty o różnych kształtach. Jeśli pytamy o posty na blogu, trudno jest odfiltrować dokumenty zawierające dane autora.
2. Uzyskanie listy kolekcji jest znacznie szybsze niż wyodrębnienie listy typów w kolekcji. Na przykład, gdybyśmy mieli w kolekcji klucz typu, który mówi, czy każdy dokument jest dokumentem „przeglądowym”, „całym” czy „grubą małpą”, znalezienie tych trzech wartości w jednym zbiorze byłoby znacznie wolniejsze niż mają trzy oddzielne kolekcje i wyszukują ich nazwy
3. Grupowanie dokumentów tego samego rodzaju razem w tym samym zbiorze umożliwia lokalizację danych. Uzyskanie kilku postów na blogu ze zbioru zawierającego tylko posty będzie prawdopodobnie wymagało mniej poszukiwań dysku niż uzyskanie tych samych postów ze zbioru zawierającego posty i dane autora.
4. Tworząc indeksy, zaczynamy narzucać jakąś strukturę naszym dokumentom. (Jest to szczególnie prawdziwe w przypadku indeksów unikatowych). Indeksy te są definiowane dla każdej kolekcji. Umieszczając w tej samej kolekcji tylko dokumenty jednego typu, możemy wydajniej indeksować nasze zbiory

Po pytaniu o bazy danych z tekstową pamięcią masową, zerknąłem na MongoDB i podobne systemy.
Jeśli dobrze zrozumiałem, mają być łatwiejsze w obsłudze i konfiguracji oraz znacznie szybsze. Być może też bezpieczniejsze, ponieważ brak SQL uniemożliwia wstrzyknięcie SQL ...
Najwyraźniej MongoDB jest używany głównie do aplikacji internetowych.
Zasadniczo, i twierdzą, że same te bazy danych nie są przystosowane do złożonych zapytań, eksploracji danych itp. Ale błyszczą w szybkim pobieraniu dużej ilości płaskich danych.

1. MongoDB obsługuje wyszukiwanie według pól, wyszukiwanie wyrażeń regularnych Zawiera zdefiniowane przez użytkownika funkcje skryptów java.
2. MongoDB może być używany jako system plików, korzystając z funkcji równoważenia obciążenia i replikacji danych na wielu komputerach do przechowywania plików.