我编写了一个带有 CouchDB 后端的应用程序。我在 CouchDB 上投入了大量时间，所以我不愿意将所有内容都转移到不同的 NoSQL 数据库(如 Redis)。
问题是我现在需要实现速率限制(基于 IP 地址)功能。
有plenty of examples关于 Redis 对于这种任务有多好，但是因为我不想为其他任务放弃 CouchDB 这意味着我基本上会运行(并支持)两个数据库(1 个用于大多数数据，1 个用于速率限制)等等...
- 将 CouchDB 与 Redis 结合使用是否闻所未闻？
- CouchDB 本身适合处理速率限制吗？
最佳答案
将 CouchDB 与 Redis 结合使用是否闻所未闻？
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 消耗、低效的网络协议(protocol))。例如，CouchDB 是一个 RESTful 服务器；我不愿意启动客户端 HTTP 操作(对 CouchDB 的 REST 查询)来限制我系统的每个传入 HTTP 查询的速率。
Redis 更适合这种工作负载(快速、内存中、无 I/O、高效的客户端协议(protocol)、无 JSON 解析/格式化、增量是 native 原子操作等......)
关于couchdb - 速率限制 - 将 CouchDB 与 Redis 一起使用或单独使用 CouchDB，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10919625/