假设一款手机游戏由 MongoDB 数据库支持，其中包含User包含数百万份文档的集合。
现在假设必须与用户关联的几十个属性 - 例如一个数组_id的值Friend文件，他们的用户名，照片，一系列_id的值Game文件、上次登录日期、游戏货币数量等等等等。
我担心的是，在数百万个用户文档上创建和更新大型且不断增长的数组是否会增加每个用户文档的“权重”，和/或增加整个系统的速度。
我们可能永远不会超过每个文档 16mb，但我们可以有把握地说，如果我们直接存储这些不断增长的列表，我们的文档将增大 10-20 倍。
问题：这在 MongoDB 中也是一个问题吗？如果使用投影和索引等正确管理查询，文档大小是否重要？我们是否应该积极修剪文档大小，例如引用外部列表与嵌入列表_id直接取值？
换句话说：如果我想要一个用户的last_login值，将是一个仅投影/选择的查询last_login如果我的领域有什么不同User文档大小是 100kb 还是 5mb？
或者：如果我想查找具有特定属性的所有用户last_login值，文档大小会影响此类查询吗？
重新表述这个问题的一种方法是，如果每个文档为 16mb 与 16kb，则 100 万个文档查询是否需要更长的时间。
如果我错了，请纠正我，根据我自己的经验，文档大小越小，查询越快。
我对 500k 文档和 25k 文档进行了查询，25k 查询明显更快 - 快了几毫秒到 1-3 秒。在生产过程中，时间差异大约是 2 倍到 10 倍。
文档大小发挥作用的一方面是查询排序，在这种情况下，文档大小将影响查询本身是否运行。我曾多次尝试对 2k 份文档进行排序，但已达到此限制。
这里有一些解决方案的更多参考：https://docs.mongodb.org/manual/reference/limits/#operations https://docs.mongodb.org/manual/reference/limits/#operations
https://docs.mongodb.org/manual/reference/operator/aggregation/sort/#sort-memory-limit https://docs.mongodb.org/manual/reference/operator/aggregation/sort/#sort-memory-limit
归根结底，受苦的还是最终用户。
当我尝试修复导致性能缓慢到无法接受的大型查询时。我通常发现自己使用数据子集创建一个新集合，并使用大量查询条件以及排序和限制。
希望这可以帮助！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
