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

638

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

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

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

Luke101
источник
19
Хотелось бы, чтобы они модифицировали систему, чтобы облегчить создание интересующего их вопроса и лучше направить пользователей на этот вопрос. Я понятия не имею, был ли когда-либо затронут этот вопрос, и нет удобного способа отследить его.
Doub1ejack
45
Я хотел бы, чтобы они добавили функциональность на этом веб-сайте, где мы могли бы «повысить или понизить» саму причину, указанную для этого вопроса как «не по теме», что могло бы помочь переключить вопросы такого типа обратно на «по теме».
Санджай
9
++ Мне не понятно, почему это не по теме. Вопрос действительно имеет четкие объективные ответы - ОР не прошу мнение , но для объективной информации об этих двух системах. user799188 предоставил отличный объективный ответ.
user48956
3
Я думаю, что администраторы просто смотрят на вопрос, содержит ли он какой-либо фрагмент кода, а не на вид запрашиваемой информации. Кстати, вы всегда можете проголосовать, чтобы вновь открыть вопрос.
Тарун
11
Вопрос только что вновь открылся. С возвращением, все ...
Алексис Дюфреной,

Ответы:

523

Из 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.

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

user799188
источник
8
Насколько я понимаю, MongoDB никак не согласуется: ivoras.sharanet.org/blog/tree/…
sheerun
2
Хорошая информация для времени, но это действительно старая ... многое изменилось (включая интерфейсы REST для Mongo).
Рич
4
Я думаю, что это может вводить в заблуждение, но управление версиями в couchdb не является аргументом. Схема управления версиями, используемая couchdb, не должна использоваться в качестве контроля версий. Он используется для обработки разделов. Во время сжатия базы данных ревизии будут удалены, как и в самом деле удалены. И только базы оборотов должны оставаться в базе данных. Если вы хотите работать с версиями в couchdb, это должно быть сделано так же, как в mongodb.
Лоик Фор-Лакруа
2
Я бы добавил в список, что couchdb может иметь автономные веб-приложения. Как и в couchdb на самом деле веб-сервер.
Лоик Фор-Лакруа
41
Я удивлен 332 голосами за неправильный ответ. MongoDB - это CP по умолчанию, а CouchDB - это AP stackoverflow.com/questions/11292215/…
adnan kamili
219

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

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

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

Ewan Makepeace
источник
18
Сжато, им так нравится.
Ely
Мне нравятся простые не слишком технические ответы, подобные этому. Спасибо!
этот ответ особенно важен для тех, кто ищет мобильный, оффлайн и синхронизацию! спасибо
Эрик Каплун
Я смеялся, когда я читал "реплицировать на мобильное устройство", lol, как мало ваших данных?
Даниэль В.
3
"LOL, как мало ваших данных?" - это действительно вещь? Я мог бы выбрать CDB, потому что мои данные большие - или я мог бы выбрать его, потому что у него лучше репликация, чем у альтернатив. В этом случае мы фильтруем наборы данных примерно до 100–200 МБ на устройство. Это плохо?
Эван Мейкпис
62

Очень старый вопрос, но он находится на вершине 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 очень прозрачен, но в то же время требует смены парадигмы и изменения в подходах к проблемам, чтобы они действительно сияли (и действительно работали).

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

tobiak777
источник
12
Обновление 2016: начиная с версии 2.0, выпущенной в сентябре 2016 года, CouchDb поддерживает специальные запросы "из коробки" :)
tobiak777
1
CouchDb relies on b-tree indexes. This means that whether you have 1 "row" or 20 billions, the querying time will always remain below 10ms.Разве это не верно почти для всех баз данных? Таким образом, это означает, что иначе.
Шелваку
38

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

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

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

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

Алексис Дафреной
источник
7
Полезный ответ, но заключение трудно любить.
Эрик Каплун
Что вы подразумеваете под "трудно любить"?
Алексис Дафреной,
23

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

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

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

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

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

отметка
источник
3
Извините, но у меня есть это ноющее чувство, что это не очень хорошая идея, и это чувство, которое я научился не игнорировать
eaglestorm
8
Ну, я не могу спорить с чувством. Все, что я знаю, это то, что мне нужны редкие уникальные индексы из-за необязательных полей, которые являются уникальными, если они присутствуют.
отметка
37
Я понимаю, что у вас есть реальный пример использования, который описывает проблему, но как насчет моей интуиции?
Chev
14
Я не знаю. Что насчет этого?
Марк
2
ROTFL. +1 Алекс Форд и оценка за ваши смешные комментарии. :-)) @mark, я не уверен, что перечисленные вами проблемы действительно оправдывают переход с MongoDB на CouchDB. Я не работал ни с MongoDB, ни с CouchDB, но моя интуиция говорит мне, что вы столкнетесь с некоторыми другими сложными ограничениями с CouchDB и потратите еще немного времени на их обход. Если вы уже освоили MongoDB, то вам, вероятно, стоит придерживаться этого. Но опять же, я никогда не был в Носкли, это просто моя интуиция.
MiniQuark
6

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

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

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

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

дм.
источник