好了，在我的游戏每个球员在我的球员集合有一个文件，每个玩家都有1个字符串，是一个序列化都有自己的游戏州。所以这个字符串可以是 长或短的方式，并且每个玩家都有很大的差异。存储一个字符串，可以改变很多，从很长很短::碎片
我有别人谁没有一吨的蒙戈的经验告诉我，我应该垫的集合，使他们都是一样的长度在每一个字符串。所以就像在所有短和中等游戏状态字符串的末尾添加大量的零。
所以A）这是一个好主意吗？
B）我还没有完全确定如何找出游戏的最长所以林不知道多远，垫他们，如果以后的游戏状态超过我的填充长度是什么？
我的朋友说，他有一个蒙戈集合不断吹起来，因为碎片，当他实施填充了他所有的问题就走了。
哦，我怀疑它的问题，但我的代码是在PHP，显然使用PHP PECL蒙戈司机
感谢您的任何想法或输入!!!!!
-Dave
从你的问题我理解那些字符串只是斑点，即它们不是以某种方式结构允许DB查询/对它们的内容过滤。如果是这种情况，请将它们存储在文件中，并将文件名存储在mongo文档中。
所以A）这是个好主意吗？
依赖。如果经常更新游戏文件，以便他们在磁盘上移动很多，那么您可能会发现填充确实有帮助，但是，考虑到莎士比亚的整个作品可以放入一个4MB的文档中，并留下一些空间非常怀疑你有任何字符串会导致大量的碎片;事实上，如果确实如此，我会很惊讶。
，在理论上，出现的问题是，你得到你很多的自由列表中的文件和删除桶不能导致出现碎片被重用。
不仅如此，磁盘移动的IO可能会成为杀手，如果它变得持久。
B）我还没有完全确定如何找出游戏的最长所以林不知道多远，垫他们，如果以后的游戏状态超过我的填充长度是什么？
然后这个想法是没用的，事实上这个想法的时候没用90％不管怎样，使用2个大小分配的权力在你的文件，如果这是成为一个问题，你会过得更好：http://docs.mongodb.org/manual/reference/command/collMod/#usePowerOf2Sizes
使用此选项将是解决碎片问题的最佳方法。
我的朋友说他有一个mongo收藏因为碎片而不断炸毁，当他实施填充时，他所有的问题都消失了。
一位朋友，一位表妹的朋友，我的一个侄女的朋友也说过类似的话......你最好自己测试一下。
我敢打赌，他遇到的更大的问题是索引和他执行的查询。对于字符串长度而言，在磁盘移动中导致如此巨大的IO使用量，这实际上使用人为填充是极为罕见的。
MongoDB在创建时为文档分配空间。如果文档的大小增加，文档将需要移动到新的位置以适应更大的尺寸。原始空间不会释放到操作系统。相反，MongoDB最终将重用这个空间。在这种情况发生之前，可能会出现数据库过度分配或有时称为分段的情况。
那么，什么可能发生在你的朋友：插入
而通过填充文档中的字段，朋友能够确保文件的大小永远不会增长，因此他的数据库永远不会超额分配。
填充方法是有效的，但它也增加了应用程序的复杂性。通常，对于最终将创建的字段执行填充操作，而不是固定值本身的大小，但是想法是相同的。在你的情况下，它听起来不像填充是一个很好的选择，因为你无法预测字段大小。
相反，你可以考虑使用usePowerOf2Sizes：http://docs.mongodb.org/manual/reference/command/collMod/
此配置将自动填充的空间分配的文件，并会增加空间有效利用的MongoDB在稍大数据库的成本重复使用的机会。