这与我之前的问题有关。在处理并存储到关系数据库之前，我们使用berkeley DB作为临时存储。当尺寸增加超过某一点时，问题就出现了。现在我们要么将文件分割成更小的文件，要么压缩现有的文件。在这个问题中，我想问压缩部分，berkeley DB是否有任何内置的压缩实用程序，或者我们必须通过编程来实现。如果它是内置的，那么它总是会更快。
从这里:
根据伯克利常见问题解答，有两种方法可以优化它(在压缩之前):
- 真空
您也可以实现自己的压缩算法，如下所示。
Berkeley DB VACUUM与SQLite的有何不同?
SQLite将VACUUM命令作为数据库转储执行从该转储完成重新加载。锁是一个代价很高的操作操作期间的整个数据库。它也是一个全有或全无操作。要么成功，要么失败，你必须改天再试一次。当SQLite结束时，数据库将频繁地关闭大小越小(文件大小越小)，b树越好组织(浅)比以前由于按顺序键插入转储文件中的数据。SQLite，什么时候可以工作，什么时候可以负担得起将所有人锁定在数据库之外，很好地完成了VACUUM。Berkeley DB以一种完全不同的方式来处理这个问题。对于许多现在，Berkeley DB的B-Tree实现已经具备了这种能力在飞行中进行其他操作时进行压缩。压缩是一种过程，其中b树节点被检查，当小于最优，它们被重新组织(反向拆分等)。越浅在b树中，查找叶子上的数据所需的查找次数越少节点。Berkeley DB可以压缩树的部分，也可以压缩整个树在一次。对于7x24x365(5 - 9)操作，这是至关重要的。BDB的compact的版本不会对正在进行的数据库操作产生不利影响而SQLite的方法可以。但是压缩并不解决空的问题数据库的部分(数据库文件的段)被删除数据曾经存在)。Berkeley DB还支持数据库压缩通过移动文件内的数据，然后截断文件将该空间返回给文件系统。从Berkeley的5.1版开始在数据库中，VACUUM命令将压缩数据库文件。此操作比SQLite的转储/加载方法花费更多的时间因为它做了更多的工作来允许数据库保留操作。我们相信这是正确的交易，但如果你不同意，你可以在代码中转储/加载数据库。