MongoDb против CouchDb: скорость записи для географически удаленных клиентов - PullRequest
10 голосов
/ 22 ноября 2010

Я бы хотел, чтобы все мои пользователи могли быстро читать и писать в хранилище данных. Кажется, что MongoDb имеет блестящие чтения, но записи, кажется, могут быть очень очень медленными, если одна главная база данных должна быть расположена очень далеко от клиента. Couchdb кажется, что у него медленное чтение, но как насчет записи в случае, когда клиент очень далеко от мастера. С помощью couchdb у нас может быть несколько мастеров, что означает, что у нас всегда может быть узел записи, близкий к клиенту. Может ли couchdb на самом деле быть быстрее для записей, чем mongodb, в том случае, если наша база пользователей очень географически распределена?

Я бы хотел использовать mongoDb из-за его невероятно быстрой скорости, но некоторые из моих пользователей, очень далеко от мастера only , получат ужасные впечатления. Для систем по всему миру лучше не было бы использовать couchDb. Разве mongodb не исключен полностью, если у вас есть пользователи по всему миру? MongoDb, если вы слушаете, почему бы вам не сделать несколько простых установок с несколькими мастерами, где разрешение конфликтов может быть частью семантики обновления? Кажется, это единственное, что стоит между mongoDb, полностью доминирующим на рынке nosql. Все остальное очень впечатляет.

Ответы [ 4 ]

9 голосов
/ 13 августа 2011

Раскрытие информации: я фанат и пользователь MongoDB, у меня нулевой опыт работы с CouchDB.

У меня тяжелое приложение, которое очень интенсивно читает и пишет. Я бы сказал, что число операций чтения превышает количество записей в 30: 1. Способ, которым монго предназначен для чтения, всегда будет намного быстрее, чем трюк (по моему опыту) состоит в том, чтобы сделать ваши записи настолько эффективными, что вы можете выделить более высокий процент системных ресурсов для записи.

При создании продукта поверх монго ключевым моментом является поле _id. Это поле автоматически генерируется и добавляется ко всем вашим объектам JSON, оно будет выглядеть примерно так: 47cc67093475061e3d95369d, когда вы создаете свои запросы (Find), пытаетесь и запрашиваете это поле везде, где это возможно, так как оно содержит местоположение компьютера (и я думаю, также местоположение диска ?? ? - я должен проверить это), где находится объект, поэтому, когда вы используете находку или обновление, используя это поле, действительно ускорит работу вашего компьютера. Учтите это при проектировании вашей системы.

Пример:

2 кластера в моей базе данных - это «пользователи» и «посты». Пользователь может создавать несколько сообщений. Эти две коллекции должны часто ссылаться друг на друга в реализации моего приложения.

В каждом объекте записи я сохраняю _id родительского пользователя. В каждом объекте пользователя я храню массив всех сообщений, созданных пользователем.

Теперь на каждой странице пользователя я могу сгенерировать список всех созданных постов без ресурсоемкого запроса, но с прямым просмотром _id. Чем больше кластер монго, тем больше будет разница.

Если вы вообще знакомы с физическими локациями оракула, вы можете понять эту концепцию только в монго, она гораздо более удивительная и мощная.

Я был напуган в прошлом году, когда мы решили окончательно отказаться от MySQL для mongo, но я могу рассказать вам следующее о своем опыте: - Портирование данных всегда ужасно, но все прошло так, как я мог себе представить. Mongo - это, вероятно, лучшая документированная база данных NoSQL, и сообщество Open Source просто фантастическое. - Когда говорят, быстро и масштабируемо, там не шутишь, летит. - На мой взгляд, дизайн схемы очень прост и намного более естественен и упорядочен, чем db типа ключ / значение. - Кажется, вся система разработана для минимальной сложности пользователя, добавление узлов и т. Д. - просто.

Хорошо, серьезно, я клянусь, Монго не заплатил мне, чтобы написать это (я желаю), но извиняюсь за праздник любви.

Независимо от вашего выбора, удачи.

5 голосов
/ 12 августа 2011

Вот подробная статья, созданная 10gen, и приводятся примеры того, когда вам следует выбрать MongoDB или CouchDB, а также причины.

http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB

Редактировать

Ссылка выше была удалена, но её можно посмотреть здесь: http://web.archive.org/web/20120614072025/http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB

4 голосов
/ 22 ноября 2010

Ваш вопрос на данный момент полон предположений и догадок.

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

Что если эти записи влияют на другие записи?Что, если эти записи помешают другим людям делать что-то?Сложно сказать о возможном побочном эффекте, если вы не сообщили нам никаких подробностей.

Мое основное предложение для вас заключается в том, чтобы вы провели некоторое тестирование.Если вы не проверили это, рассуждения о горлышках бутылок - это пустая трата времени.Вам не нужно тестировать его на удаленных компьютерах, настроить несколько локальных баз данных и добавить искусственное отставание, а затем запустить свои тесты.

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

Никто здесь не сможет дать вам общее решение для вашего специфическая проблема (хорошо, если вы не дадите нам весь свой код и не заплатите нам за работу над ним: P). Базы данных нелегки, особенно если вам необходимо масштабировать их под определенные требования.

3 голосов
/ 23 ноября 2010

Для систем по всему миру лучше не было бы couchDb. Разве mongodb не исключен полностью, если у вас есть пользователи по всему миру?

MongoDB поддерживает шардинг. Так что вам не нужен ни один мастер. На самом деле, похоже, у вас есть готовый ключ шарда (регион).

MongoDB также поддерживает наборы реплик наряду с шардингом. Поэтому, если вам нужно работать в нескольких центрах обработки данных (DC), вы помещаете мастер и одну из реплик в один и тот же DC. Фактически, они также предлагают добавить третий узел к отдельному DC в качестве аварийного переключения в режиме горячего резервного копирования.

Вам нужно будет детализировать более подробную конфигурацию MongoDB, но вы определенно можете контролировать, где хранятся данные, и вы можете расставить приоритеты, чтобы другие реплики в DC были «следующими в очереди» для продвижения к Master.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...