Kiedy używać MongoDB lub innych systemów baz danych zorientowanych na dokumenty? [Zamknięte]


516

Oferujemy platformę do klipów wideo i audio, zdjęć i grafiki wektorowej. Zaczęliśmy od MySQL jako zaplecza bazy danych, a ostatnio dołączyliśmy MongoDB do przechowywania wszystkich meta-informacji plików, ponieważ MongoDB lepiej spełnia wymagania. Na przykład: zdjęcia mogą zawierać informacje Exif , filmy mogą zawierać ścieżki audio, w których również chcemy przechowywać meta-informacje. Filmy i grafika wektorowa nie dzielą się żadnymi typowymi meta-informacjami itp., Więc wiem, że MongoDB doskonale nadaje się do przechowywania tych nieuporządkowanych danych i umożliwienia wyszukiwania.

Nadal jednak rozwijamy naszą platformę i dodajemy funkcje. Teraz jednym z kolejnych kroków będzie stworzenie forum dla naszych użytkowników. Powstaje teraz pytanie: użyj bazy danych MySQL, która byłaby dobrym wyborem do przechowywania forów i postów na forum itp., Czy też użyj do tego MongoDB?

Pytanie brzmi: kiedy używać MongoDB, a kiedy RDBMS. Co byś wziął, mongoDB lub MySQL, gdybyś miał wybór i dlaczego miałby to zrobić?


12
Nie jestem pewien, dlaczego jest to oznaczone jako oparte na opiniach, skoro tak nie jest. Tutaj jest wyraźna dobra lub zła odpowiedź.
Spencer

Odpowiedzi:


659

W NoSQL: Gdyby to było takie łatwe , autor pisze o MongoDB:

MongoDB nie jest magazynem kluczy / wartości, jest o wiele więcej. Zdecydowanie nie jest to również RDBMS. Nie użyłem MongoDB w produkcji, ale użyłem go trochę do zbudowania aplikacji testowej i jest to bardzo fajny zestaw. Wydaje się być bardzo wydajny i albo ma, albo będzie miał wkrótce, odporność na awarie i automatyczne sharding (inaczej skaluje się). Myślę, że Mongo może być najbliższą wymianą RDBMS, którą widziałem do tej pory. Nie będzie działać dla wszystkich zestawów danych i wzorców dostępu, ale jest zbudowany dla typowych elementów CRUD. Większość ludzi używa relacyjnej bazy danych do przechowywania tego, co jest w zasadzie ogromnym hashem i możliwości wyboru dowolnego z tych kluczy.Jeśli twój DB to 3NF i nie wykonujesz żadnych połączeń (po prostu wybierasz kilka tabel i łączysz wszystkie obiekty razem, na przykład to, co większość ludzi robi w aplikacji internetowej), MongoDB prawdopodobnie skopałby ci tyłek.

Następnie na zakończenie:

Rzeczywistą rzeczą, na którą należy zwrócić uwagę, jest to, że jeśli powstrzymujesz się od zrobienia czegoś super niesamowitego, ponieważ nie możesz wybrać bazy danych, robisz to źle. Jeśli znasz mysql, po prostu go użyj. Zoptymalizuj, kiedy naprawdę potrzebujesz. Używaj go jak sklepu ak / v, używaj go jak rdbms, ale na miłość boską, zbuduj swoją aplikację zabójcy! Nic z tego nie będzie miało znaczenia dla większości aplikacji. Facebook nadal bardzo często korzysta z MySQL. Wikipedia bardzo często korzysta z MySQL. FriendFeed bardzo często korzysta z MySQL. NoSQL jest świetnym narzędziem, ale z pewnością nie będzie twoją przewagą konkurencyjną, nie sprawi, że twoja aplikacja będzie gorąca, a przede wszystkim Twoi użytkownicy nie będą się tym przejmować.

