4
アプリケーションでは、オブジェクトを格納するためにbucketsの概念を使用します。すべてのバケツは作成時に空です。そのうちのいくつかは、2時間以内に最大20個の物体を充填することができ、6ヶ月にはいくつかの物体を充填することができる。各オブジェクトのサイズはかなり固定されています。つまり、サイズが10％を超えて異なるとは思わない、つまり完全なバケットのサイズも同じではありません。実装はそれに似ています。 padding factor低く保つMongoDBがSpringでパディングするのを避けるためのエンティティ事前挿入
@Document
public class MyBucket {
// maximum capacity of 20
private List<MyObject> objects;
}
一つのアプローチは、ダミーデータと私のバケツを事前格納することです。二つのオプションは、私の心に来る：
- その内容をリセットし、ダミーデータと「自然のまま」としてフラグを持つバケットを作成
- もう一度それを保存し、それを保存、ダミーデータでバケットを作成します。最初の書き込みでは、フラグはfalseに設定され、データはリセットされます。
オプション1は2回のDB書き込みが必要で、オプション2は自分のエンティティで余分な（ビジネス以外の）コードが必要です。
恐らく私はどんな解決策でも安くは降りません。それにもかかわらず、その問題の実際の経験、ベストプラクティスまたはヒントはありますか？
セットアップ：春データMongoDBの1.9.2、限り、あなたの主な懸念を理解などのMongoDB 3.2
問題の実際の内容を詳しく説明してください。パディングファクタでどのような問題を解決していますか？ –
避けたいシナリオは次のとおりです。 数日で100000個の予備の空のバケットを作成します。これらのバケツの80％は1年間の作成時にサイズの20倍に成長することがわかっています。これらのバケットをあらかじめ準備していないと、すばやくパディングファクタが4になり、非常に非効率なメモリ使用、大規模な再配置、スペースの無駄になります。私はコンパクトや修理のようなオプションがあることを知っていますが、私はMongoDBにそれが期待できる文書サイズを伝えることによってそれを回避しようとします。 – Matt