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

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

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

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.

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.

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.

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)

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

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ść.

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.

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.

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!