Na czym mam zbudować następną aplikację? Prawdopodobnie Postgres. Czy użyję NoSQL? Może. Mogę również użyć Hadoop i Hive. Mogę trzymać wszystko w płaskich plikach. Może zacznę hakować Maglev. Użyję wszystkiego, co najlepsze do pracy. Jeśli potrzebuję raportowania, nie będę używać żadnego NoSQL. Jeśli będę potrzebować pamięci podręcznej, prawdopodobnie użyję Tokyo Tyrant. Jeśli potrzebuję ACIDity, nie będę używać NoSQL. Jeśli potrzebuję tony liczników, skorzystam z Redis. Jeśli będę potrzebować transakcji, skorzystam z Postgres. Jeśli mam mnóstwo jednego rodzaju dokumentów, prawdopodobnie użyję Mongo. Gdybym musiał pisać 1 miliard przedmiotów dziennie, prawdopodobnie użyłbym Voldemorta. Gdybym potrzebował wyszukiwania pełnotekstowego, prawdopodobnie użyłbym Solr. Gdybym potrzebował wyszukiwania pełnotekstowego danych niestabilnych, prawdopodobnie użyłbym Sfinksa.

Podoba mi się ten artykuł, uważam go za bardzo pouczający, daje dobry przegląd krajobrazu NoSQL i szumu. Ale i to jest najważniejsze, naprawdę pomaga zadać sobie właściwe pytania, jeśli chodzi o wybór między RDBMS i NoSQL. Warto przeczytać IMHO.

Alternatywny link do artykułu


4
dzięki, to naprawdę bardzo interesujący artykuł.
aurora


48
@iddqd ROFL! Człowieku, to było przezabawne. „Jeśli jesteś na tyle głupi, aby całkowicie zignorować wiarygodność tylko po to, aby uzyskać testy porównawcze, sugeruję, aby przesyłać dane /dev/null, będzie to bardzo szybkie” : D
Pascal Thivent

3
Dzięki za hype świadomą odpowiedź.
deamon

2
Mamy nadzieję, że BJ Clark nie zdecyduje się na wykorzystanie wszystkich tych technologii w tym samym projekcie. To byłaby krzywa uczenia się.
Adam Monsen

186

Po dwóch latach używania MongoDb jako aplikacji społecznościowej, widziałem, co to naprawdę znaczy żyć bez SQL RDBMS.

  1. W końcu piszesz zadania, takie jak łączenie danych z różnych tabel / kolekcji, co RDBMS zrobi dla ciebie automatycznie.
  2. Twoje możliwości zapytań w NoSQL są drastycznie sparaliżowane. MongoDb może być najbliżej SQL, ale wciąż jest bardzo daleko w tyle. Zaufaj mi. Zapytania SQL są bardzo intuicyjne, elastyczne i wydajne. Zapytania MongoDb nie są.
  3. Zapytania MongoDb mogą pobierać dane tylko z jednej kolekcji i korzystać z tylko jednego indeksu. A MongoDb jest prawdopodobnie jedną z najbardziej elastycznych baz danych NoSQL. W wielu scenariuszach oznacza to więcej podróży w obie strony na serwer w celu znalezienia powiązanych rekordów. A potem zaczynasz od normalizować dane - co oznacza zadania w tle.
  4. Fakt, że nie jest to relacyjna baza danych, oznacza, że ​​nie będziesz mieć (zdaniem niektórych złej wydajności) ograniczeń klucza obcego, aby zapewnić spójność danych. Zapewniam cię, że w końcu spowoduje to niespójność danych w Twojej bazie danych. Być przygotowanym. Najprawdopodobniej zaczniesz pisać procesy lub kontrole, aby zachować spójność bazy danych, co prawdopodobnie nie będzie lepsze niż pozwolenie RDBMS na wykonanie tego za Ciebie.
  5. Zapomnij o dojrzałych ramach, takich jak hibernacja.

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


10
ciekawe myśli ...
luigi7up

