我最近遇到了一种情况，我的 CouchDB 实例使用了 20GB 虚拟机实例上的所有可用磁盘空间。 经过调查，我发现 /usr/local/var/lib/couchdb/ 中的一个目录包含一堆 .view 文件，其中最大的是 16GB。我能够删除 *.view 文件以恢复正常操作。我不确定 .view 文件为何会变得如此之大，以及 CouchDB 如何管理 .view 文件。
更多信息。我有一个运行 512MB 和 CouchDB 0.10 的 Ubuntu 9.10 (karmic) 的虚拟机。 VM 有一个 cron 作业，它调用一个查询视图的 Python 脚本。 cron 作业每五分钟运行一次。每次查询视图时，.view 文件的大小都会增加。我写了一份工作来每小时监控一次，几天后我没有看到文件滚动或以其他方式减小。
有人对这个问题有任何见解吗？有没有我错过的文件？我无法找到有关该主题的任何内容，但这可能是由于查看了错误的位置或我的搜索字词。
【问题讨论】：
标签： couchdb
CouchDB 非常消耗磁盘，用磁盘空间换取性能。随着项目的添加，视图的大小将增加。您可以通过清理和压缩来恢复不再需要的磁盘空间。
每次创建更新或删除文档时，视图索引都会随着文档的相关更改而更新。视图的更新将在查询时发生。因此，如果您要进行大量文档更改，那么您应该期望索引会增长，并且需要通过压缩和清理来管理。
如果您的视图对于给定的一组文档非常大，那么您的视图可能设计不佳。或者，您的设计可能只需要大视图，您需要像管理任何其他资源一样管理它。
如果您可以描述正在发生的文档更新（包括创建和删除）以及您的视图函数正在发出什么，那么就更容易判断发生了什么，尤其是对于大视图。
【讨论】：
?include_docs 这样的操作非常激烈，这使得在视图中包含完整的文档是性能所必需的。这又是 CouchDB 用磁盘空间换取性能的地方。
每次访问视图时，您的 .view 文件都会增长，因为 CouchDB 会在访问时更新视图。 CouchDB 视图也需要像数据库一样的压缩。如果您经常更改文档，导致视图发生变化，则应不时运行视图压缩。见http://wiki.apache.org/couchdb/HTTP_view_API#View_Compaction
要减小视图的大小，请查看您发出的数据。当您发出(foo, doc) 时，整个文档将被复制到视图中，以便在您查询视图时立即可用。函数（doc）{发出（doc.title，doc）； } 将产生一个与数据库本身一样大的视图。你也可以发出(doc.title, nil);并使用 include_docs 选项让 CouchDB 在您访问视图时从数据库中获取文档（这将导致稍微的性能损失）。见http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options
【讨论】：
对文档使用顺序或单调的 id 而不是随机的
是的，couchdb 非常需要磁盘，并且需要定期压缩。但是还有另一件事可以帮助减少磁盘使用量，尤其是在不必要的时候。
Couchdb 使用 B+ 树来存储数据/文档，这是一种非常好的数据结构，可以提高数据检索的性能。然而，使用 B-tree 会以性能换取磁盘空间的使用。使用完全随机的 Id，B+-tree 迅速扇出。由于每个内部节点的最小填充率为 1/2，因此节点大多填充到 1/2（由于数据的随机性而均匀分布），从而生成更多的内部节点。新的插入也可能导致整棵树的重写。这就是随机性可能导致的 ;)
相反，使用sequential or monotonic id 可以避免所有问题。
【讨论】：
我也遇到过这个问题，尝试使用 CouchDB 开发基于浏览的游戏。
在网站启动的第一天，我们就有大约 100,000 名不速之客，在 2 天内，CouchDB 数据库占用了大约 40GB 的空间。这导致服务器崩溃，因为 HD 已满。
压缩将其恢复到大约 50MB。我还将_revs_limit（默认为 1000）设置为 10，因为我们不关心修订历史，并且从那以后它运行良好。在几乎 1M 用户之后，数据库大小通常在 2-3GB 左右。当我运行压缩时，它大约是 500MB。
将文档修订限制设置为 10：curl -X PUT -d "10" http://dbuser:dbpassword@127.0.0.1:5984/yourdb/_revs_limit
或者没有用户：密码（不推荐）：curl -X PUT -d "10" http://127.0.0.1:5984/yourdb/_revs_limit
【讨论】：