作业队列的正确mongo架构设计是什么？

Question

我想在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...
    }
}

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

• 根据 type ， state ， priority 以及 timing.submitted上的范围查询找到要执行的未处理作业大于先前的读取时间
• 查找所有已处理（已完成，已失败，已取消）的作业
• 查找所有未处理（已提交，正在运行）的作业
• 通过_id查找特定作业并检索其有效负载（当状态正在运行时）

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

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

我可以使用架构设计做出哪些替代和权衡？

Answer 1

  

将有效负载移至jobs_payload集合是否值得，因此作业集合中的文档大小差异不大？

通常嵌入是mongodb中的一种正确方法，在你的情况下看起来很好。

  

大量处理（完成，失败，取消）和未处理的作业最终会增加作业集合所需的工作集内存吗？   即使使用正确的索引，未处理作业的访问时间是否会更慢？

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

您的架构看起来没问题。作为示例，您可以查看celery（具有mongodb后端）架构。