Я полный нуб, когда дело доходит до движения NoSQL. Я много слышал о MongoDB и CouchDB. Я знаю, что между ними есть различия. Что вы рекомендуете изучать в качестве первого шага в мир NoSQL?
В качестве первого шага лучше использовать mongoDB, потому что его легче освоить, но у него есть некоторые проблемы. Существует не лучший выбор для использования конкретной базы данных noSQL, это зависит от того, что вы должны сделать. Проверьте документно-ориентированный, ключ-значение, граф-ориентированный, ориентированный на столбцы.
Обновление : я нашел отличное сравнение баз данных NoSQL .
MongoDB (3.2)
Написано на: C ++
Основной момент: хранилище документов JSON
Лицензия: AGPL (Драйверы: Apache)
Протокол: Пользовательский, двоичный (BSON)
Репликация master / slave (автоматическое переключение при сбое с наборами реплик)
Sharding встроенный
Запросы являются выражениями JavaScript
Выполнить произвольные функции JavaScript на стороне сервера
Имеет геопространственную индексацию и запросы
Несколько систем хранения с различными эксплуатационными характеристиками
Производительность над функциями
Проверка документов
Журналирование
Мощная структура агрегации
На 32-битных системах ограничено ~ 2.5 Гб
Интегрированный текстовый поиск
GridFS для хранения больших данных + метаданных (на самом деле не FS)
Центр обработки данных осведомлен
Лучше всего использовать : если вам нужны динамические запросы. Если вы предпочитаете определять индексы, а не отображать / сокращать функции. Если вам нужна хорошая производительность на большой БД. Если вы хотели CouchDB, но ваши данные слишком сильно меняются, заполняя диски.
Например : для большинства вещей, которые вы делаете с MySQL или PostgreSQL, но наличие предопределенных столбцов действительно сдерживает вас.
CouchDB (1.2)
Написано в: Erlang
Главное: согласованность БД, простота использования
Лицензия: Apache
Протокол: HTTP / REST
Двунаправленная (!) Репликация,
непрерывный или специальный,
с обнаружением конфликта,
Таким образом, мастер-мастер репликации. (!)
MVCC - операции записи не блокируют чтения
Предыдущие версии документов доступны
Аварийный (надежный) дизайн
Время от времени требует уплотнения
Просмотры: встроенная карта / уменьшить
Форматирование просмотров: списки и шоу
Возможна проверка документов на стороне сервера
Аутентификация возможна
Обновления в режиме реального времени через _changes (!)
Обработка вложений
Лучше всего использовать : для накопления, периодически изменяющихся данных, для которых должны выполняться предварительно определенные запросы. Места, где важно управление версиями.
Например : CRM, CMS системы. Репликация мастер-мастер - это особенно интересная функция, которая позволяет легко развертывать несколько сайтов.
Если вы выходец из мира 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 Улица, в таком случае посмотрите на Редис).
Сейчас на рынке гораздо больше баз данных NoSQL, чем когда-либо прежде. Я предлагаю даже взглянуть на магический квадрант Gartner, если вы ищете базу данных, которая также подойдет для корпоративных приложений, основанных на поддержке, расширяемости, управлении и стоимости.
Я хотел бы предложить Couchbase всем, кто еще не пробовал его, но не на основе версии, показанной в отчете (2.5.1), потому что он почти на 2 ревизии отстает от того, где находится CB Server сегодня, приближается к выпуску 4.0 во 2П15 ,
Другая часть, касающаяся Couchbase как поставщика / продукта, заключается в том, что это многофункциональный тип БД. Он может выступать в роли чистого K / V-хранилища, Document Oriented Database с многомерным масштабированием, Memcached, кэширования с сохранением, а также поддерживает ANSI 92-совместимый SQL с автоматическими объединениями, репликацией в кластеры DR одним нажатием кнопки и даже имеет мобильный компонент, встроенный в экосистему.
Если ничего другого, стоит проверить последние тесты:
Ответы:
Смотрите следующие ссылки
Обновление : я нашел отличное сравнение баз данных NoSQL .
MongoDB (3.2)
Лучше всего использовать : если вам нужны динамические запросы. Если вы предпочитаете определять индексы, а не отображать / сокращать функции. Если вам нужна хорошая производительность на большой БД. Если вы хотели CouchDB, но ваши данные слишком сильно меняются, заполняя диски.
Например : для большинства вещей, которые вы делаете с MySQL или PostgreSQL, но наличие предопределенных столбцов действительно сдерживает вас.
CouchDB (1.2)
Лучше всего использовать : для накопления, периодически изменяющихся данных, для которых должны выполняться предварительно определенные запросы. Места, где важно управление версиями.
Например : CRM, CMS системы. Репликация мастер-мастер - это особенно интересная функция, которая позволяет легко развертывать несколько сайтов.
источник
Если вы выходец из мира MySQL, MongoDB будет «чувствовать» вас гораздо естественнее благодаря своей языковой поддержке, подобной запросам.
Я думаю, именно это делает его таким дружелюбным для многих людей.
CouchDB - это фантастика, если вы хотите использовать действительно великолепную поддержку репликации мастер-мастер с многоузловой установкой, возможно, в разных центрах обработки данных или чем-то в этом роде.
Репликация MongoDB (наборы реплик) является установкой master-slave-slave-slave- *, вы можете записывать данные на master только в наборе реплик и читать из любого из них.
Для стандартной конфигурации сайта это нормально. Это очень хорошо соответствует использованию MySQL.
Но если вы пытаетесь создать глобальный сервис, такой как CDN, который должен поддерживать синхронизацию всех глобальных узлов, даже если чтение / запись для них всех, что-то вроде репликации в CouchDB станет для вас огромным благом.
В то время как MongoDB имеет язык запросов, который вы можете использовать, и он очень интуитивно понятен, CouchDB использует подход «map-Reduce» и эту концепцию представлений. Поначалу это кажется странным, но по мере того, как вы это понимаете, оно действительно начинает казаться интуитивным.
Вот краткий обзор, поэтому он имеет некоторый смысл:
Таким образом, оба этих источника используют документы JSON, но CouchDB придерживается этого принципа «каждый сервер является мастером и может синхронизироваться с миром», и это фантастический подход, если вам это нужно, в то время как MongoDB действительно является MySQL в мире NoSQL.
Так что, если это звучит больше как то, что вам нужно / хотите, сделайте это.
Небольшие отличия, такие как двоичный протокол Mongo от интерфейса RESTful CouchDB, - все это мелкие детали.
Если вам нужна грубая скорость и, черт возьми, безопасность данных, вы можете заставить Mongo работать быстрее, чем CouchDB, так как вы можете указать, что он работает не по памяти и не записывает данные на диск, за исключением редких интервалов.
Вы можете сделать то же самое с Couch, но его протокол обмена данными на основе HTTP будет в 2-4 раза медленнее, чем необработанный двоичный обмен данными с Mongo в этой «скорости над всем!» сценарий.
Имейте в виду, что сумасшедшая безумная скорость бесполезна, если сбой сервера или сбой диска повредят и превратят вашу БД в забвение, так что точка данных не так удивительна, как может показаться (если только вы не используете торговые системы реального времени на Wall Улица, в таком случае посмотрите на Редис).
Надеюсь, что все помогает!
источник
Посмотрите на эти ссылки:
MongoDB против CouchDB (со стороны MongoDB)
CouchDB против MongoDB: попытка более информированного сравнения
Сравнение CouchDB и MongoDB (сравнение производительности)
источник
Сейчас на рынке гораздо больше баз данных NoSQL, чем когда-либо прежде. Я предлагаю даже взглянуть на магический квадрант Gartner, если вы ищете базу данных, которая также подойдет для корпоративных приложений, основанных на поддержке, расширяемости, управлении и стоимости.
http://www.gartner.com/technology/reprints.do?id=1-23A415Q&ct=141020&st=sb
Я хотел бы предложить Couchbase всем, кто еще не пробовал его, но не на основе версии, показанной в отчете (2.5.1), потому что он почти на 2 ревизии отстает от того, где находится CB Server сегодня, приближается к выпуску 4.0 во 2П15 ,
http://www.couchbase.com/coming-in-couchbase-server-4-0
Другая часть, касающаяся Couchbase как поставщика / продукта, заключается в том, что это многофункциональный тип БД. Он может выступать в роли чистого K / V-хранилища, Document Oriented Database с многомерным масштабированием, Memcached, кэширования с сохранением, а также поддерживает ANSI 92-совместимый SQL с автоматическими объединениями, репликацией в кластеры DR одним нажатием кнопки и даже имеет мобильный компонент, встроенный в экосистему.
Если ничего другого, стоит проверить последние тесты:
http://info.couchbase.com/Benchmark_MongoDB_VS_CouchbaseServer_HPW_BM.html http://info.couchbase.com/NoSQL-Technical-Comparison-Report.html
источник