Любая причина, почему я не должен использовать couchdb для передачи сообщений или потоков активности в реальном времени? - PullRequest
7 голосов
/ 26 мая 2010

Хотя использование ampq или xmpp (rabbitmq или ejabbered, для которых в качестве бэкэндов может быть couchdb) кажется вполне подходящим для доставки в реальном времени обновлений о состоянии друзей в социальной игровой платформе, где обновления небольшие, но частые, я не могу помочь, но Подумайте, почему couchdb не будет хорошей платформой для доставки таких обновлений?

Основным преимуществом, которое я могу себе представить, является его способность фильтровать обновления на основе друзей и доступности api изменений, что делает разработку такого приложения и управление им (включая репликацию) довольно простым по сравнению с ampq или xmpp, где вы должны подумать о том, как управлять узлами pubsub и кто подписан на них в любой момент времени.

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

У кого-нибудь есть опыт использования couchdb для таких приложений? Вы бы порекомендовали использовать другую платформу?

Ответы [ 3 ]

6 голосов
/ 27 мая 2010

Вот некоторые проблемы, с которыми вы столкнетесь с «небольшими, но частыми» обновлениями и CouchDB.

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

Другая проблема, с которой вы можете столкнуться при использовании отфильтрованных изменений, заключается в том, что функция фильтра получает объект запроса, что означает, что это отдельный вызов сервера представления для каждого документа, умноженного на количество соединений. Вместо этого вы можете захотеть использовать сервер node.js или erlang для реализации подхода «каналов» для изменения фильтрации и размещения его в едином фиде нефильтрованных изменений.

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

2 голосов
/ 18 августа 2011

Тем не менее, я не могу не думать, что это слишком хорошо, чтобы быть правдой, я не могу найти информацию о недостатках couchdb. Почему-то как использование MySQL для передачи сообщений, поэтому я не решаюсь используя его.

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

1 голос
/ 18 августа 2011

Я могу вспомнить одну очень простую причину ... потому что базы данных не были предназначены для этого!

Очередь сообщений - это именно то, что нужно для такого рода рабочих процессов. Вы смотрели на некоторые продукты или услуги на основе AMQP? К ним относятся RabbitMQ (установлен локально) и StormMQ (облачный сервис). Больше здесь: http://www.amqp.org

...