3
Z drugiej strony, możliwości zapytań i sprzężenia, które opisujesz, nie powinny stanowić problemu: jeśli korzystasz z MongoDB, nadal musisz wykonać pewne zadanie, aby zaprojektować swoje kolekcje i jakie dane w nich umieścisz, abyś nie potrzebował skomplikowanych DOŁĄCZ i tak dalej. W każdym razie bazy danych nie są wąskim gardłem i istnieją rozwiązania takie jak Memcache w niektórych przypadkach użycia. Jeśli zaczynasz od zera, może się okazać, że projektowanie i używanie MongoDB jest prostsze i szybsze (jako programista pracujący z kodem obiektowym nie potrzebuję ORM). Pewnie, że musisz napisać kilka skryptów, ale tak naprawdę nie jest to takie trudne i ponownie używasz kodu
Aki

1
Większość ludzi nie będzie korzystać z baz danych NoSQL do bardzo konkretnego przypadku, dla którego zostały stworzone, wymyślając na nowo tyle kół. W NoSQL vs. SQL debata pokazuje, że wielu ludzi doświadczenia w korzystaniu NoSQL jakby były wracając 20-30 lat w czasie, do pre-Codd, pre-relacyjne, czasy pre-SQL . Lub, jak to ujął Michael Stonebraker: „Co się dzieje, nadchodzi”
Lukas Eder,

1
Czy pozycja nr 3 „i skorzystaj z tylko jednego indeksu” jest nadal aktualna? Właśnie wchodzę do MongoDB i wydaje się, że z tego, co przeczytałem / obejrzałem do tej pory, mogę obsługiwać wiele indeksów?
Jeach

1
@Jeach: Nie, nr 3 nie jest już prawdą. MongoDB 2.6 wprowadził przecięcie indeksu .
Rob Garrison

26

do przechowywania tych nieuporządkowanych danych

