【问题标题】:MongoDB - Design efficient way to calculate resultMongoDB - 设计计算结果的有效方法
【发布时间】:2020-07-06 01:07:43
【问题描述】:

我正在使用 Java、Spring-Boot 和 db 一个 mongodb。在 mongo 我有 human 集合结构,如

{
  "_id": {
    "$oid": "5eaf79f4bce37709f84f6b03"
  },
  "claimNo": 123
  "xrays": [
    "xray1",
    "xray2",
    "xray3"
  ],
  "xray_details": {
    "xray1": {},
    "xray2": {},
    "xray3": {},
  },
  "claimResult": "A"
}

xrays 对象包含 X 射线的名称。 xray_details 包含有关每个 X 射线的详细信息。 所以就像我们最初创建这个文档一样; xray_detailsclaimResult 不包含任何信息。我们一准备好就会得到信息,例如对于 xray2,我们可能会获得一些信息,但对于 xray3 和 xray1,我们可能会在 15 分钟后获得信息。我们需要做的是,一旦我们有了一些信息,我们就需要计算和更新claimResult

详细说明:xray_details 中,我们获得xray2 的信息,但xray1xray3 不可用,然后我们只考虑xray2 并更新claimResult。一旦我们得到一些其他的 X 射线信息,即xray1,那么我们将使用xray1xray2 来计算claimResult,稍后我们会得到xray3,然后我们需要再次检查/确认我们是否已经有信息可以使用xray1xray2xray3 来计算claimResult

问题: 在这个阶段,我们正在制作一个调度程序来计算结果,但这效率不高,我们需要它,一旦信息可用,我们就会考虑先前完成的信息并再次计算结果。不知道像 kafka 这样的解决方案是否可以在这种情况下工作,但请随时提供您对此的宝贵反馈/建议。谢谢!

【问题讨论】:

    标签: java spring mongodb design-patterns architecture


    【解决方案1】:

    正如你提到的,调度器在这里效率不高。

    为什么调度器不是最好的:


    1. 在没有变化的情况下可能需要低效地轮询细节
    2. 当它轮询效率低下时,它将影响数据库上的其他未决请求。

    什么是最好的:


    正如您所怀疑的,Kafka 是最合适的。我更喜欢 Kafka 而不是其他消息传递系统,因为 Kafka 是 durable,并且您可以在单个消费者组中拥有多个消费者 process the messages in parallel

    每当输入新条目时,都会向 Kafka 主题发布消息。将您的调度程序应用程序逻辑转换为消息驱动。新消息发布时会自动处理。


    假设 Application1,2,3 插入这些 xray1,2,3 细节。这里的问题是claimResult的计算。因此,当应用程序更新这些 X 射线详细信息时,它必须生成一条消息。

    消费者应选择该消息并计算 claimResult 并更新它。

    【讨论】:

    • 我们可以做的另一件事是使用 mongo 触发器,但不知何故,我们发现它并不耐用,因为大多数时候它根本没有触发或因任何原因而失败。对于 Kafka,我相信它可能会成为一个有点复杂的解决方案,但无论如何我想听听,所以你能更详细地解释一下吗?谢谢!
    • 当然。您想了解更多卡夫卡的哪一部分?生产者/消费者/基础设施? @iCurious
    • 我对 Kafka 不是很熟悉,但如果你能提供简要的解决方案设计,那么我可以弄清楚其余的。只是为了更好地理解应用程序是消息驱动的,因此应用程序侦听主题并插入数据库。然后其他消费者收听其他主题,并在获取详细信息时更新文档
    • 哦,我没有收到任何通知。谢谢!这似乎很有趣。目前我们正在研究一个临时解决方案,但我会检查一下并分享更多细节。谢谢!
    • 临时解决方案是什么?你能解释一下吗?如果我的回答对您有帮助,您是否也可以批准/赞成/两者兼而有之。
    猜你喜欢
    • 2011-04-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多