7

虽然使用 ampq 或 xmpp（可能有 couchdb 作为后端的rabbitmq 或 ejabbered）似乎很适合在更新小但频繁的社交游戏平台中提供有关朋友状态的实时更新，但我不禁想到为什么不couchdb 不是提供此类更新的好平台吗？

我能想到的主要优点是它能够根据朋友和更改 API 的可用性过滤更新，这使得开发这样的应用程序和管理它（包括复制）与你必须考虑如何管理 pubsub 节点以及在任何时间点订阅它们的人。

但是，我不禁认为这太好了，我无法找到有关 couchdb 缺点的信息。不知何故，感觉就像使用 MySQL 进行消息传递，这就是我犹豫使用它的原因。

任何人都有将 couchdb 用于此类应用程序的经验吗？您会推荐其他平台使用吗？

4

3 回答 3

6

以下是您在使用“小而频繁”的更新和 CouchDB 时会遇到的一些问题。

CouchDB 有一个优秀的 MVCC 系统用于文档更新。每次更新都会更改修订版，如果不传递要更新的修订版，您将无法更新文档。这也意味着，如果您有多个客户端非常频繁地更新同一个文档，则此功能会妨碍您，因为即使使用更改提要，更新后的网络延迟也会很小。

使用过滤更改可能遇到的另一个问题是过滤器函数获取请求对象，这意味着它是对每个文档乘以连接数的视图服务器的单独调用。相反，您可能希望使用 node.js 或 erlang 服务器来实现“通道”方法来更改过滤并将其放在单个未过滤的更改提要上。

总而言之，如果您没有多个客户端试图以高频率更新相同的文档，并且如果您没有在具有高数据库的大量并发客户端上使用更改过滤器，那么您想要做的事情将会很好。更新频率。除此之外，它会很好用。@jchris 仅使用裸更改源就完成了大量的实时应用程序，它们运行良好。

于 2010-05-27T05:41:13.333 回答
2

但是，我不禁认为这太好了，我无法找到有关 couchdb 缺点的信息。不知何故，感觉就像使用 MySQL 进行消息传递，这就是我犹豫使用它的原因。

试着看看为什么数据库不适合消息传递。尽管它主要针对 MySQL 等数据库，但它可以为您提供有关此主题的更大图景。

于 2011-08-18T07:11:49.260 回答
1

我能想到一个非常简单的原因……因为数据库不是为此而设计的！

消息队列正是这种工作流程所需要的。您是否看过一些基于 AMQP 的产品或服务？其中包括 RabbitMQ（本地安装）和 StormMQ（基于云的服务）。更多信息：http: //www.amqp.org

于 2011-08-18T06:54:32.193 回答