为什么我不应该使用 couchdb 进行消息传递或实时活动流？
虽然使用 ampq 或 xmpp（rabbitmq 或 ejabbered，可以将 couchdb 作为后端）似乎很适合在社交游戏平台中提供有关朋友状态的实时更新，其中更新虽小但频繁，但我不禁想为什么不这样做couchdb 不是提供此类更新的好平台吗？
我能想到的主要优点是它能够根据朋友和更改 API 的可用性来过滤更新，与 ampq 或 xmpp 相比，这使得开发这样的应用程序并管理它（包括复制）变得非常容易，在 ampq 或 xmpp 中你必须考虑如何管理 pubsub 节点以及谁在任何时间点订阅它们。
然而，我不禁认为这太好了，令人难以置信，我找不到有关 couchdb 缺点的信息。不知何故，感觉就像使用 MySQL 进行消息传递，这就是我犹豫是否使用它的原因。
有人有使用 couchdb 进行此类应用程序的经验吗？您会推荐另一个使用的平台吗？
While using ampq or xmpp (rabbitmq or ejabbered that could have couchdb as backends) seems like a good fit to deliver real time updates about friend state in a social gaming platform where updates are small but frequent, I can't help but think why wouldn't couchdb be a good platform to deliver such updates?
The main advantage I could think of is its ability to filter updates based on friends and availability of changes api, which makes developing such an application and managing it (including replication) quite easy compared to ampq or xmpp where you have to think about how to manage the pubsub nodes and who is subscribed to them at any point in time.
However, I can't help but think this is too good to be true, I can't find information on what couchdb's shortcomings are. Somehow, it feels like using MySQL for message passing which is why I am hesitant to using it.
Anyone have any experience in using couchdb for such applications? would you recommend another platform to use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
以下是您在“小而频繁”的更新和 CouchDB 中会遇到的一些问题。
CouchDB 有一个优秀的 MVCC 系统用于文档更新。每次更新都会更改修订版，如果不通过您想要更新的修订版，您就无法更新文档。这也意味着，如果您有多个客户端非常频繁地更新同一文档，则此功能将会受到阻碍，因为即使使用更改源，更新后也会出现很小的网络延迟。
使用过滤更改时可能遇到的另一个问题是过滤器函数获取请求对象，这意味着它是对每个文档乘以连接数的视图服务器的单独调用。您可能想使用 node.js 或 erlang 服务器来实现“通道”方法来进行更改过滤，并将其置于单个未过滤的更改源上。
总而言之，如果您没有多个客户端尝试高频率更新相同的文档，并且您不在具有高数据库的大量并发客户端上使用更改过滤器，那么您想要做的事情将会很好地工作更新频率。除此之外，它会工作得很好。 @jchris 仅使用简单的更改提要就完成了大量的实时应用程序，并且它们工作得很好。
Here's some problems you'll run in to with "small but frequent" updates and CouchDB.
CouchDB has an excellent MVCC system for document updates. Every update changes the revision and you can't update a document without passing the revision you'd like to update. This also means that if you have multiple clients updating the same document incredibly frequently this feature will get in the way since even with the changes feed there is a small network delay after updates.
Another problem you might have using filtered changes is that the filter function gets the request object, which means it's a separate call to the view server for every document multiplied by the number of connections. You may instead want to use a node.js or erlang server to implement a "channels" approach to change filtering and have it sit on a single unfiltered changes feed.
To summarize, what you want to do will work well if you don't have multiple clients attempting to update the same documents at high frequency and if you don't use a changes filter on a very large number of concurrent clients with a high database update frequency. Other than that, it'll work great. @jchris has done a ton of real-time application just using the bare changes feed and they work great.
尝试看看为什么数据库对于消息传递来说很糟糕演示。虽然它主要针对 MySQL 等数据库，但它可以让您对这个主题有更全面的了解。
Try to look at why Databases suck for Messaging presentation. Although it's mainly targeted against databases such as MySQL, it can give you a bigger picturer on this topic.
我可以想到一个非常简单的原因......因为数据库不是为做到这一点而设计的！
消息队列正是此类工作流程所需要的。您是否看过一些基于 AMQP 的产品或服务？其中包括 RabbitMQ（本地安装）和 StormMQ（基于云的服务）。更多这里：
http://www.amqp.org
I can think of one very simple reason...because databases were not designed to do this!
A message queue is exactly what this sort of work flow needs. Have you looked at some of the AMQP based products or services? These include RabbitMQ (installed locally) and StormMQ (cloud based service). More here:
http://www.amqp.org