我想在CouchDB文档中存储计数器，每个页面视图递增。CouchDB将为这个文档创建一个完整的修订版，只需一次计数器更新。
这样不会占用太多空间吗?考虑到我一天有100万次点击，我可能会在一天内查看文档的100万次修改。
对此有什么想法吗?
谢谢!
CouchDB非常明确地说明了它所做的权衡。在这种特殊情况下，我们谈论的是一个防崩溃数据库，不幸的是，它可以并且将使用大量磁盘，直到压缩。
你得到了这样的可靠性和读的并发性。您还将获得与任何其他节点无缝复制的能力。这是最重要的。因为计数器碰撞而不得不压缩是最糟糕的。不要乱搞_rev_limit。你会把自己搞砸的，因为修改是Couch的基础。
你有一个可能是记录一些信息，日期和时间，IP和其他东西。然后，您将创建一个发送所需数据的视图，并使用_count作为reduce函数。你会得到你需要的信息和其他一些可能对分析有价值的东西。这就是"创建一个视图"的解决方案。
第二种可能是使用[redis] (http://redis.io/commands/incr)。Redis非常好，很适合这个用例(http://ai.mee.nu/is_couchdb_the_anti-redis)。这将是"适合工作的合适工具"的解决方案。第三种可能是简单地忽略它。这可能根本不是问题(如果你经常压缩)。这将是"放松"的解决方案。
你必须接受好的和坏的，确保利大于弊。
我认为这是不可能的。
另一种解决方案是将计数器放在一个小文档中，并定期对其运行压缩。这不是最优的，但是它最小化了占用的空间。
您可能还想考虑使用memcached(或Membase)之类的东西作为"计数器存储"。这将允许您更新这些计数器，而无需在CouchDB中创建额外的修订。我假设您实际上不需要保留计数器的所有中间状态(因为您说您不希望保留修订)，因此将它们放在更适合此用例的地方似乎是有意义的。
如果您不需要复制，您可以将计数器保存在_local文档中。本地文档没有版本历史记录。您也可以在不知道其修订的情况下保存它们。它们不复制，最后写总是占上风。
创建/更新_local文档只需使用PUT /db/_local/[DOCID]
您可以使用GET /db/_local/[DOCID]
我们在做一个小实验…
文档有默认的1000转速限制，有大约100kb的附件，1个整数计数器，我们不断增加
我们最终使用了大约4GB的磁盘，用于大约200,000个增量。使用压实&它被减少到大约6KB。
现在这是一个令人沮丧的!
我现在最担心的是——在一个写量很大的实例上运行频繁的压缩(可能是每小时/每天两次/等等)!