Я застрял между этими двумя базами данных NoSQL.
В моем проекте я буду создавать базу данных в базе данных. Например, мне нужно решение для создания динамических таблиц.
Таким образом, пользователи могут создавать таблицы со столбцами и строками. Я думаю, что либо MongoDB, либо CouchDB будут хороши для этого, но я не уверен, какой из них. Мне также понадобится эффективный пейджинг.
Из C, A & P (согласованность, доступность и допуск на разделы), какие 2 для вас важнее? Краткое руководство, визуальное руководство по системам NoSQL
Сообщение в блоге, Cassandra против MongoDB против CouchDB против Redis против Riak против HBase против Membase против Neo4j, сравнивает сценарии "наиболее часто используемые" для каждой сравниваемой базы данных NoSQL. Цитируя ссылку,
Недавнее (февраль 2012 г.) и более полное сравнение, выполненное Риядом Каллой,
Сообщение в блоге (октябрь 2011 г.), написанное кем-то, кто попробовал и то и другое, парень MongoDB, изучающий CouchDB, прокомментировал, что пейджинг CouchDB не так полезен.
Датированный (июнь 2009 г.) тест Kristina Chodorow (часть команды MongoDB),
Я бы пошел на 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 - парадоксально - очень прозрачен, но в то же время требует сдвига парадигмы и изменения в том, как вы приближаетесь к проблемам, чтобы действительно сиять (и действительно работать).
Но как только вы это сделали, это действительно окупается. Мне лично нужны очень сильные причины или серьезный нарушитель транзакций в проекте, чтобы выбрать другую базу данных, но до сих пор я ее не встречал.
Задайте этот вопрос самостоятельно? И вы решите выбор своей БД.
Я обобщаю ответы, найденные в этой статье:
MongoDB: лучший запрос, хранение данных в BSON (более быстрый доступ), улучшенная согласованность данных, несколько коллекций
CouchDB: улучшенная репликация, с мастером для репликации и разрешения конфликтов, хранение данных в JSON (доступный для человека, лучший доступ через службы REST), запрос через уменьшение карты.
Итак, в заключение, MongoDB работает быстрее, CouchDB безопаснее.
Также: http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb
Помните о проблеме с разреженными уникальными индексами в MongoDB. Я ударил его, и это очень громоздко для решения проблемы.
Проблема заключается в том, что у вас есть поле, которое является уникальным, если оно присутствует, и вы хотите найти все объекты, где это поле отсутствует. Способ использования редких уникальных индексов в Монго заключается в том, что объекты, в которых это поле отсутствует, отсутствуют в индексе вообще - они не могут быть получены запросом в этом поле - {$exists: false} просто не работает.
Единственным обходным решением, которое я придумал, является наличие специального нулевого семейства значений, где пустое значение переводится в специальный префикс (например, null:), объединенный с uuid. Это настоящая головная боль, потому что нужно позаботиться о преобразовании в/из пустых значений при записи/запросе/чтении. Основная неприятность.
Я никогда не использовал выполнение javascript на стороне сервера в MongoDB (в любом случае это не рекомендуется), а их карта/сокращение имеет ужасную производительность, когда есть только один Mongo node. Из-за всех этих причин, которые я сейчас рассматриваю, чтобы проверить CouchDB, возможно, он больше подходит для моего конкретного сценария.
Кстати, если кто-то знает ссылку на соответствующий монгонский вопрос, описывающий редкую уникальную проблему с индексом, пожалуйста, поделитесь.
Я уверен, что вы можете с Монго (более знакомы с ним), и вполне уверенно, что с кушеткой тоже можете.
Оба документа документально ориентированы (основаны на JSON), поэтому не было бы "столбцов", а скорее полей в документах, но они могут быть полностью динамическими.
Они оба делают это, вы можете захотеть взглянуть на другие факторы, на которых можно использовать: другие функции, о которых вы заботитесь, популярность и т.д. Прочтения Google, а также сообщения о вакансиях на самом деле .com - это способы поиска популярности.
Вы могли бы просто попробовать, я думаю, вы должны иметь возможность работать с манго через 5 минут.