Если вы выходец из мира MySQL, MongoDB будет «чувствовать» вас гораздо естественнее благодаря своей языковой поддержке, подобной запросам.
Я думаю, именно это делает его таким дружелюбным для многих людей.
CouchDB - это фантастика, если вы хотите использовать действительно великолепную поддержку репликации мастер-мастер с многоузловой установкой, возможно, в разных центрах обработки данных или чем-то в этом роде.
Репликация MongoDB (наборы реплик) является установкой master-slave-slave-slave- *, вы можете записывать данные на master только в наборе реплик и читать из любого из них.
Для стандартной конфигурации сайта это нормально. Это очень хорошо соответствует использованию MySQL.
Но если вы пытаетесь создать глобальный сервис, такой как CDN, который должен поддерживать синхронизацию всех глобальных узлов, даже если чтение / запись для них всех, что-то вроде репликации в CouchDB станет для вас огромным благом.
В то время как MongoDB имеет язык запросов, который вы можете использовать, и он очень интуитивно понятен, CouchDB использует подход «map-Reduce» и эту концепцию представлений. Поначалу это кажется странным, но по мере того, как вы это понимаете, оно действительно начинает казаться интуитивным.
Вот краткий обзор, поэтому он имеет некоторый смысл:
- CouchDB хранит все ваши данные в B-дереве
- Вы не можете "запросить" его динамически с помощью чего-то вроде "SELECT * FROM user WHERE ..."
- Вместо этого вы определяете дискретные «представления» ваших данных ... «здесь - представление всех моих пользователей», «здесь - представление всех пользователей старше 10 лет», «здесь - представление всех пользователей старше 30 лет» и скоро.
- Эти представления определяются с использованием подхода сокращения карт и определяются как функции JavaScript.
- Когда вы определяете представление, БД начинает подачу через него всех документов БД, которым вы назначили представление, и записывает результаты ваших функций в качестве «индекса» этих данных.
- Есть несколько базовых запросов, которые вы можете сделать в представлениях, например, запросить конкретный ключ (ID) или диапазон идентификаторов независимо от того, что делает ваша функция map / lower.
- Прочитайте эти слайды , это лучшее разъяснение карты / уменьшения в Couch, которое я видел.
Таким образом, оба этих источника используют документы JSON, но CouchDB придерживается этого принципа «каждый сервер является мастером и может синхронизироваться с миром», и это фантастический подход, если вам это нужно, в то время как MongoDB действительно является MySQL в мире NoSQL.
Так что, если это звучит больше как то, что вам нужно / хотите, сделайте это.
Небольшие отличия, такие как двоичный протокол Mongo от интерфейса RESTful CouchDB, - все это мелкие детали.
Если вам нужна грубая скорость и, черт возьми, безопасность данных, вы можете заставить Mongo работать быстрее, чем CouchDB, так как вы можете указать, что он работает не по памяти и не записывает данные на диск, за исключением редких интервалов.
Вы можете сделать то же самое с Couch, но его протокол обмена данными на основе HTTP будет в 2-4 раза медленнее, чем необработанный двоичный обмен данными с Mongo в этой «скорости над всем!» сценарий.
Имейте в виду, что сумасшедшая безумная скорость бесполезна, если сбой сервера или сбой диска повредят и превратят вашу БД в забвение, так что точка данных не так удивительна, как может показаться (если только вы не используете торговые системы реального времени на Wall Улица, в таком случае посмотрите на Редис).
Надеюсь, что все помогает!