我们首次使用 MongoDB 构建一个新系统。我们的主要文档集合之一包含大小可以从几百字节到接近 16MB 文档限制的任意大小的文档。
我们需要跟踪文档被阅读的次数并限制阅读次数。
我们正在权衡两种选择：
第一个的价值在于我们可以一次将计数和数据获取到数据库中。
引起这个问题的部分是文档大小似乎会影响写入性能。但是，我没有找到任何关于这种情况的参考。我们的猜测是，即使我们正在更新单个字段，也必须对整个文档进行反序列化、更新、序列化并写回表中。如果文档大小变化很大，那么性能似乎也会随之变化。此外，集合将被索引，MongoDB 文档说每次更新都需要更新集合上的所有索引。这些加起来就是潜在的性能问题。
如果是这样，那么我们将使用第二个选项并进行两次数据库命中。
【问题讨论】：
标签： mongodb
如果您使用“原子更新”运算符并且您正在更新的字段的大小没有变化，则可以在不触及文档其余部分的情况下执行更新。例如，这适用于 $inc。
关于索引，如果您在此处更新的字段上没有索引，则不必更新它们。
【讨论】：
解决您的两个问题，文档的更新不取决于您要更新的文档的大小*。因此，如果您有两个文档：一个包含 200 个字段，重量为 6Mb，另一个包含 3 个字段，重量为 0.4Kb，并且您需要为两个文档更新 2 个字段，它们将花费大约相同的时间。
我在此处添加了星号，因为如果您正在更新文档并且文档变得比原始文档大，那么document will be moved 可能会出现（如果没有足够的空间来容纳新文档）。在这种情况下，文档的大小会增加一些惩罚（您可以使用padding 减轻这种影响）。正如 Thilio 所说，原子更新永远不会导致文档移动。
关于您的索引问题。索引不依赖于文档大小。这取决于您要索引的字段数和字段的大小。例如，具有“非常长的文本将更长”的字段的索引然后是具有“短文本”的字段。并且数组 [1, 2, ..., 500] 的索引大小会比 [1, 2] 长。
【讨论】：