Jak powiedziałeś, MongoDB najlepiej nadaje się do przechowywania nieustrukturyzowanych danych. A to może uporządkować twoje dane w formacie dokumentu. Te alternatywy RDBMS zwane magazynami danych NoSQL ( 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.

A implementacja tych baz danych jest prostsza niż zwykły RDBMS. Ponieważ są to proste obiekty binarne o wartości klucza lub stylu dokumentu, bezpośrednio zserializowane na dysk. Te magazyny danych nie wymuszają właściwości ACID ani żadnych schematów . Nie zapewnia to żadnych możliwości transakcyjnych . Dzięki temu można skalować na dużą skalę i możemy uzyskać szybszy dostęp (zarówno do odczytu, jak i do zapisu).

Jednak w przeciwieństwie do RDBM wymusza ACID i schematy danych. Jeśli chcesz pracować z danymi strukturalnymi, możesz skorzystać z RDBM.

Wybrałbym MySQL do tworzenia forów tego typu. Ponieważ to nie będzie miało dużej skali. Jest to bardzo prosta (powszechna) aplikacja, która ma uporządkowane relacje między danymi.


10
„Wybrałbym mysql do tworzenia rzeczy na forach”. Naprawdę? Myślę, że takie fora jak forum byłyby o wiele łatwiejsze do pisania przy użyciu baz danych zorientowanych na dokumenty niż relacyjnych (jeśli pisałeś je od zera). Jeśli nie potrzebujesz konkretnie funkcji RDBMS, powiedziałbym, że idź z MongoDB lub podobną bazą danych dla łatwości użycia i skalowania.
Sasha Chedygov

2
CouchDB ma obsługę ACID. couchdb.apache.org/docs/overview.html
Sonia

2018: MongoDB ma również obsługę ACID
Nepoxx

10

Pamiętaj, że Mongo zasadniczo przechowuje JSON. Jeśli twoja aplikacja ma do czynienia z wieloma obiektami JS (z zagnieżdżaniem) i chcesz je utrwalić, istnieje bardzo silny argument za użyciem Mongo. Sprawia, że ​​warstwy DAL i MVC są bardzo cienkie, ponieważ nie rozpakowują wszystkich właściwości obiektu JS i próbują dopasować je do struktury (schematu), do której naturalnie nie pasują.

Mamy system, który ma kilka złożonych JS Objects w sercu, i uwielbiamy Mongo, ponieważ możemy przetrwać wszystko naprawdę, bardzo łatwo. Nasze obiekty są również raczej amorficzne i nieustrukturyzowane, a Mongo pochłania tę komplikację bez mrugnięcia okiem. Mamy niestandardową warstwę raportowania, która odszyfrowuje amorficzne dane do spożycia przez ludzi, i nie było to trudne do opracowania.


7

Powiedziałbym, że używaj RDBMS, jeśli potrzebujesz skomplikowanych transakcji. W przeciwnym razie wybrałbym MongoDB - bardziej elastyczny w pracy i wiesz, że można go skalować, kiedy trzeba. (Jestem jednak stronniczy - pracuję nad projektem MongoDB)


7
Złożone transakcje nie działają w MongoDB, ale działają w innych bazach danych NoSQL, takich jak MarkLogic (jestem również stronniczy, ponieważ prowadzę społeczność programistów dla MarkLogic).
Eric Bloch

Dzięki za podpowiedź dla MarkLogic - nie wiedziałem o tym.
aurora,

Chciałbym o tym usłyszeć od mdirolfa. Dlaczego MongoDB zdecydowało się nie realizować transakcji?
Aki

7

Kto potrzebuje rozproszonych, podzielonych forów? Może Facebook, ale jeśli nie tworzysz konkurenta na Facebooku, po prostu użyj Mysql, Postgres lub czegokolwiek, co najbardziej ci odpowiada. Jeśli chcesz wypróbować MongoDB, ok, ale nie spodziewaj się, że to zrobi dla ciebie magię. Będzie miał swoje dziwactwa i ogólną paskudność, tak jak wszystko inne, co jestem pewien, że już to odkryłeś, jeśli naprawdę już nad tym pracowałeś.

Jasne, MongoDB może wydawać się przeszywający i wydaje się łatwy na powierzchni, ale napotkasz problemy, które rozwiązały już bardziej dojrzałe produkty. Nie daj się tak łatwo zwabić, ale raczej poczekaj, aż „nosql” dojrzeje lub umrze.

Osobiście uważam, że „nosql” uschnie i umrze z powodu fragmentacji, ponieważ nie ma ustalonych standardów (prawie z definicji). Dlatego nie będę osobiście stawiać na to w przypadku długoterminowych projektów.

Jedyną rzeczą, która może zaoszczędzić „nosql” w mojej książce, jest to, że bezproblemowo integruje się z Ruby lub podobnymi językami i sprawia, że ​​język jest „trwały”, prawie bez żadnych kosztów związanych z kodowaniem i projektowaniem. Może się to zdarzyć, ale poczekam do tego czasu, nie teraz, I oczywiście musi być bardziej dojrzały.

Przy okazji, dlaczego tworzysz forum od zera? Istnieje mnóstwo forów o otwartym kodzie źródłowym, które można dostosować do większości wymagań, chyba że naprawdę tworzysz forum nowej generacji (co wątpię).


5
dzięki za odpowiedź. integracja forum to bałagan - już to zrobiliśmy i postanowiliśmy nie iść ponownie w tę stronę: nie potrzebujemy tysięcy funkcji, ale pełną integrację z naszym oprogramowaniem.
zorza polarna

4

Widziałem w wielu firmach używa MongoDB do analizy w czasie rzeczywistym z dzienników aplikacji. Jego płynność schematu naprawdę pasuje do dzienników aplikacji, w których schemat rekordów zmienia się od czasu do czasu. Również jego kolekcja Capped funkcja jest przydatna, ponieważ automatycznie usuwa stare dane, aby dopasować je do pamięci.

To jest jeden obszar, który naprawdę uważam za MongoDB, ale MySQL / PostgreSQL jest ogólnie bardziej zalecany. W sieci znajduje się wiele dokumentacji i zasobów dla programistów, a także ich funkcjonalność i niezawodność.


4

Dwa główne powody, dla których warto wybrać Mongo, to:

  • Elastyczność w projektowaniu schematów (magazyn dokumentów typu JSON).
  • Skalowalność - wystarczy dodać węzły, aby skalować się w poziomie całkiem dobrze.

Nadaje się do aplikacji Big Data. RDBMS nie jest dobry dla dużych zbiorów danych.


3

Wiesz, wszystkie te rzeczy o sprzężeniach i „złożonych transakcjach” - ale to sam Monty wiele lat temu wyjaśnił „potrzebę” COMMIT / ROLLBACK, mówiąc, że „wszystko to dzieje się w klasach logiki (a nie baza danych) w każdym razie ”- więc od początku to samo. Potrzebny jest głupi, ale niezwykle schludny i szybki silnik do przechowywania / wyszukiwania danych, do 99% tego, co robią aplikacje internetowe.


Dzięki, poruszasz tutaj interesujący punkt. Naprawdę byłbym zainteresowany wyjaśnieniem Monty'ego, ponieważ nie jestem pewien, w jaki sposób skomplikowane wycofywanie aktualizacji w wielu tabelach zachodzi w czystej logice aplikacji - nie jestem pewien, czy to naprawdę możliwe?
zorza polarna

Nie jestem też pewien „najlepszego” sposobu. Zawsze tylko śledziliśmy wszystko, co zrobiono w bazie danych, a następnie zezwalaliśmy lub cofaliśmy na poziomie aplikacji, w kodzie. Nigdy nie polegaliśmy na transakcjach, nigdzie, nigdy. Dokumenty Mongo sugerują użycie metadanych do śledzenia, które części transakcji, które można zrolować, wystąpiły, w jakim stanie jest transakcja, na wypadek, gdyby nastąpiła awaria i trzeba ją wycofać. Zabawne jest to, że robiliśmy to już razem z MySQL i innymi. To niewiele więcej pracy i skupia się na tym, co się dzieje, kiedy, gdzie i dlaczego, zamiast czarnego boksowania.
FYA,

Gdzieś na stronie 10gen znajduje się informacja na ten temat ... o tym, jak pola „blokady” lub „zapadki” są ręcznie używane do wskazywania statusu procesu wieloetapowego. Wydaje mi się, że jeśli powiększysz sam silnik MySQL, „transakcja blokowa” nadal będzie się rozszerzać na szereg kroków, bez względu na wszystko; po prostu blokady lub zapadki są wykonywane w znacznie mniejszy, szybszy sposób niż ręczne śledzenie w polach bazy danych.
FYA,

Musimy jeszcze znaleźć dobry sposób na ograniczenie demona MongoDB - pochłania prawie całą dostępną pamięć RAM dla swojego indeksu i przechowywania danych w pamięci, chociaż szybko zwalnia pamięć, gdy potrzebują go inne procesy. Byłoby jednak miło mieć „use_max_memory” lub kilka innych łatwo definiowalnych limitów, aby upewnić się, że MongoDB nie ucieknie i nie prześle serwera w zamianę wymiany (widzieliśmy to kilka razy, nawet w najnowszej wersji). Przynajmniej MySQL akceptuje wszystkie rodzaje definiowalnych limitów i wskazówek operacyjnych.
FYA,

Nie bezpośrednio powiązane, ale w pewnym sensie: używaliśmy memcached, ale zrezygnowaliśmy z powodu wciąż nierozwiązanego fiasku sterownika Memcache / Memcached PHP. Używaliśmy MongoDB jako szybkiego, tymczasowego klucza: val store (dla którego działało świetnie!) Aż do odkrycia, jak szybka i łatwa jest apc_store (). Jeśli okaże się, że APC zapełnia się tymczasowym crudem (w porównaniu do zapisanego wstępnie skompilowanego PHP), którego używaliśmy do przechowywania w memcached, wrócimy do MongoDB po klucz: val storage.
FYA,

1

Jak powiedziano wcześniej, możesz wybierać spośród wielu opcji, spójrz na te wszystkie opcje: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Sugeruję, aby 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ż jestem do tego przyzwyczajony, a potem zaczynam używać innych struktur bazy danych. W jednym projekcie możesz na przykład połączyć MySQL i MongoDB!


MySQL + memcached zapewni Ci ostateczną spójność. Którego nie uważam za ACID w kontekście RDMB.
R. van Twisk
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.