MongoDB 架构设计 - 巨大的列表

Question

我想知道在我的 mongoDB 中存储数据的最佳方式是什么，例如餐厅的订单。

所以，首先我需要有一个“订单”集合。

还需要大量阅读以在服务员之间同步数据，因此我不想将已完成（已付款）的订单和仍在同一列表中打开的订单存储。

所以我想出了一个“订单”集合，它有 2 个数组字段：“当前”和“历史”。 目前，我将存储所有仍未付款的订单（需要通过所有服务员同步），在“历史记录”中，我将存储所有已关闭且仅需要由经理或想要查看数据的人访问的订单.

这样我可以最大限度地减少访问时间和发送数据量。

这是一种正确的最佳实践方式吗？

或者我应该将所有内容存储在一个列表中，然后执行按时间或类似排序的查询，并限制我发回的文档数量？

编辑：

在这个集合中，我希望保存多个餐厅的订单。所以我可以在这个集合中为每个餐厅使用一个文档并将订单嵌入其中，或者将这个集合中的所有订单放在同一级别，然后每个订单都有一个 restaurantId

Answer 1

由于订单集合代表一家餐厅，它是否会包含所有订单的记录，每个文档看起来像：

{
    _id:{}
    waiter: 'Sammaye',
    table: 9,
    items: [
        {id:9,qty:1,cooked:false}
    ],
    billed: false
}

所有需要了解等待外出订单的服务员只会从该集合中获取所有具有billedfalse 的订单文档。

如果您在billed 上放置索引，这应该足够了。

使用您所说的另一种方法可能会导致问题，例如它是存储所有订单的集合中的一个文档。我可以想象那个文件会变得非常大。

在内存中使用运算符（$push、$pull 等）可能会使对文档的操作变慢。

它还可能在数据库中产生碎片，因为这些未绑定的数组会随着时间的推移不断增长，这也会降低性能。

与将每个订单存储为记录相比，您的方法也不会产生任何优势，除了您可以一次性获取所有待处理订单，但是，配置批量大小时，您可能会非常接近将所有订单存储为单独的文件。