Java vs Elasticsearch。把逻辑放在哪里？

例如，我在elasticsearch中有许多项。每个项目都有：

id
name
price
storeConnectionId
regionConnectionId

可以有不同ID但名称相同的项目，我想在搜索中添加一些聚合逻辑

• 如果项目存在于您的地区，我想返回这个项目与该地区的id和价格
• 如果你们地区没有这样的商品，我只想退回最便宜的商品

我在这里看到的解决方案很少：

将整个逻辑置于elasticsearch。创建很棒的聚合和bool查询。只保留一个对elasticsearch的请求

使用两个查询。第一个将返回请求区域的项目，第二个将返回具有最小价格聚合的所有项目

返回搜索中的所有项目，并将此业务逻辑保留在Java中

---

Elasticsearch只应在处理大量项目时运行得更快，但对于Elasticsearch查询来说，这样的逻辑还可以吗？

我认为相关功能的逻辑应该尽可能保持在同一位置。所以，如果你想用Java来完成这一切，就去做吧。但是，如果ES可以帮助您利用某个功能的负担，并且性能不会受到影响，那么您为什么不使用ES呢？这个问题似乎更多地是关于“elasticsearch的整个逻辑”的主题，而查询仍然是您的Java代码（并决定要查询什么内容）。所以这在我的书中仍然是“一个地方”。如果您必须在索引生成中添加额外的逻辑来支持这种查询，那将是另一回事，这将增加“复杂性负担”。但是，仅仅对有机存在的字段充分利用现有的查询功能应该“足够简单”。#1或#2可以，但#3听起来毫无意义。ES毕竟是一个带有查询api的数据库，加上业务逻辑（部分编码为ES查询）在#2中也停留在java端。