CouchDB или Mongo для очень высоких скоростей обновления и объема? - PullRequest
6 голосов
/ 09 марта 2011

Какова была бы лучшая альтернатива no-sql для хранения пользовательских данных с очень высокой частотой обновления и объемом данных?

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

В настоящее время я смотрю на Монго или Дивана, но я открыт для других альтернатив.

РЕДАКТИРОВАТЬ (в ответ на запрос kprobst): Он будет размещен в Linux, и могут быть доступны несколько экземпляров (HW или VM).

Система будет использоваться для хранения состояния посетителей сайта, 1-2 недели для неаутентифицированных пользователей и (потенциально) на неопределенный срок для аутентифицированных пользователей.

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

Помимо этого состояния «дамп» будет храниться другая пользовательская информация и возможность запроса, которая будет полезна.

Ответы [ 4 ]

6 голосов
/ 09 марта 2011

Я недавно исследовал ряд технологий NoSQL, включая CouchDB и MongoDB.У меня сложилось ощущение, что MongoDB больше ориентирован на производительность, чем CouchDB, возможно, за счет определенных функций.Например, MongoDB использует драйверы, зависящие от языка, CouchDB использует REST.MongoDB - «Обновление на месте», тогда как CouchDB - MVCC .MongoDB хранит данные в отображенных в памяти файлах.

Я выбрал MongoDB, потому что он соответствовал типу данных, которые я хочу сохранить, и производительности, которую он предлагает.ИМХО, я не думаю, что решение MVCC лучше всего подходит для использования, которое вы описали.При обновлении документа вместо перезаписи существующего документа создается новая его версия, а затем помечается старая как устаревшая, что означает необходимость периодического удаления / сжатия этих документов.Чем больше обновлений, тем больше работы это будет связано с моей заботой.

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

Сравнение 2 на MongoDB.org . Немного больше1011 *

1 голос
/ 09 марта 2011

Другой вариант, который следует рассмотреть, это Berkeley DB , который часто используется для поддержки крупных веб-приложений и инфраструктуры (например, Amazon.com).Berkeley DB поддерживает как API ключ / значение (NoSQL), так и API SQL.Если вы создаете SOA-решение на основе Java, вы можете рассмотреть BDB Java Edition , который используется Heretix Way Back Machine .

Отказ от ответственности: я являюсь одним из менеджеров по продуктам в Berkeley DB, поэтому я немного предвзят.Тем не менее, BDB был написан для обеспечения быстрого, масштабируемого и надежного встроенного хранилища данных для именно тех операций, которые вы описываете.

1 голос
/ 09 марта 2011

Membase - это база данных NoSQL с сохраняемой дисковой кластерной памятью. Он был разработан несколькими лидерами memcached. В дополнение к собственному протоколу, он также имеет 100% -ный memcache-совместимый API. Membase уже используется в приложениях с очень большим объемом, таких как Farmville.

Membase и CouchOne объединены в Couchbase (где я работаю, FWIW, но я не работаю над Membase). Поэтому кажется разумным, что будущее Membase будет иметь функции CouchDB: запрос уменьшения карты, репликация / резервное копирование вне сайта, интерфейс HTTP REST и т. Д.

1 голос
/ 09 марта 2011

Вы не говорите, на какой платформе вы работаете или на какой платформе вы можете разместить свое решение nosql. Вы также не указываете, хотите ли вы иметь прямое распределенное хранилище значений ключей или базу данных NoSQL, которая будет MongoDB. Две вещи не одинаковы, хотя база данных NoSQL может использоваться как хранилище kv, я полагаю.

Тем не менее, если вам нужно простое хранилище значений ключей, которое хорошо работает в Linux, я бы выбрал Redis . Из всех решений NoSQL я использовал только MongoDB, но он хорошо работает на Server 2008 (64-разрядная версия) и отлично работает на Linux (CentOS).

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

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