Kiedy używać CouchDB w stosunku do MongoDB i odwrotnie

Utknąłem między tymi dwiema bazami danych NoSQL.

W moim projekcie będę tworzyć bazę danych w bazie danych. Na przykład potrzebuję rozwiązania do tworzenia dynamicznych tabel.

Użytkownicy mogą tworzyć tabele z kolumnami i wierszami. Myślę, że albo MongoDB, albo CouchDB będą do tego odpowiednie, ale nie jestem pewien, który z nich. Potrzebuję również wydajnego stronicowania.

Z C, A i P (spójność, dostępność i tolerancja partycji), które 2 są dla Ciebie ważniejsze? Krótki przegląd, wizualny przewodnik po systemach NoSQL

• MongodB: Spójność i tolerancja podziału
• CouchDB: dostępność i tolerancja partycji

W blogu porównanie Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j zawiera scenariusze „ najlepiej używane ” dla każdej porównywanej bazy danych NoSQL. Cytując link,

• MongoDB: jeśli potrzebujesz zapytań dynamicznych. Jeśli wolisz definiować indeksy, nie mapuj / zmniejszaj funkcji. Jeśli potrzebujesz dobrej wydajności na dużym DB. Jeśli chciałeś CouchDB, ale Twoje dane zmieniają się zbyt mocno, zapełniając dyski.
• CouchDB: Do gromadzenia, czasami zmieniających się danych, na których mają być uruchamiane wstępnie zdefiniowane zapytania. Miejsca, w których ważne jest przechowywanie wersji.

Ostatnie (luty 2012 r.) I bardziej wyczerpujące porównanie autorstwa Riyada Kalli,

• MongoDB: TYLKO replikacja Master-Slave
• CouchDB: Replikacja Master-Master

Wpis na blogu (październik 2011 r.) Autorstwa kogoś, kto wypróbował jedno i drugie, facet z MongoDB dowiaduje się, że CouchDB skomentował, że stronicowanie CouchDB nie jest tak przydatne.

Datowany (czerwiec 2009) test porównawczy autorstwa Kristiny Chodorow ( część zespołu stojącego za MongoDB ),

Wybrałbym MongoDB.

Mam nadzieję, że to pomoże.

Odpowiedzi przede wszystkim komplikują historię.

1. Jeśli planujesz mieć komponent mobilny lub potrzebujesz użytkowników komputerów stacjonarnych do pracy offline, a następnie zsynchronizować ich pracę z serwerem, potrzebujesz CouchDB.
2. Jeśli Twój kod będzie działał tylko na serwerze, przejdź do MongoDB

Otóż ​​to. O ile nie potrzebujesz (niesamowitej) możliwości CouchDB do replikacji na urządzenia mobilne i stacjonarne, MongoDB ma obecnie przewagę pod względem wydajności, społeczności i narzędzi.

Bardzo stare pytanie, ale jest na górze Google i nie bardzo lubię odpowiedzi, które widzę, więc oto moje własne.

Couchdb ma znacznie więcej niż zdolność do rozwijania CouchApps. Większość osób korzysta z CouchDb w klasycznej trójwarstwowej architekturze internetowej.

W praktyce decydującym czynnikiem dla większości ludzi będzie fakt, że MongoDb zezwala na zapytania ad-hoc ze składnią podobną do SQL, podczas gdy CouchDb tego nie robi (musisz stworzyć mapę / zmniejszyć widoki, które wyłączają niektóre osoby, nawet jeśli tworzysz te widoki jest przyjazny dla szybkiego tworzenia aplikacji - nie mają one nic wspólnego z procedurami przechowywanymi).

Aby zająć się kwestiami podniesionymi w zaakceptowanej odpowiedzi: CouchDb ma świetny system wersjonowania, ale to nie znaczy, że nadaje się tylko (lub lepiej) do miejsc, w których wersjonowanie jest ważne. Ponadto couchdb jest przyjazny dla ciężkich zapisów, ponieważ ma charakter tylko do dołączania (operacje zapisu wracają w krótkim czasie, gwarantując, że żadne dane nigdy nie zostaną utracone).

Jedną bardzo ważną rzeczą, o której nikt nie wspomina, jest fakt, że CouchDb opiera się na indeksach b-drzewa. Oznacza to, że niezależnie od tego, czy masz 1 „wiersz”, czy 20 miliardów, czas zapytania zawsze pozostanie poniżej 10 ms. Jest to zmieniacz gier, który sprawia, że ​​CouchDb jest bazą danych o małych opóźnieniach i przyjazną do odczytu, i to naprawdę nie powinno być pomijane.

Aby być uczciwym i wyczerpującym, przewagą MongoDb nad CouchDb jest oprzyrządowanie i marketing. Posiadają najwyższej klasy narzędzia obywatelskie dla wszystkich głównych języków i platform, dzięki czemu ich wdrożenie jest łatwe, a to dodane do ich zapytań adhoc sprawia, że ​​przejście z SQL jest jeszcze łatwiejsze.

CouchDb nie ma takiego poziomu narzędzi - mimo że obecnie dostępnych jest wiele bibliotek - ale CouchDb jest dostępny jako interfejs API HTTP, dlatego łatwo jest stworzyć opakowanie w swoim ulubionym języku, aby z nim porozmawiać. Osobiście podoba mi się to podejście, ponieważ pozwala uniknąć wzdęć i pozwala ci brać tylko to, co chcesz (zasada segregacji interfejsu).

