Якщо ви приїжджаєте зі світу MySQL, MongoDB "почуватиметься" набагато природніше для вас через мовну підтримку, подібну до запитів.
Я думаю, що саме це робить його таким дружнім для багатьох людей.
CouchDB є фантастичним, якщо ви хочете використовувати дійсно чудову підтримку реплікації master-master за допомогою множинного вузла, можливо, в різних центрах обробки даних чи щось подібне.
Реплікація MongoDB (набори реплік) - це параметр master-slave-slave-slave- *, ви можете писати майстру лише в наборі реплік і читати з будь-якого з них.
Для стандартної конфігурації сайту це добре. Це дуже добре відображає використання MySQL.
Але якщо ви намагаєтесь створити глобальну службу на зразок CDN, яка повинна підтримувати всі глобальні вузли синхронізованими, навіть незважаючи на те, що їх читають / записують, щось на зразок реплікації в CouchDB стане для вас величезною користю.
Незважаючи на те, що у MongoDB є мова, що нагадує запит, яку ви можете використовувати, і ви відчуваєте себе дуже інтуїтивно, CouchDB використовує підхід "зменшити карту" та це поняття поглядів. Спочатку це здається дивним, але, коли ви причасуєтесь до цього, він справді починає відчувати інтуїтивність.
Ось короткий огляд, і це має певний сенс:
- CouchDB зберігає всі ваші дані у b-дереві
- Ви не можете "запитувати" його динамічно за допомогою кшталт "SELECT * OF user WHERE ..."
- Натомість ви визначаєте дискретні "перегляди" своїх даних ... "тут представлення всіх моїх користувачів", "тут представлення всіх користувачів старше 10" "тут представлення всіх користувачів старше 30" та так далі.
- Ці представлення визначаються за допомогою підходу зменшення карт і визначаються як функції JavaScript.
- Коли Ви визначаєте подання, БД починає подавати всі документи БД, яким Ви призначили представлення, через нього та записуючи результати Ваших функцій як "індекс" на цих даних.
- Існує кілька основних запитів, які ви можете виконати в представленнях даних, як-от запит на певний ключ (ідентифікатор) або діапазон ідентифікаторів, незалежно від того, що робить ваша карта / функція зменшення.
- Прочитайте ці слайди , це найкраще уточнення карти / зменшення на Дивані, яке я бачив.
Отже, обидва ці джерела використовують документи JSON, але CouchDB дотримується цього більше "кожен сервер є майстром і може синхронізуватися зі світом", підхід, який є фантастичним, якщо вам це потрібно, в той час як MongoDB - це справді MySQL світу NoSQL.
Отже, якщо це звучить більше як те, що вам потрібно / хочете, продовжуйте це.
Невеликі розбіжності, як двійковий протокол Монго проти RESTful інтерфейс CouchDB, - це незначні деталі.
Якщо ви хочете отримати швидку швидкість і, до пекла, безпеку даних, ви можете змусити Mongo працювати швидше, ніж CouchDB, оскільки ви можете сказати, що він працює з пам'яті і не вводить речі на диск, за винятком обмежених інтервалів.
Ви можете зробити те ж саме з Couch, але це протокол зв'язку на основі HTTP буде в 2-4 рази повільніше, ніж необроблений бінарний зв’язок з Mongo у цій "швидкості за все!" сценарій.
Майте на увазі, що неочищена божевільна швидкість є марною, якщо збій сервера або збій диска псується і відганяє ваш БД у забуття, так що точка даних не така дивна, як може здатися (якщо ви не займаєтеся реальними торговими системами на стіні Вулиця, в такому випадку подивіться на Redis).
Сподіваюся, що все допомагає!