我已经阅读了很多关于该主题的文档、问答等（嵌入或使用参考）。我理解为什么您应该使用一种或另一种方法的要点，但我看不到有人讨论（询问）类似的情况：
我有 2 个 (A和B) 实体，它们之间的关系是 ONE_TO_MANY （A可能属于许多B），我可以使用embed（非规范化方法）并且没关系（我清楚地理解它），但是如果我想（稍后）修改其中一个怎么办使用，成许多B文档，A文档字段？修改不代表替换A为A'，而是将一些修改准确A记录下来。这意味着（embed以防万一）我必须在所有已经有版本的B文档中应用这些更改。A
What If later we would like to change used in many documents address:name field ?
What If we need the list of available addresses in the system ?
这些操作在 MongoDb 中完成的速度有多快？
它基于主要使用的操作。如果您要插入和选择大量文档并且有可能，例如每月一次您将需要修改许多嵌套的子文档，我认为存储A在里面B是一种很好的做法，这就是 mongodb 应该是的。您只需选择一个文档即可节省大量时间，而无需加入另一个文档，并且每次可以忍受一次较慢的更新，而不会出现任何问题。
我会提出更多关于速度的建议。
如果您有一个名为 A 的子文档，它嵌入到许多文档中 - 并且您想要更改 A 的实例...
请注意，文档不会随着更改而增长太多。如果 A 变得太大，那将损害性能，因为它将迫使 Mongo 将文档移动到内存中。
这显然取决于您拥有多少嵌入式实例。你拥有的越多，它就会越慢。
这取决于您如何匹配子文档。如果你在没有索引的情况下找到 A，它会很慢。如果您使用范围运算符来识别它，它会很慢。
有人已经提到文件的大小很可能会影响速度。
我听到的关于是否链接或嵌入的最佳建议是……如果实体（在本例中为 A）是可变的……如果它要经常变异/更改……然后链接它，不要嵌入它。
更新操作的速度显然取决于数据量。
关于是否使用嵌入式文档或参考的其他考虑因素是单个文档中的数据量是否会超过 16mb。这是很多文件的想法。
然而，在某些情况下，对整个文档进行非规范化是没有意义的，尤其是在其他地方使用/引用它们的地方。
以User文档为例，您通常不会对需要引用用户的每个集合中的所有用户属性进行非规范化。相反，您引用用户 [可能带有一些非规范化的用户详细信息]。
显然，当引用的用户更改时，每个额外的非规范化值（除非是审计）都需要更新，但您可以将更新排队等待后台进程处理 - 而不是让调用者等待。