Какая-либо причина, почему я не должен использовать couchdb для передачи сообщений или лент активности в реальном времени?
В то время как использование ampq или xmpp (rabbitmq или ejabbered, который мог иметь couchdb как бэкенды) походит на хорошую подгонку для обеспечения оперативных обновлений о друге состояние в социальной играющей платформе, где обновления являются маленькими, но частыми, я не могу не думать, почему не был бы couchdb быть хорошей платформой для обеспечения таких обновлений?
Основным преимуществом, о котором я мог думать, является своя способность отфильтровать обновления на основе друзей и доступности API изменений, который делает разработку такого приложения и управление им (включая репликацию) довольно легкими по сравнению с ampq или xmpp, где необходимо думать о том, как управлять pubsub узлами и кто подписан на них в любом моменте времени.
Однако я не могу не думать, что это слишком хорошо, чтобы быть правдой, я не могу найти информацию о том, каковы недостатки couchdb. Так или иначе как использовать MySQL для передачи сообщений, которая является, почему я колеблюсь к использованию его.
У кого-либо есть опыт в использовании couchdb для таких приложений? Вы рекомендовали бы другой платформе использовать?
1 ответ
Вот некоторые проблемы, с которыми вы столкнетесь при использовании "небольших, но частых" обновлений и CouchDB.
CouchDB имеет отличную систему MVCC для обновлений документов. Каждое обновление изменяет ревизию, и вы не можете обновить документ без передачи ревизии, которую вы хотите обновить. Это также означает, что если у вас есть несколько клиентов, обновляющих один и тот же документ невероятно часто, эта функция будет мешать, поскольку даже при передаче изменений существует небольшая сетевая задержка после обновления.
Еще одна проблема, с которой вы можете столкнуться при использовании фильтрованных изменений, заключается в том, что функция фильтрации получает объект запроса, что означает отдельный вызов сервера представления для каждого документа, умноженный на количество соединений. Вместо этого вы можете использовать сервер node.js или erlang для реализации "канального" подхода к фильтрации изменений и заставить его сидеть на одном нефильтрованном канале изменений.
Подводя итог, можно сказать, что то, что вы хотите сделать, будет работать хорошо, если у вас нет множества клиентов, пытающихся обновить одни и те же документы с высокой частотой, и если вы не используете фильтр изменений на очень большом количестве одновременных клиентов с высокой частотой обновления базы данных. В остальном все будет работать отлично. @jchris сделал тонну приложений в реальном времени, используя только голый поток изменений, и они отлично работают.