来自少数操作的MongoDB聚合

我们系统中的每个用户（如Facebook和twitter）都可以选择将其他用户添加到其预定义的列表中，如：*“收藏夹”、“关注”、“阻止”、“关闭的朋友”。然后，我们希望允许他搜索列表，过滤并查看上面所有列表中的可交换数据。例如：

UserA {
   IsFollow: 1,
   IsFavorite: 0
   ...
   IsBlocked: 0
} 

我们还希望在用户将其他用户添加到上述列表（如addingDate）时保留一些附加信息

选项一是管理不同的收藏，如“收藏”、“关注”、“阻止”、“关闭的朋友”

选项二-管理一个集合，如“关系”，并保留该集合上的所有数据，而无需使用查找

选项三-使用选项一，但创建一个包含每个表中所有相关数据的平面集合（RabbitMQ、事务更新等）

---

由于我是MongoDB新手（我正在从MS SQL迁移系统），我想知道什么是实现高规模系统的最佳方法；DR：使用分布式和有序日志，如Kafka、Kinesis、EventHub等。。。并根据您的用例建立协议以建立关系，然后在两个用户记录上记录关系。我之所以提到这个协议，是因为它确保了用户记录之间的一致性，这是数据库之外转移到您这边的责任之一

<> P>将数据库从数据库分解为NoSQL存储，将关系数据库转移到NoSQL存储中，有助于规范化。您将负责管理预写日志（可能是隐式的和非统一的）的处理，并在记录之间创建一致性

我会推荐阅读马丁·克莱普曼（Martin Kleppman）写的相对简短的书，也许还有更大的版本（这本电子书是一本挑逗性的书）叫做。还有很多其他资源，但这些都是最好的。所涵盖的关键见解包括秩序和共识的等价性

太长了，读不下去了，我的TL；DR支持了你提到的集合源于（或属于）控制它们的用户。因此，在非规范化的世界中，它们是用户数据的一部分，并在这些记录中复制。在这种高规模的系统架构下，代码/系统负责管理复制的数据并在整个系统中保持其一致性。您可能会考虑到，为了减少查询延迟，您可能希望缓存远程用户的一些细节，但这将增加您在其他记录中传播对已连接的用户缓存的信息的任何更改的责任。请注意，您需要接受某种程度的最终一致性。另一方面，在概要文件加载期间查询用户数据将为您提供对这些集合执行响应性本地查询所需的一切。如果最终用户的卷太大，则可能需要对其集合进行特殊处理，并为这些集合发出网络请求

请考虑，除非您预期很快会出现相当极端的扩展，否则所有这些实践和模式的成本可能远远大于您目前承诺的价值

---

随着新的解决方案和工具的创建，这个答案可能会过时。更具体地说，正在开发和分离用于自动化通用物化和一致性管理协议的工具。

我建议您使用选项2，其中所有密钥将出现在一个文档中

MongoDB建议采用模式设计，将所有数据嵌入到单个文档中。他们声称，与关系映射方法相比，这将减少对DB的读写操作，加快CRUD操作

但是，这里有一个陷阱。仅当关系为

一对一

、

一对少

或

一对多

时，数据才应嵌入到单个文档中

如果您的数据映射关系是

1到Squillions

我建议您阅读

我不建议选项1单独收集的原因是，对于每个收集链接，您必须向DB发出更多请求。尽管

$lookup

阶段速度很快，但与嵌入方法相比，它的效率并不高

就选项3而言，这是一种可行的方法（如果您正确有效地使用事务），但它增加了编码方面的复杂性

我个人使用了Option-1和Option-2两种方法，Option-1总是让AWS-EC2实例运行MongoDB，以提高CPU和RAM的使用率。就选项2而言，我有一个集合，它几乎有1000个数组元素（索引键），每个记录中有15K个键（我不是开玩笑的），MongoDB在处理它时没有问题。只要确保在任何地方都使用返回文档的投影即可

因此，选择选项2作为标准方法，选择选项3作为

One-to-Squillions

关系映射

对于引用两个或多个集合，请确保使用MongoDB生成的

ObjectId

，而不是您自己的自定义引用，因为使用ObjectId以外的多文档关系映射会对性能产生轻微影响（即使该特定键已被索引）

---

希望这有帮助。如果您有其他疑问，请联系我

DocumentDB不是MongoDB-您实际使用的是哪一个？您使用的是mongoosejs吗？@AsyaKamsky谢谢，我更新了问题。我正在使用MongoDB。@HenriqueVanKlaveren-是的。我使用Mongoose作为LoopbackJS的一部分。你知道Mongoose autopopulate吗？也许这能帮你。