Więc powiedziałbym, że używanie jednego lub drugiego jest w dużej mierze kwestią wygody i preferencji w ich paradygmatach. Podejście CouchDb „po prostu pasuje”, dla niektórych osób, ale jeśli po zapoznaniu się z funkcjami bazy danych (w wyczerpującym oficjalnym przewodniku ) nie masz momentu „piekło tak”, prawdopodobnie powinieneś przejść dalej.

Odradzam korzystanie z CouchDb, jeśli chcesz po prostu użyć „odpowiedniego narzędzia do właściwej pracy”. bo przekonasz się, że nie możesz tego tak po prostu wykorzystać i skończysz na tym, że będziesz wkurzony i napisze posty na blogu, takie jak „Gdzie są dołączenia do CouchDb?” i „Gdzie jest zarządzanie transakcjami?”. Rzeczywiście Couchdb jest - paradoksalnie - bardzo przejrzysty, ale jednocześnie wymaga zmiany paradygmatu i zmiany w podejściu do problemów, aby naprawdę błyszczeć (i naprawdę pracować).

Ale kiedy to zrobisz, to naprawdę się opłaca. Osobiście potrzebuję bardzo silnych powodów lub poważnego przełomu w projekcie, aby wybrać inną bazę danych, ale jak dotąd nie spotkałem żadnej.

Zadaj sobie to pytanie? A ty wybierzesz DB.

1. Potrzebujesz master-master ? Następnie CouchDB. Głównie CouchDB obsługuje replikację master-master, która przewiduje rozłączanie węzłów na długi okres czasu. MongoDB nie radziłoby sobie dobrze w tym środowisku.
2. Czy potrzebujesz MAKSYMALNEJ przepustowości R / W ? Następnie MongoDB
3. Czy potrzebujesz najwyższej trwałości pojedynczego serwera, ponieważ będziesz mieć tylko jeden serwer DB? Następnie CouchDB.
4. Czy przechowujesz MASYWNY zestaw danych, który wymaga dzielenia przy jednoczesnym zachowaniu szalonej przepustowości? Następnie MongoDB.
5. Czy potrzebujesz silnej spójności danych? Następnie MongoDB.
6. Czy potrzebujesz haju? dostępności bazy danych? Następnie CouchDB.
7. Czy masz nadzieję wiele baz danych i wiele tabel / kolekcji? Następnie MongoDB
8. Masz użytkowników aplikacji mobilnej offline i chcesz zsynchronizować dane dotyczące ich aktywności z serwerem? Następnie potrzebujesz CouchDB.
9. Czy potrzebujesz dużej różnorodności zapytań ? Następnie MongoDB
10. Czy potrzebujesz dużej społeczności, aby korzystać z DB? Następnie MongoDB

Podsumowuję odpowiedzi znalezione w tym artykule:

http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the- zalety-and-disadvantages-of-each

MongoDB: Lepsze zapytania, przechowywanie danych w BSON (szybszy dostęp), lepsza spójność danych, wiele zbiorów

CouchDB: lepsza replikacja, z replikacją master do master i rozwiązywaniem konfliktów, przechowywanie danych w JSON (czytelne dla człowieka, lepszy dostęp za pośrednictwem usług REST), odpytywanie poprzez redukcję map.

Podsumowując, MongoDB jest szybszy, CouchDB jest bezpieczniejszy.

Także: http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

Należy pamiętać o problemie z rzadkimi unikalnymi indeksami w MongoDB. Uderzyłem w to i obejście tego jest bardzo kłopotliwe.

Problem polega na tym, że masz pole, które jest unikalne, jeśli jest obecne, i chcesz znaleźć wszystkie obiekty, w których pole jest nieobecne. Sposób, w jaki rzadkie unikalne indeksy są implementowane w Mongo, polega na tym, że obiekty, w których brakuje tego pola, w ogóle nie znajdują się w indeksie - nie można ich pobrać za pomocą zapytania na tym polu - {$exists: false}po prostu nie działa.

Jedynym obejściem, jakie wpadłem na to, jest posiadanie specjalnej rodziny wartości null, w której pusta wartość jest tłumaczona na specjalny prefiks (jak null :) połączony z uuid. Jest to prawdziwy ból głowy, ponieważ podczas pisania / sprawdzania / czytania należy zadbać o przekształcenie do / z pustych wartości. Poważna uciążliwość.

Nigdy nie korzystałem z wykonywania javascript po stronie serwera w MongoDB (i tak nie jest zalecane), a ich mapowanie / zmniejszanie ma okropną wydajność, gdy jest tylko jeden węzeł Mongo. Z tych wszystkich powodów rozważam teraz wypróbowanie CouchDB, może bardziej pasuje do mojego konkretnego scenariusza.

BTW, jeśli ktoś zna link do odpowiedniego wydania Mongo opisującego rzadki problem z unikalnym indeksem - udostępnij.

Jestem pewien, że możesz to zrobić z Mongo (bardziej obeznanym z nim) i całkiem pewnie, że możesz także z kanapą.

Oba są zorientowane na dokumenty (oparte na JSON), więc nie byłoby w nich „kolumn”, a raczej pola w dokumentach - ale mogą być w pełni dynamiczne.

Oboje robią to, możesz chcieć spojrzeć na inne czynniki, na których należy użyć: inne funkcje, na których ci zależy, popularność itp. Wgląd Google, oferty pracy na stronie rzeczywiście byłyby sposobami na sprawdzenie popularności.

Możesz po prostu spróbować, myślę, że powinieneś być w stanie uruchomić mongo w 5 minut.