Kiedy korzystać z MongoDB lub innych systemów bazodanowych zorientowanych na dokumenty? [zamknięte]

Po dwóch latach używania MongoDb jako aplikacji społecznościowej, byłem świadkiem, co tak naprawdę oznacza życie bez SQL RDBMS.

1. w końcu piszesz zadania, aby robić takie rzeczy, jak łączenie danych z różnych tabel/kolekcji, coś, co RDBMS zrobiłby dla ciebie automatycznie.
2. twoje możliwości zapytań z NoSQL są drastycznie sparaliżowane. MongoDb może być najbliższy SQL, ale nadal jest bardzo daleko w tyle. Zaufaj mi. Zapytania SQL są super intuicyjne, elastyczne i potężny. Zapytania MongoDb nie są.
3. zapytania MongoDb mogą pobierać dane tylko z jednej kolekcji i wykorzystywać tylko jeden indeks. A MongoDb jest prawdopodobnie jedną z najbardziej elastycznych baz danych NoSQL. W wielu scenariuszach oznacza to więcej podróży w obie strony do serwera, aby znaleźć powiązane rekordy. A potem zaczynasz od normalizacji danych - co oznacza zadania w tle.
4. fakt, że nie jest to relacyjna baza danych oznacza, że nie będziesz miał (uważanego przez niektórych za źle wykonującego) klucza obcego ograniczenia zapewniające spójność danych. Zapewniam cię, że w końcu doprowadzi to do powstania niespójności danych w Twojej bazie danych. Bądź przygotowany. Najprawdopodobniej zaczniesz pisać procesy lub kontrole, aby utrzymać spójność bazy danych, co prawdopodobnie nie będzie działać lepiej niż pozwolić RDBMS zrobić to za Ciebie.
5. zapomnij o dojrzałych frameworkach, takich jak hibernate.

Uważam, że 98% wszystkich projektów prawdopodobnie jest o wiele lepiej z typowym SQL RDBMS niż z NoSQL.

Do przechowywania tych nieustrukturyzowanych danych

Jak powiedziałeś, MongoDB najlepiej nadaje się do przechowywania nieustrukturyzowanych danych. To może zorganizować Twoje dane w formacie dokumentu. Te altenatywy RDBMS o nazwie NoSQL data stores (MongoDB, CouchDB, Voldemort) są bardzo przydatne w aplikacjach, które skalują się masowo i wymagają szybszego dostępu do danych z tych dużych magazynów danych.

I implementacja tych baz danych jest prostsza niż regularne RDBMS. Ponieważ są to proste obiekty binarne o wartości klucza lub stylu dokumentu bezpośrednio serializowane na dysk. Te magazyny danych nie wymuszają właściwości kwasu , ani żadnych schematów . To nie zapewnia żadnych zdolności transakcji. Dzięki temu może to być skalowane i możemy osiągnąć szybszy dostęp (zarówno do odczytu, jak i do zapisu).

Ale w przeciwieństwie do tego, RDBM wymusza kwasy i schematy na danych. Jeśli chcesz pracować ze strukturyzowanymi danymi, możesz skorzystać z RDBM.

I would wybierz MySQL do tworzenia forów do tego rodzaju rzeczy. Bo to nie będzie wielka skala. Jest to bardzo prosta (wspólna) aplikacja, która ma uporządkowane relacje między danymi.

Zauważ, że Mongo zasadniczo przechowuje JSON. Jeśli Twoja aplikacja ma do czynienia z wieloma obiektami JS (z zagnieżdżeniem) i chcesz utrzymywać te obiekty, to istnieje bardzo silny argument za używaniem Mongo. To sprawia, że warstwy DAL i MVC są ultra cienkie, ponieważ nie są one un-pakowania wszystkich właściwości obiektów JS i próbuje wymusić dopasować je do struktury (schematu), że nie pasują naturalnie.

Mamy system, który ma kilka złożonych obiektów JS w sercu i kochamy Mongo, ponieważ możemy wytrwać wszystko naprawdę, naprawdę łatwo. Nasze obiekty są również raczej amorficzne i niestrukturalne, a Mongo wchłania tę komplikację bez mrugania. Mamy niestandardową warstwę raportowania, która odszyfrowuje amorficzne dane do spożycia przez ludzi, a to nie było takie trudne do opracowania.

