4

我想在 Mongo 中实现一个作业队列。整个软件系统都是基于 Mongo 的，所以它看起来很自然并且可能很合适。

作业集合将每个作业状态存储为一个文档。我想这是一个基于我的查询需求的无上限集合。工作文件如下所示：

{
    "_id" : ObjectId("50a6742ee4b0a9a1c2cb4fd4"),
    "type" : "archive_job",
    "state" : 2,
    "priority" : 1,
    "timing" : {
        "submitted": ISODate(...),
        "running": ISODate(...),
        "completed": ISODate(...),
        "failed": null,
        "cancelled": null
    },
    payload: {
       ...job-specific JSON...
    }
}

作业集合的典型访问模式将是：

  • 根据类型、状态、优先级和可能的范围查询来查找要执行的未处理作业的时间。提交大于上一次读取时间
  • 查找所有已处理（完成、失败、取消）的作业
  • 查找所有未处理（已提交、正在运行）的作业
  • 通过 _id 查找特定作业并检索其有效负载（当状态正在运行时）

大部分查询将查找需要执行的未处理作业。将有效负载移动到jobs_payload集合是否值得，以便文档大小在作业集合中变化不大？

与未处理的作业相比，大量已处理（已完成、失败、取消）的作业最终会增加作业集合所需的工作集内存吗？即使使用正确的索引，执行未处理作业的访问时间会变慢吗？

我可以通过模式设计做出哪些替代方案和权衡取舍？

4

1 回答 1

-1

将有效负载移动到 jobs_payload 集合是否值得，以便文档大小在作业集合中变化不大？

通常嵌入是 mongodb 中的正确方法，在您的情况下它看起来不错。

与未处理的作业相比，大量已处理（已完成、失败、取消）的作业最终会增加作业集合所需的工作集内存吗？即使使用正确的索引，执行未处理作业的访问时间会变慢吗？

虽然数据库适合内存减速不会被注意到。

您的架构看起来不错。例如，您可以查看celery（具有 mongodb 后端）模式。

于 2012-11-17T20:49:58.830 回答