Elasticsearch 多索引查询和过滤答案

【问题标题】：Elasticsearch Multi Index Query and FilterElasticsearch 多索引查询和过滤
【发布时间】：2020-08-08 13:29:27
【问题描述】：

我有 2 个索引，一个存储有关事件的数据，另一个存储该事件的可用性。我正在尝试创建一个通过查询获取事件但仅返回可用事件的单个查询，但我在这样做时遇到了困难。

事件索引存储

{
  "id" : "152ce52d-e975-4ebd-849a-0a12f535e644",
  "createdAt" : 1.5519999143126902E12,
  "description" : "A very not so concise description",
  "geoHash" : "dnh00x6x5",
  "name" : "a name",
  ...etc...
}

可用性索引存储可用性如下：

{
  "eventId" : "152ce52d-e975-4ebd-849a-0a12f535e644",
  "maxGuests" : 8,
  "availability" : {
    "lte" : "2019-10-18T22:15:00.000Z",
    "gte" : "2019-10-18T02:30:00.000Z"
  }
}

我正在尝试创建如下所示的查询，但我不知道如何通过满足事件索引中的条件并且在可用性索引中可用的列表进行过滤。

GET events,availability/_search
{
  "size": 5,
  "from": 0,
  "_source": [
      "id"
  ],
  "query": {
    "bool": {
      "must": [
        {
          "geo_distance": {
            "distance": "25mi",
            "geoHash": {
              "lat": 34.0389,
              "lon": -84.3826
            }
          }
        }
      ],
      "should": [],
      "filter":[               
        {
          "range" : {
            "availability" : { 
              "gte" : "2019-10-31",
              "lte" : "2020-11-01",
              "relation" : "within" 
            }
          }
        }
      ]
    }
  }
}

我只想做一个查询的原因是客户端期望特定数量的事件。如果我在获取事件数据后过滤掉不可用的事件，那么我可能会得到比客户预期更少的事件，并且需要再次搜索以填补空白。

当然，我也可以合并这两个索引，以便事件也存储可用性信息，但我最初是这样设置的，因为可用性信息每个事件可能有数百或数千个条目。

【问题讨论】：

标签： elasticsearch elasticsearch-dsl elasticsearch-query

【解决方案1】：

你想要完成的是相当于 SQL 的外键（join）。没有办法得到你想要的，这意味着通过查询索引 B 来过滤索引 A 中的文档。你的选择是：

正如您所提到的，在应用程序级别解决它（尽管这会给您带来其他问题，所以它不是解决方案）。
将数据合并到一个索引中并具有重复的事件信息。虽然看起来很昂贵，但 NoSQL 数据库中的数据重复是可以预料的。如果您需要关系模型，那么也许您应该使用 SQL 解决方案。
使用parent/child (join datatype)。这里的问题是您需要将数据放在同一个索引中。此外，父子节点也将存储在同一个分片中。

我认为对您有用的一种方法（虽然有点复杂）是使用nested datatype，这实际上是解决方案 2 的一种更紧凑的方法（将您的数据组合到一个索引中，但只保存一次根信息）。使事件成为根，可用性显示为嵌套。当您想添加一个可用性时，您可以使用update api，当您查询时，您可以按根字段和嵌套字段进行搜索。如果您需要检索某个事件的特定可用性条目，您可以使用inner hits

您正在尝试执行的操作（多索引搜索）不会自动加入您的数据，它不会起作用。 Elasticsearch 不是这样工作的，关系模型也不适合这个产品。

最后一件事，提前计划是件好事，但尝试optimize early on是件坏事。

真正的问题是程序员在错误的地方和错误的时间花费了太多时间来担心效率；过早的优化是编程中万恶之源（或至少是大部分）。

An interesting read总结以上内容

【讨论】：