我最近遇到的情况是我的CouchDB实例使用了20GB VM实例上的所有可用磁盘空间。 经过调查，我发现/ usr / local / var / lib / couchdb /中的目录包含一堆.view文件，其中最大的是16GB。我能够删除* .view文件以恢复正常操作。我不确定为什么.view文件变得如此之大以及CouchDB如何管理.view文件。
更多信息。我有一台运行Ubuntu 9.10（karmic）的VM，512MB和CouchDB 0.10。 VM有一个cron作业，它调用查询视图的Python脚本。 cron作业每五分钟运行一次。每次查询视图时，.view文件的大小都会增加。我已经写了一份工作来按小时监控这个问题，几天后我看不到文件翻滚或者尺寸减小。
有没有人对此问题有任何见解？有没有我错过的文件？我无法找到有关该主题的任何内容，但这可能是由于查找错误的地方或我的搜索字词。
答案 0 :(得分：13)
CouchDB非常耗油，为了提高性能而交换磁盘空间。随着项目的添加，视图的大小会增加。您可以通过清理和压缩来恢复不再需要的磁盘空间。
每次创建更新或删除文档时，视图索引都将使用对文档的相关更改进行更新。查询时将发生对视图的更新。因此，如果您要进行大量的文档更改，那么您应该期望索引增长，并且需要通过压缩和清理来管理。
如果您的视图对于给定的文档集非常大，那么您可能设计的视图设计不佳。或者，您的设计可能只需要大量视图，您将需要像管理任何其他资源一样进行管理。
如果您可以描述正在发生的文档更新（包括创建和删除）以及您的视图函数正在发出的内容，尤其是对于大视图，则更容易分辨出正在发生的事情。
答案 1 :(得分：7)
每次访问视图时，.view文件都会增长，因为CouchDB会更新访问视图。 CouchDB视图也需要像数据库一样压缩。如果您经常更改文档，导致视图发生更改，则应不时运行视图压缩。见http://wiki.apache.org/couchdb/HTTP_view_API#View_Compaction
要缩小视图的大小，请查看数据，然后发出。当您发出（foo，doc）时，整个文档被复制到视图中，当您查询视图时，它立即可用。函数（doc）{emit（doc.title，doc）;将导致视图与数据库本身一样大。你也可以发射（doc.title，nil）;并使用include_docs选项让CouchDB在访问视图时从数据库中获取文档（这会导致性能略有下降）。见http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options
答案 2 :(得分：3)
对文档使用顺序或单调id，而不是随机
是的，couchdb非常耗费磁盘，需要定期压缩。但还有另一件事可以帮助减少磁盘使用量，特别是在有必要的时候。
Couchdb使用B +树来存储数据/文档，这是用于数据检索性能的非常好的数据结构。但是，在磁盘空间使用的性能中使用B树交易。有完全随机的Id，B + -tree粉丝快速出局。由于每个内部节点的最小填充率为1/2，因此节点大部分填充到1/2（因为数据由于其随机性而均匀分布），从而生成更多内部节点。此外，新插入可能会导致重写完整树。这就是随机性可能导致的;）
相反，使用sequential or monotonic ID可以避免所有。
答案 3 :(得分：1)
我也遇到过这个问题，尝试使用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