MongoDB的设计为快速增长的文件

Question

案例：

我正在开发一个POS系统，我需要存储每个交易（产品信息，价格，数量等），每个收银终端。这当然意味着交易文件的数量将会及时增长。

我目前的解决方案是：

有两个集合称为“注册”和“销售”。销售文件有注册编号参考，所以我知道哪些销售文件属于哪个收银机。交易存储在每个销售单据内的数组中（每隔一天约300个新的交易单据）。

为了在更新已经很大的数组时有更好的性能，我在每个销售文档中设计了一个小的'缓存'数组（大约50个文档 - 所以我只更新小数组）完整的，我会将它们移动到主事务数组。

因为MongoDB中文档的最大大小限制为16MB，所以我为销售文档设置了10000个交易的计数限制，并且如果交易数量超过了计数限制，我将创建一个新的销售文档并将他们的id引用存储在寄存器文档的数组中以保留销售文档的订单。

我对这个设计并不满意，因为我必须编写非常复杂的查询来为每个查询检索大约200个事务，以事务处理为了分页以及处理极端情况。

代价：

所以我在考虑一种名为只是“交易”一个非常大的是（不断增长）的收集，在那里我会扔每个收银机的所有交易，以一个桩，然后每笔交易都有自己的注册号参考。

问题：我应该这样做吗？

更新：我怎么需要访问数据：

• 插入和只读，从不更新或删除现有文档
• 插入是最常见的操作
• 阅读查询应该返回一个适合交易号码的文档数组e或在创建时间范围内，阵列不需要排序）
• 阅读：大多数情况下，我只需显示前200个最近的事务。然后用户可以根据需要查询更多信息。

优点：

• 简单的查询（不知道是否有效，虽然），例如通过交易数量/时间范围内找到ID和过滤器的事务，同时查询特定号码的交易
• 避免不必要的重复
• 一步步接近阵列免费的数据库
• 适合切分（？）

缺点：

• 索引过多（这被认为是一个问题，那就没关系，如果有指标的trilions为这些小？文件？）
• 我不知道我做完后会发生什么。理论上，它应该工作。但现实更为残酷的比我们知道它

备注：

• 也许我为什么选择阵列在一个桩收集的主要原因是，我没有用MongoDB的任何经验，当我开始。
• ，是的，我想，以确保该交易，以留

一些视觉效果：

• MongoDB Schema Design

Answer 1

我觉得外侧入路（制造一个大交易集合）更好，如果你想从复杂的查询中拯救自己，并且mongodb可以处理数十亿条记录，如果你使用索引正确管理你的数据库和分片。

您可以检查这个博客帖子为例 - http://blog.mongodb.org/post/79557091037/processing-2-billion-documents-a-day-and-30tb-a

正如你提到的，通常会有没有什么更新和删除这是很好的索引。索引将有助于读取，并且不会太昂贵，因为它们只会在插入时更改。

为什么你在销售数组中有销售数据？在改变你的模型之后，我不会建议你将所有事务ID保存在注册集合中的一个数组中。未绑定的数组在MongoDB中不好。

最后提到的是我个人的建议，并根据我在互联网上的研究。我不是专家，我只是在一家软件公司从事过去两年的mongodb工作。