Jeśli pochodzisz ze świata MySQL, MongoDB będzie dla Ciebie o wiele bardziej naturalne dzięki obsłudze języka podobnego do zapytań.
Myślę, że to właśnie sprawia, że jest tak przyjazny dla wielu ludzi.
CouchDB jest fantastyczny, jeśli chcesz wykorzystać naprawdę świetne wsparcie replikacji typu master-master z konfiguracją wielowęzłową, prawdopodobnie w różnych centrach danych lub coś w tym rodzaju.
Replikacja MongoDB (zestawy replik) to konfiguracja master-slave-slave-slave- *, możesz tylko zapisywać do mastera w zestawie replik i czytać z dowolnego z nich.
W przypadku standardowej konfiguracji witryny jest to w porządku. Bardzo dobrze odwzorowuje użycie MySQL.
Ale jeśli próbujesz stworzyć globalną usługę, taką jak CDN, która musi synchronizować wszystkie globalne węzły, nawet jeśli odczyt / zapis do nich wszystkich, coś takiego jak replikacja w CouchDB będzie dla ciebie ogromnym dobrodziejstwem.
Podczas gdy MongoDB ma język podobny do zapytań, którego można używać i który jest bardzo intuicyjny, CouchDB przyjmuje podejście „zmniejszania mapy” i takie koncepcje widoków. Na początku wydaje się to dziwne, ale kiedy już to zrozumiesz, naprawdę zaczyna wydawać się intuicyjne.
Oto krótki przegląd, więc ma to jakiś sens:
- CouchDB przechowuje wszystkie twoje dane w b-drzewie
- Nie możesz dynamicznie wyszukiwać go w zapytaniach, np. „SELECT * FROM user WHERE ...”
- Zamiast tego definiujesz odrębne „widoki” swoich danych ... „tutaj jest widok wszystkich moich użytkowników”, „tutaj jest widok wszystkich użytkowników w wieku powyżej 10 lat” „tutaj jest widok wszystkich użytkowników starszych niż 30” i wkrótce.
- Widoki te są definiowane przy użyciu podejścia zmniejszania mapy i są zdefiniowane jako funkcje JavaScript.
- Kiedy definiujesz widok, DB zaczyna przekazywać wszystkie dokumenty bazy danych, do której przypisałeś widok, poprzez niego i zapisywać wyniki funkcji jako „indeks” tych danych.
- Istnieje kilka podstawowych zapytań, które możesz wykonać w widokach, takich jak pytanie o określony klucz (ID) lub zakres identyfikatorów, niezależnie od tego, co robi twoja funkcja map / redukuj.
- Przeczytaj te slajdy , to najlepsze wyjaśnienie mapy / redukcji w Couch, jakie widziałem.
Tak więc oba te źródła używają dokumentów JSON, ale CouchDB podąża za podejściem „każdy serwer jest mistrzem i może synchronizować się ze światem”, co jest fantastyczne, jeśli jest to potrzebne, podczas gdy MongoDB jest naprawdę MySQL świata NoSQL.
Więc jeśli to brzmi bardziej jak to, czego potrzebujesz / chcesz, idź do tego.
Drobne różnice, takie jak protokół binarny Mongo i interfejs RESTful CouchDB, to drobne szczegóły.
Jeśli chcesz surowego szybkość i do diabła z bezpieczeństwem danych, to można dokonać Mongo szybciej niż CouchDB jak można powiedzieć to działać z pamięci i nie popełnić rzeczy na dysku z wyjątkiem rzadkich odstępach czasu.
Możesz zrobić to samo z Couch, ale jego protokół komunikacyjny oparty na HTTP będzie 2-4x wolniejszy niż nieprzetworzona komunikacja binarna z Mongo w tej "prędkości ponad wszystko!" scenariusz.
Pamiętaj, że surowa szalona szalona prędkość jest bezużyteczna, jeśli awaria serwera lub awaria dysku zepsuje i wznieci twoją bazę danych w zapomnienie, więc punkt danych nie jest tak niesamowity, jak mogłoby się wydawać (chyba że robisz systemy handlu w czasie rzeczywistym na Wall Ulica, w takim przypadku spójrz na Redis).
Mam nadzieję, że to wszystko pomoże!