Когда использовать CouchDB над MongoDB и наоборот

ответы, прежде всего, усложняют историю.

1. Если вы планируете иметь мобильный компонент или хотите, чтобы пользователи рабочего стола работали в автономном режиме, а затем синхронизировали свою работу с сервером, вам нужен CouchDB.
2. Если ваш код будет работать только на сервере, тогда идите с MongoDB

очень старый вопрос, но он находится на вершине Google, и мне не совсем нравятся ответы, которые я вижу, поэтому вот мой собственный.

есть гораздо больше, чтобы Couchdb, чем способность развивать CouchApps. Большинство людей используют CouchDb в классической 3-х уровневой веб-архитектуре.

на практике решающим фактором для большинства людей будет тот факт, что MongoDb позволяет выполнять специальные запросы с синтаксисом SQL, а CouchDb-нет (вам нужно создать map/reduce views, который отключает некоторых людей даже хотя создание этих представлений является быстрой разработкой приложений-они не имеют ничего общего с хранимыми процедурами).

для решения вопросов, поднятых в принятом ответе: CouchDb имеет отличную систему управления версиями, но это не означает, что она подходит (или более подходит) только для мест, где важно управление версиями. Кроме того, couchdb удобен для записи благодаря своей добавленной природе (операции записи возвращаются в кратчайшие сроки, гарантируя, что никакие данные никогда не будут растеряться.)

одна очень важная вещь, о которой никто не упоминает,-это тот факт, что CouchDb полагается на индексы b-дерева. Это означает, что независимо от того, есть ли у вас 1 "строка" или 20 миллиардов, время запроса всегда будет оставаться ниже 10 мс. Это игровой чейнджер, который делает CouchDb базой данных с низкой задержкой и удобным для чтения, и это действительно не следует упускать из виду.

чтобы быть справедливым и исчерпывающим, преимущество MongoDb над CouchDb-это инструменты и маркетинг. У них первоклассные citizen tools для всех основных языков и платформ, что делает посадку легко, и это добавлено к их adhoc запросов делает переход от SQL еще проще.

CouchDb не имеет такого уровня инструментов - хотя сегодня доступно много библиотек, - но CouchDb предоставляется как HTTP API, и поэтому довольно легко создать оболочку на вашем любимом языке, чтобы поговорить с ней. Мне лично нравится этот подход, так как он позволяет избежать вздутия живота и позволяет вам брать только то, что вы хочу (принцип разделения интерфейса).

поэтому я бы сказал, что использование одного или другого в значительной степени является вопросом комфорта и предпочтения с их парадигмами. Подход CouchDb "просто подходит" для определенных людей, но если после изучения особенностей базы данных (в исчерпывающем официальное руководство) у вас нет вашего "черт возьми, да" момент, Вы, вероятно, должны двигаться дальше.

Я бы не рекомендовал использовать CouchDb, если вы просто хотите использовать "правильный инструмент для правильной работы". потому что вы узнаете, что вы не можете просто использовать его таким образом, и вы в конечном итоге будете злиться и писать сообщения в блоге, такие как "где присоединяется к CouchDb ?"и "где управление транзакциями ?". Действительно, Couchdb-парадоксально-очень прозрачен, но в то же время требует смены парадигмы и изменения в том, как вы подходите к проблемам, чтобы действительно сиять (и действительно работать).

но как только вы это сделаете, это действительно окупится. Мне лично нужны очень веские причины или серьезное нарушение сделки. проекта для выбора другой базы данных, но до сих пор я не встретил ни одного.

задайте эти вопросы сами? И вы решите свой выбор DB.

1. вам нужно мастер-мастер? Затем В CouchDB. В основном CouchDB поддерживает репликацию master-master, которая ожидает, что узлы будут отключены в течение длительных периодов времени. MongoDB не будет хорошо работать в этой среде.
2. вам нужно максимальная пропускная способность R/W? Затем В MongoDB
3. вам нужен окончательный стойкость одно-сервера потому что ты только один сервер БД? Затем В CouchDB.
4. вы заносите массивные данные установить, что нужно sharding при сохранении безумной пропускной способности? Затем В MongoDB.
5. вам нужен сильный последовательность данных? Затем В MongoDB.
6. вам нужен высокий в наличии базы данных? Затем В CouchDB.
7. вы надеетесь multi базы данных и multi таблицы / коллекции? Затем В MongoDB
8. вы есть мобильное приложение автономных пользователей и хотите синхронизировать свои данные на сервер? Тогда вам нужен CouchDB.
9. вам нужно большое разнообразие запрос двигателя? Затем В MongoDB
10. вам нужен большой сообщество использовать DB? Затем В MongoDB

я суммирую ответы, найденные в этой статье:

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

MongoDB: лучший запрос, хранение данных в BSON (быстрый доступ), лучшая согласованность данных, несколько коллекций

CouchDB: Лучшая репликация, с master для управления репликацией и разрешением конфликтов, хранение данных в JSON (читаемый человеком, лучший доступ через REST услуги), запрос через map-reduce.

Итак, в заключение, MongoDB быстрее, CouchDB безопаснее.

также:http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

имейте в виду проблему с разреженными уникальными индексами в MongoDB. Я попал в него, и это очень громоздко обходной путь.

проблема в том , что у вас есть поле, которое уникально, если оно присутствует, и вы хотите найти все объекты, где поле отсутствует. Способ реализации разреженных уникальных индексов в Mongo заключается в том, что объекты, в которых отсутствует это поле, вообще не входят в индекс - они не могут быть получены запросом по этому полю - {$exists: false} просто не работает.

единственным обходным путем, который я придумал, является наличие специального семейства значений null, где пустое значение переводится в специальный префикс (например,null:) объединены с uuid. Это настоящая головная боль, потому что нужно позаботиться о преобразовании в/из пустых значений при написании/quering/чтении. Большая неприятность.

Я никогда не использовал выполнение javascript на стороне сервера в MongoDB (это не рекомендуется в любом случае), и их карта / сокращение ужасно производительность, когда есть только один узел Mongo. Из-за всех этих причин, которые я сейчас рассматриваю, чтобы проверить CouchDB, возможно, это больше подходит к моему конкретному сценарию.

кстати, если кто - нибудь знает ссылку на соответствующую проблему Монго, описывающую разреженную уникальную проблему индекса-пожалуйста, поделитесь.

Я уверен, что вы можете с Монго (более знакомы с ним), и уверен, что вы можете с дивана.

оба документа ориентированы (на основе JSON), поэтому в документах не будет "столбцов", а скорее полей, но они могут быть полностью динамическими.

Они оба делают это, вы можете посмотреть на другие факторы, на которые следует использовать:другие функции, о которых вы заботитесь, популярность и т. д. Google insights, indeed.com должности-это способ взглянуть на популярность.

вы могли просто попробуйте, я думаю, вы сможете запустить монго через 5 минут.