限制 mongodb 集合中的文档数量，没有 FIFO 策略答案

【问题标题】：Limit the number of documents in a mongodb collection , without FIFO policy限制 mongodb 集合中的文档数量，没有 FIFO 策略
【发布时间】：2013-04-04 13:56:26
【问题描述】：

我正在构建一个应用程序来处理门票销售，并且预计会有非常高的需求。我想尝试将 MongoDB 与服务于 node.js 网站的多个并发客户端节点一起使用（并优雅地处理客户端故障）。

我读过“Limit the number of documents in a collection in mongodb”（完全不相关）和“Is there a way to limit the number of records in certain collection”（但那是关于有上限的集合，新文档会覆盖最旧的文档）。

是否可以将集合中的文档数量限制为某个最大大小，并让超过该限制的文档被拒绝。简单的例子是将门票销售添加到数据库中，如果所有门票都已售罄，则失败。

我考虑拥有一个 NumberRemaining 文档，我可以自动递减该文档，直到它达到 0，但如果节点在递减该数字和保存票证购买之间崩溃，我就会遇到问题。

【问题讨论】：

票的数量（存储为ticket id）是否会超过单个 MongoDB 文档的最大大小（16MB）？您一次只能自动设置一个文档（因此可能只需将成功的票务交易存储在一个文档中）。 MongoDB 通常不适合您所描述的多文档事务系统，但 10gen 有一个可行的模式：docs.mongodb.org/manual/tutorial/perform-two-phase-commits
这其实是个好建议，一个单据可以支持大约200万张门票销售。唯一的问题是一张唱片有多“热”，它会成为一个轻微的性能瓶颈，但这可能是一个好计划。然后，我可以单独存储文档（并在尝试将它们添加到成功票证列表之前添加它们）。
如果您将其添加为答案，我会将其标记为已接受
如果你想在这里售票的原子性，那么瓶颈将存在于表/集合级别或文档级别，因为该文档将在内存中，所以在文档级别更容易。

标签： mongodb

【解决方案1】：

将票证存储在单个 MongoDB 文档中。由于您一次只能以原子方式设置一个文档，因此您不应该遇到可以通过使用传统事务数据库系统解决的文档依赖性问题。

由于文档最大可达 16MB，通过在主文档中仅存储 ticket_id，您应该能够存储大量票证，而无需进行任何额外复杂的文档管理。虽然它可能会引入一个热点，但该文档可能不会很大。如果它确实变大，您可以使用多个文档（通过将它们拆分为多个文档作为一个文档“填充”，激活另一个文档）。

如果这不起作用，10gen 有一个可能适合的pattern。

【讨论】：

2 阶段提交不是原子的，因此售出的票数仍然比可用票数多的可能性很小。
两阶段提交选项是伪原子的，因为它总是可以通过常规清理作业返回到一致状态。
@ForbesLindesay 确保工作本身是一致的，没有任何超过应用程序级别的东西可以确保，数据库端没有级别隔离等来知道这一点，有效地不会过度销售票务性能你必须在销售结束后回来，仔细检查谁有票，谁没有
一旦两阶段提交终止，它就会完成，只是有时事务会启动，然后必须回滚。

【解决方案2】：

到目前为止我唯一的解决方案（我希望有人可以改进）：

在文档到达时将其插入到无上限的集合中。保留 ObjectID 的隐含 _id 值，该值可以排序，因此将按照添加文档的时间对文档进行排序。

运行按_id 排序的所有查询，并限制在最大文档数内。

要确定插入是否“成功”，请运行附加查询，检查新插入的文档是否在最大文档数内。

【讨论】：

【解决方案3】：

我的解决方案是：我在另一个集合中使用了一个额外的计数变量。此集合有一个验证规则，可避免计数变量变为负数。计数变量应始终为非负整数。

"count": { "$gte": 0 }

算法很简单。将计数减一。如果成功插入文档。如果失败，则表示没有剩余空间。

删除反之亦然。

您还可以使用事务来防止失败（计数减少但服务在插入操作之前失败）。

【讨论】：