一个大项目上的MongoDB方案

我们最近开始在一个大项目中工作，并决定使用MongoDB作为DDBB解决方案

我们编写了很多代码，但是项目已经开始增长，我们发现我们正在尝试使用

join

s，而不是使用

NoSQL

的方式，这意味着一个糟糕的DDBB设计

我想问的是我们项目的一个好设计，在这一点上包括以下内容：

• 超过12000种产品
• 超过2000名卖家

每个卖家都应该有自己的私人区域，允许根据+12.000“产品模板列表”创建产品目录

卖方应该能够设定价格、库存和报价，然后这些信息将只反映在其公共产品清单中。产品的模板列表将保持不变

目前我们有两个系列。一个用于产品（保存一般产品信息，如名称、说明、照片等），另一个用于我们存储文档的集合，其中包含第一个集合中的产品ID，一个与卖家以及库存、价格和报价相关的ID

我们使用

aggregate

和

$lookup

来“模拟”SQL的左连接来合并这两个集合，但是这个过程并没有像我们希望的那样扩展，我们遇到了严重的性能问题

---

我们知道在NoSQL中使用连接不是一种好方法。我们该怎么办？我们应该如何重构DDBB设计？我们是否应该在每个文档中嵌入每个卖家的价格、报价和库存？

使用“嵌入文档”或“两个或多个不同集合之间的联接”的决定应取决于您将如何检索数据。如果每次在获取产品时，您都将获取卖家，因此，将其作为一个嵌入式文档而不是不同的集合是有意义的。但是，如果您计划分别获取这两个实体，那么您唯一的选择就是使用Join。

为什么要使用mongo？我们在开始项目之前开了一个会，决定MongoDB可以给我们带来比demage更多的好处。12K产品和2K卖家只是一个演示数据，未来可能会有数百万。关系数据库能够有效地管理数十亿行，而不仅仅是数百万行…@Renzo嗯，你甚至可以成功地将Redis用于应用程序或平面文件。这并不是一个好的选择。考虑到大多数RDBMS的可扩展性和故障切换能力，我们可以在很长一段时间内争论任何关系数据库是否真的是一个好的选择。@Nache请提供示例文档。