Powiedziałbym, że użyj RDBMS, jeśli potrzebujesz złożonych transakcji. W przeciwnym razie wybrałbym MongoDB-bardziej elastyczny w pracy i wiesz, że może się skalować, gdy trzeba. (Jestem jednak stronniczy - pracuję nad projektem MongoDB)

Komu potrzebne rozproszone, sharded fora? Facebook może Facebook, ale jeśli nie tworzysz Facebooka-konkurenta, po prostu użyj Mysql, Postgres lub cokolwiek, co najbardziej Ci odpowiada. Jeśli chcesz spróbować MongoDB, ok, ale nie oczekuj, że zrobi to za Ciebie Magia. Będzie miał swoje dziwactwa i ogólną złośliwość, tak jak Wszystko inne, jak jestem pewien, że już odkryłeś, jeśli naprawdę już nad tym pracowałeś.

Jasne, MongoDB może być hyped i wydawać się łatwe na powierzchni, ale można uruchomić na problemy, które dojrzalsze produkty już przezwyciężyły. Nie daj się tak łatwo zwabić, ale raczej poczekaj, aż "nosql" dojrzeje lub umrze.

Osobiście uważam, że "nosql" uschnie i umrze od fragmentacji, ponieważ nie ma ustalonych standardów (prawie z definicji). Nie będę więc osobiście stawiał na to żadnych długoterminowych projektów.

Jedyną rzeczą, która może zapisać "nosql" w mojej książce, jest to, że może bezproblemowo zintegrować się z Ruby lub podobnymi językami i sprawić, że język będzie "trwały", prawie bez żadnych kosztów związanych z kodowaniem i projektowaniem. To może się zdarzyć, ale poczekam do tego czasu, nie teraz, i to musi być bardziej dojrzałe oczywiście.

Btw, dlaczego tworzysz forum od podstaw? Istnieje mnóstwo forów open source, które można dostosować do większości wymagań, chyba że naprawdę tworzysz nową generację forów (w co wątpię).

Po udziale w Devoxx 2011 i Prezentacji z 10Gen, napisałem mały blog porównujący bazy danych MongoDB do RDBMS. MongoDB jest jednym z popularnych NoSQL dbs. Zobacz poniżej:

Http://blog.iprofs.nl/2011/11/25/is-mongodb-a-good-alternative-to-rdbms-databases-like-oracle-and-mysql/

Widziałem, że wiele firm używa MongoDB do analizy czasu rzeczywistego z dzienników aplikacji. Jego schema-freeness naprawdę pasuje do dzienników aplikacji, gdzie schemat rekordów ma tendencję do zmiany czasu na czas. Ponadto funkcja Capped Collection jest przydatna, ponieważ automatycznie czyści stare dane, aby utrzymać je w pamięci.

To jest jeden z obszarów, do którego naprawdę myślę, że MongoDB pasuje, ale MySQL / PostgreSQL jest bardziej zalecany w ogóle. Jest wiele dokumentów i zasoby programistyczne w sieci, a także ich funkcjonalność i solidność.

2 główne powody, dla których możesz chcieć preferować Mongo są

• elastyczność w projektowaniu schematów (magazyn dokumentów typu JSON).
• skalowalność - wystarczy dodać węzły i może skalować poziomo dość dobrze.

Nadaje się do aplikacji big data. RDBMS nie jest dobry dla dużych danych.

Wiesz, te wszystkie rzeczy o joinach i' złożonych transakcjach ' -- ale to sam Monty wiele lat temu wyjaśnił "potrzebę" COMMIT / ROLLBACK, mówiąc, że 'wszystko, co jest robione w klasach logicznych (a nie w bazie danych) i tak' -- więc jest to znowu to samo. Potrzebny jest głupi, ale niesamowicie schludny i szybki silnik do przechowywania/pobierania danych, dla 99% tego, co robią aplikacje internetowe.

Jak już wcześniej, możesz wybierać między wieloma wyborami, spójrz na te wszystkie wybory: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Proponuję znaleźć najlepszą kombinację: MySQL + Memcache jest naprawdę świetny, jeśli potrzebujesz ACID i chcesz dołączyć do niektórych tabel MongoDB + Redis jest idealny do przechowywania dokumentów Neo4J jest idealny do bazy danych grafów

Co robię: zaczynam od MySQl + Memcache ponieważ używam do, potem zaczynam używać innych Framework bazy danych. W jednym projekcie możesz na przykład połączyć MySQL i MongoDB !