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

Ответы выше всего осложняют историю.

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

Что это. Если вам не нужна CouchDB (удивительная) возможность репликации на мобильные и настольные устройства, MongoDB имеет преимущество производительности, сообщества и инструментов в настоящее время.

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

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

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

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

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

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

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

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

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

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

Я обобщаю ответы, найденные в этой статье:

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

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

CouchDB: улучшенная репликация, с мастером для репликации и разрешения конфликтов, хранение данных в JSON (доступный для человека, лучший доступ через службы REST), запрос через уменьшение карты.

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

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

Задайте этот вопрос самостоятельно? И вы решите выбор своей БД.

• Вам нужен мастер-мастер? Затем CouchDB. В основном CouchDB поддерживает репликацию master-master, которая ожидает, что узлы будут отключены в течение длительных периодов времени. MongoDB не преуспел в этой среде.
• Вам нужна MAXIMUM R/W пропускная способность? Затем MongoDB
• Вам нужна максимальная прочность на один сервер, потому что у вас будет только один сервер БД? Затем CouchDB.
• Вы сохраняете набор МАССИВНЫХ данных, который требует осколки при сохранении безумной пропускной способности? Затем MongoDB.
• Вам нужна сильная последовательность данных? Затем MongoDB.
• Вам нужна высокая доступность базы данных? Затем CouchDB.
• Ожидаете ли вы несколько баз данных и несколько таблиц/коллекций? Затем MongoDB
• У вас есть автономные пользователи мобильных приложений и хотите синхронизировать данные своей активности с сервером? Тогда вам понадобится CouchDB.
• Вам нужно большое количество запросов? Затем MongoDB
• Вам нужно большое сообщество для использования БД? Затем MongoDB

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

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

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

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

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

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

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

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

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