我用CouchDB后端编写了一个应用程序。我花了很多时间在CouchDB上，所以我不愿意把所有东西都移到不同的NoSQL数据库（比如Redis）。
问题是我现在需要实现速率限制（基于IP地址）功能。
Redis对于这种任务有多好plenty of examples，但是因为我不想将CouchDB丢弃用于其他任务，这意味着我将基本上运行（并支持）两个数据库（1个用于大多数数据，1表示速率限制）等......
答案 0 :(得分：6)
与Redis串联运行CouchDB闻所未闻？
Redis通常与其他存储解决方案（MySQL，PostgreSQL，MongoDB，CouchDB等）配合使用。与许多其他NoSQL解决方案一样，Redis不适用于所有类型的工作负载或情况。 Redis的作者是务实和开放的人，当他们更适应这种情况时，他们通常建议使用其他解决方案而不是Redis。
因此，Redis是一个优秀的团队合作者，通常很容易集成到现有的基础架构中。这是an example of usage of Redis with CouchDB。
CouchDB本身是否适合处理速率限制？
CouchDB有许多有用的功能来实现Chris O'Hara的文章中描述的速率限制策略。例如，它在几个文档上支持bulk operations（具有可选的原子性）。 “桶跨度”可以存储在单个文档中。可以使用update handlers覆盖计数器的就地增量。
IMO，主要的缺失功能是自动项目到期（CouchDB不提供AFAIK）。所以你必须设计一个聪明的机制来摆脱CouchDB之上的过时数据。
主要问题是CouchDB并非真正设计用于此类工作负载：它是面向日志结构化文档的数据库。每次计数器必须递增时，它将涉及JSON解包/打包操作，要执行的一些Javascript代码，以及仅附加文件来编写整个文档的新修订版。您可以找到一篇很好的文章，描述CouchDB如何存储其数据here。
我怀疑在CouchDB之上实施的速率限制策略不能很好地扩展（I / O太多，CPU消耗太多，网络协议效率低）。例如，CouchDB是一个RESTful服务器;我不习惯启动客户端HTTP操作（对CouchDB的REST查询）来限制我系统的每个传入HTTP查询。
Redis更适应这种工作负载（快速，内存中，没有I / O，高效的客户端协议，没有JSON解析/格式化，增量是本机原子操作等等）。
答案 1 :(得分：1)
您可以使用Memcached进行速率限制 - 它提供了一个很好的计数器增量命令，加上过时的数据会在适当的时候从缓存中自动清除，因此它具有Redis对此应用程序的所有好处，而不会产生烦人的重复在CouchDB上运行Redis会带来的能力（和复杂性）。
http://simonwillison.net/2009/jan/7/ratelimitcache/
您可以轻松地将memcached添加到您自己的设置中，或者您可以调查CouchBase，其当前的服务器产品集成了CouchDB派生的数据库，其中包含Memcached兼容性：
http://www.couchbase.com/memcached
我个人不喜欢Couchbase从CouchDB分叉的方式，但对于你的应用程序，它可能是一个完美的选择。