elasticsearch - Elasticsearch多索引查询和过滤

Question

我有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" 
            }
          }
        }
      ]
    }
  }
}

-

我只想执行一个查询的原因是客户端期望特定数量的事件。如果我在获取事件数据后滤除了不可用的事件，那么我留下的事件可能少于客户端预期的事件，因此需要再次进行搜索以填补空白。

另外，当然，我可以合并两个索引，以便事件也存储可用性信息，但是我最初是用这种方式设置它们的，因为可用性信息每个事件可能有成百上千个条目。

Answer 1

您想要完成的是等效于SQL(联接)的外键。无法完全满足您的需求，这意味着通过查询索引B从索引A筛选文档。您的选择是:

正如您提到的，在应用程序级别解决它(尽管这会给您带来其他问题，所以这不是解决方案)。

将数据合并到一个索引中，并复制了事件信息。尽管看起来很昂贵，但是可以预期NoSQL数据库中的数据重复。如果需要关系模型，那么也许应该使用SQL解决方案。

使用parent/child (join datatype)。这里的问题是，您将需要整体上将数据包含在相同的索引中。而且， parent 和 child 也将存储在同一分片中。

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

您尝试执行的操作(多索引搜索)将不会自动加入您的数据，这将无法正常工作。 Elasticsearch不能那样工作，并且关系模型不适用于该产品。

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

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

An interesting read总结了以上内容