2016-07-31 72 views
4

在应用程序中,我使用buckets的概念来存储对象。所有的桶在创建时都是空的。其中一些可能会在两个小时内填满20个物体的最大容量,一些在6个月内。每个对象的大小几乎是固定的,即我不认为它们的大小差异超过10%,即满桶的大小也不会。实现看起来与此类似。保持padding factorMongoDB的实体预填充以避免使用弹簧填充

@Document 
public class MyBucket { 
    // maximum capacity of 20 
    private List<MyObject> objects; 
} 

一种方法是将预填充我的桶的虚拟数据。两个选项来我的脑海:

  1. 创建虚拟数据桶,保存它,然后重置其内容,并再次
  2. 保存创建虚拟数据和其标记为“原始”的水桶。在第一次写入时,该标志被设置为false,并且数据被重置。

缺点很明显,选项1需要两次数据库写入,选项2需要额外的(非业务)代码在我的实体中。

也许我不会用任何解决方案便宜地下车。尽管如此,任何有关该问题的实际经验,任何最佳实践或提示?

设置:春季数据的MongoDB 1.9.2,MongoDB的3.2

+0

你能否更详细地解释一下问题究竟是什么,你用填充因子解决什么问题? –

+0

我想避免的情况如下: 我在几天内创建了100.000个初步空桶。我知道80%的水桶在一年的时间里会增长到其尺寸的20倍。如果我没有预先填充这些桶,他们将会很快产生4的填充因子,导致内存使用效率非常低,大量搬迁和浪费空间。我知道有一些选项比如压缩或修复,但我会尽量避免告诉MongoDB它可以预期的文档大小。 – Matt

回答

2

据了解您主要关注的是有关文件的大小导致对文档的搬迁和索引更新增加性能开销。这是mmapv1存储引擎的实际情况,但是自从MongoDB 3.0版本以来,可用的WiredTiger存储引擎不存在此类问题(请检查类似的question)。