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

Я застрял между этими двумя базами данных NoSQL.

В моем проекте я буду создавать базу данных в базе данных. Например, мне нужно решение для создания динамических таблиц.

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

Из C, A & P (согласованность, доступность и допуск на разделы), какие 2 для вас важнее? Краткое руководство, визуальное руководство по системам NoSQL

• MongodB: последовательность и допуск раздела
• CouchDB: доступность и допуск раздела

Сообщение в блоге, Cassandra против MongoDB против CouchDB против Redis против Riak против HBase против Membase против Neo4j, сравнивает сценарии « наиболее часто используемые » для каждой сравниваемой базы данных NoSQL. Цитируя ссылку,

• MongoDB: если вам нужны динамические запросы. Если вы предпочитаете определять индексы, а не отображать / сокращать функции. Если вам нужна хорошая производительность на большой БД. Если вы хотели CouchDB, но ваши данные слишком сильно меняются, заполняя диски.
• CouchDB: для накопления, иногда изменяющихся данных, для которых должны выполняться предварительно определенные запросы. Места, где важно управление версиями.

Недавнее (февраль 2012 г.) и более полное сравнение, выполненное Риядом Каллой,

• MongoDB: ТОЛЬКО репликация ведущий-ведомый
• CouchDB: Мастер-Мастер Репликация

Сообщение в блоге (октябрь 2011 г.) того, кто попробовал и то и другое, парень MongoDB, изучающий CouchDB, прокомментировал, что пейджинг CouchDB не так полезен.

А от (июнь 2009) ориентир по Кристина Чодороу ( часть команды за MongoDB ),

Я бы пошел на MongoDB.

Надеюсь, поможет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Вам нужен мастер-мастер ? Тогда CouchDB. В основном CouchDB поддерживает репликацию мастер-мастер, которая предполагает отключение узлов в течение длительных периодов времени. MongoDB не преуспеет в этой среде.
2. Вам нужна МАКСИМАЛЬНАЯ пропускная способность R / W ? Тогда MongoDB
3. Вам нужна максимальная долговечность одного сервера, потому что у вас будет только один сервер БД? Тогда CouchDB.
4. Вы храните МАССИВНЫЙ набор данных, который требует разбиения при сохранении безумной пропускной способности? Затем MongoDB.
5. Вам нужна строгая согласованность данных? Затем MongoDB.
6. Вам нужна высокая доступность базы данных? Тогда CouchDB.
7. Вы надеетесь на несколько баз данных и несколько таблиц / коллекций? Тогда MongoDB
8. У вас есть мобильное приложение офлайн-пользователей, и вы хотите синхронизировать данные их активности на сервере? Тогда вам нужен CouchDB.
9. Вам нужен большой выбор движка запросов ? Тогда MongoDB
10. Вам нужно большое сообщество, чтобы использовать БД? Тогда MongoDB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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