MongoDB 带有数组的大文档 VS 小而多的文档

Question

我们有一个送餐应用。我们使用 MySQL，但我们现在正在迁移到 MongoDB。

我们有这样的表格：餐厅、菜单、订单等......

要迁移 MongoDB，我对如何为“菜单”集合设计架构感到困惑

选项 1) 与 MySQL 使用相同的方式，'menus' 集合将有很多来自不同餐厅的菜单（文档）

选项 2) 每个商店将在“菜单”集合中拥有一个文档，将他们的菜单嵌入到他们的文档中

总而言之，哪一个最适合 MongoDb？ 20000 个小文档与 100 个文档，每个文档包含 100 或 200 个数组/对象。 我问的是性能，如果这个应用程序随着数十家新餐厅的发展而增长

每个菜单文档几乎是 256 字节，为了计算，我们可以很容易地说每个商店的菜单在 50 到 200 之间。（所以我们不会超过 MongoDB 的 16MB 文档限制）

此外，我们需要在两个不同的页面上使用应用程序内的“菜单”，第一个：20 种来自不同餐厅的适合您附近位置的最佳食物，第二个：每个商店都有自己的页面和自己的菜单。

注意：当餐厅添加所有菜单时，他们的菜单至少在 6-8 个月内保持 98% 不变。除了价格或小细节外，他们不会轻易修改/编辑或更改。

Answer 1

在 MongoDB 中，您将数据存储为您以后想要读取的格式。

所以你需要分析你的用例：

• 20 种来自不同餐厅的最佳美食，适合您附近的位置
• 每个商店都有自己的页面和自己的菜单。

我不确定第一个用例，但看起来您总是要先过滤餐厅（位置），所以在这种情况下，将菜单项与餐厅一起存储。

如果您想直接过滤菜单项，您可以将它们存储在具有专用索引的单独集合中。在您的情况下，如果您将地理位置添加（非规范化）到每个不同的菜单项，这也可以工作。

您也可以同时做到：将菜单项存储在餐厅文档中并作为单独的文档。