我想知道为什么我的CouchDB数据库增长如此之快,所以我写了一些test script。此脚本将CouchDB文档的属性更改1200次,并在每次更改后获取数据库的大小。在执行这1200个写入步骤之后,数据库正在执行compaction step,并且再次测量db大小。最后,脚本根据修订号绘制数据库大小。基准测试运行两次:
第一次运行将生成以下图
第二次运行产生了这个图
对我来说,这是一个相当意想不到的行为。在第一次运行时,我预计会出现线性增长,因为每次更改都会产生新的修订。当达到1000个修订版时,大小值应该是恒定的,因为较早的修订版将被丢弃。在压实之后,尺寸应该会显着下降。
在第二次运行中,第一次修订应该产生一定的数据库大小,然后在随后的写入步骤中保持该大小,因为每次新的修订都会导致删除前一次修订。
如果需要一点开销来管理更改,我可以理解,但这种增长行为对我来说似乎很奇怪。有没有人能解释这种现象,或者纠正我导致错误预期的假设?
发布于 2010-05-28 21:11:49
首先,CouchDB甚至为删除的修订保存了一些信息(只保存ID和修订标识符),因为它需要这些信息用于复制目的。
其次,由于数据保存在磁盘上的方式(请参阅WikiPedia),一次插入一个文档并不是最优的,这可以解释第一个图中的超线性增长。
https://stackoverflow.com/questions/2921151
复制相似问题