我想在CouchDB文档中存储计数器，在每个页面视图上递增。 CouchDB将只为1次计数器更新创建该文档的完整版本。
这不会消耗太多空间吗？ 考虑到我每天有1M次点击，我可能会在一天内查看文档的1M修订版。
对此有任何想法...
谢谢！
答案 0 :(得分：7)
CouchDB非常清楚它所做出的权衡。在这个特殊情况下，我们正在谈论有一个防撞数据库，遗憾的是，在压缩之前可以并将使用大量磁盘。
您可以获得这种可靠性以及大量的读取并发性。您还可以与任何其他节点无缝复制。这是它的培根。由于碰撞计数器而必须紧凑是它的吮吸。忘了用_rev_limit来解决问题。你会搞砸自己，因为修订是Couch的基础。
您拥有的一种可能性是记录一些信息，日期和时间，IP和其他内容。然后，您将创建一个发出所需数据的视图，并使用_count作为reduce函数。您将获得所需的信息以及其他一些可能有价值的分析内容。这是“只是创建一个视图”的解决方案。
第二种可能性是使用[redis]（http://redis.io/commands/incr）。 Redis相当不错，适合这个用例（http://ai.mee.nu/is_couchdb_the_anti-redis）。这将是“正确工作的正确工具”解决方案。
第三种可能性就是忽略它。它可能根本不是问题（如果你经常压缩）。这将是“放松”的解决方案。
你必须把好处带走，并确保优势超过劣势。在剪切/优化之前测量所有内容两次。
答案 1 :(得分：3)
我认为这不可能。
另一种解决方案是将计数器放在一个小文档中，并定期运行compaction。这不是最佳选择，但可以最大限度地减少占用的空间。
答案 2 :(得分：2)
如果不需要复制，可以将Counter保存在_local文档中。 本地文档没有版本历史记录。 您也可以保存它们而不知道它们的修订版本。 他们不复制，最后一次写总是赢。
要创建/更新_local文档，只需使用PUT /db/_local/[DOCID]
您可以使用GET /db/_local/[DOCID]
答案 3 :(得分：1)
您可能还想考虑使用memcached（或Membase）之类的东西作为“计数器存储”。这将允许您更新这些计数器，而无需在CouchDB中创建额外的修订。我假设您实际上并不需要保留计数器的所有中间状态（因为您说您不希望保留修订版本），因此将它们放在更适合此用例的内容中似乎是有意义的。
答案 4 :(得分：0)
我们正在做一个小实验...
该文件有默认的1000转限制，有大约100kb的附件，1个整数计数器，我们一直在增加
我们最终使用大约4GB的磁盘，大约200,000个增量。二手压实＆amp;它减少到大约6KB。
现在这真是太糟糕了！
我现在非常担心 - 在一个写重的沙发实例上经常进行压缩（可能是每小时/每天两次/等）！