批量更新NoSQL文档：糟糕的做法？

Question

我在MongoDB数据库中存储了两个集合：

==网站==

id nickname url ==检查==

id website_id status

我想显示一个具有相应网站昵称的支票状态列表。

例如：

[Google，200]＆lt;＆lt; （基本上是SQL世界中的连接）

我有成千上万的支票，只有几个网站。

哪个更有效？

1. 将网站的昵称存储在＆＃34;检查＆＃34;直。这意味着如果昵称发生变化，我将不得不对数千份文件进行大规模更新。

2. 返回一个多维数组，其中站点ID是键，昵称是值。这在迭代检查列表时使用。

我读过＃1并不是太糟糕（在NoSQL中）并且事实上可能更受欢迎？真？

Answer 1

如果它只是少数几个网站，我会选择选项1 - 不像关系/ SQL世界那样干净和规范化，但它比使用MongoDB模拟连接更有效。 MongoDB或任何其他NoSQL数据库要记住的事情是你通常会做出某种交易 - 没有什么是免费的。我个人非常重视无模式的面向文档的数据设计，对于我使用它的应用程序，我很容易做出权衡（比如没有连接和事务）。

那就是说，这是一个权衡 - 所以在这种情况下总是要问自己，为什么我使用MongoDB或其他NoSQL数据库呢？是的，这是时髦和“热”，但我确定你正在做的事情对NoSQL方法有意义。如果你花费大量时间来解决缺少连接和外键，没有任何事务以及你在SQL世界中习惯的其他事情，我会认真考虑这是否最适合你的问题。

Answer 2

您可以考虑第三种选择：摆脱Checks集合，并将每个网站的支票作为数组嵌入到每个Websites文档中。

通过这种方式，您可以避免任何JOIN，并避免出现不一致，因为Check无法在没有Website的情况下存在。

但是，只有当每个文档的checks数组随时间保持相对恒定且不会不断增长时，才建议使用此方法。 MongoDB中应该避免快速增长的文档，因为每当文档的大小增加一倍时，它就会被移动到存储在其中的物理文件中的不同位置，这会降低写入操作的速度。此外，MongoDB每个文档限制为16MB。这种限制主要是为了阻止不断增长的文件。

您还没有说明申请中Check实际上是什么。当它是您定期执行的任务列表并且只是偶尔进行更改时，嵌入就没有问题。但是，当您收集所有检查的历史结果时，我宁愿建议将每个结果（设置？）放在自己的文档中以避免文档增长。