ElasticSearch многоуровневая агрегация родитель-потомок

У меня есть родительская / дочерняя структура на 3 уровнях. Скажем:

Компания -> Сотрудник -> Доступность

Поскольку здесь часто обновляется доступность (а также сотрудник), я предпочитаю использовать родительскую / дочернюю структуру вместо вложенных. И функция поиска работает нормально (все документы в правильных шардах).

Теперь я хочу отсортировать эти результаты. Сортировать их по метаданным компании (1-й уровень) несложно. Но мне нужно отсортировать еще и по 3-му уровню (доступности).

Мне нужен список компаний, отсортированных по:

• Расстояние от местоположения с учетом ASC
• Рейтинг DESC
• Самая быстрая доступность ASC

Например:

Компания A находится в 5 милях, имеет рейтинг 4, и скорее всего один из их сотрудников будет доступен через 20 часов. Компания B также находится в 5 милях, также имеет рейтинг 4, но скорее всего один из их сотрудников будет доступен через 5 часов.

Следовательно, результат сортировки должен быть B, A.

Я хотел бы добавить особый вес к каждому из этих данных, поэтому я начал писать агрегаты, которые позже мог бы использовать в моем скрипте custom_score.

Полная суть для создания индекса, импорта данных и поиска.

Теперь мне удалось написать запрос, который фактически возвращает результат, но корзина агрегирования доступности пуста. Однако я также получаю слишком структурированные результаты, я бы хотел их сгладить.

Сейчас возвращаюсь:

IDS компании -> IDS сотрудника -> первая доступность

Я хотел бы иметь такую ​​агрегацию:

IDS компании -> первая доступность

Таким образом, я могу написать свой custom_scoreсценарий для подсчета очков и их правильной сортировки.

Более упрощенный вопрос:
как можно сортировать / агрегировать по многоуровневым (большим) дочерним элементам и, возможно, сгладить результат.

Для этого вам не нужны агрегаты:

Это критерии сортировки:

1. Расстояние ASC (company.location)
2. Рейтинг DESC (company.rating_value)
3. Скоро в будущем ASC (company.employee.availability.start)

Если вы проигнорируете пункт 3, вы можете выполнить относительно простой запрос компании, например:

GET /companies/company/_search
{
 "query": { "match_all" : {} },
 "sort": {
    "_script": {
        "params": {
            "lat": 51.5186,
            "lon": -0.1347
        },
        "lang": "groovy",
        "type": "number",
        "order": "asc",
        "script": "doc['location'].distanceInMiles(lat,lon)"
    },
    "rating_value": { "order": "desc" }
  }
}

№3 сложен, потому что вам нужно найти доступность ( компания> сотрудник> доступность ) для каждой компании, ближайшей ко времени запроса, и использовать эту продолжительность в качестве третьего критерия сортировки.

Мы собираемся использовать function_scoreзапрос на уровне внуков, чтобы определить разницу во времени между временем запроса и каждой доступностью в обращении _score. (Затем мы будем использовать в _scoreкачестве третьего критерия сортировки).

Чтобы связаться с внуками, нам нужно использовать has_childзапрос внутри has_childзапроса.

Для каждой компании мы хотим, чтобы Сотрудник был доступен как можно скорее (и, конечно, как можно быстрее). Elasticsearch 2,0 даст нам "score_mode": "min"для подобных случаев, но в настоящее время, так как мы ограничены , "score_mode": "max"мы сделаем внук _scoreбыть взаимными из временной разницы.

          "function_score": {
            "filter": { 
              "range": { 
                "start": {
                  "gt": "2014-12-22T10:34:18+01:00"
                } 
              }
            },
            "functions": [
              {
                "script_score": {
                  "lang": "groovy",
                  "params": {
                      "requested": "2014-12-22T10:34:18+01:00",
                      "millisPerHour": 3600000
                   },
                  "script": "1 / ((doc['availability.start'].value - new DateTime(requested).getMillis()) / millisPerHour)"
                }
              }
            ]
          }

Итак, теперь _scoreдля каждого внука ( Доступность ) будет 1 / number-of-hours-until-available(чтобы мы могли использовать максимальное обратное время, пока оно не будет доступно для каждого сотрудника, и максимальное обратное (ли?) Доступное время для сотрудника на компанию).

Собирая все вместе, мы продолжаем запрашивать компанию, но используем команду company> employee> availability, чтобы сгенерировать _scoreдля использования в качестве критерия сортировки # 3 :

GET /companies/company/_search
{
 "query": { 
    "has_child" : {
        "type" : "employee",
        "score_mode" : "max",
        "query": {
          "has_child" : {
            "type" : "availability",
            "score_mode" : "max",
            "query": {
              "function_score": {
                "filter": { 
                  "range": { 
                    "start": {
                      "gt": "2014-12-22T10:34:18+01:00"
                    } 
                  }
                },
                "functions": [
                  {
                    "script_score": {
                      "lang": "groovy",
                      "params": {
                          "requested": "2014-12-22T10:34:18+01:00",
                          "millisPerHour": 3600000
                       },
                      "script": "1/((doc['availability.start'].value - new DateTime(requested).getMillis()) / millisPerHour)"
                    }
                  }
                ]
              }
            }
          }
        }
    }
 },
 "sort": {
  "_script": {
    "params": {
        "lat": 51.5186,
        "lon": -0.1347
    },
    "lang": "groovy",
    "type": "number",
    "order": "asc",
    "script": "doc['location'].distanceInMiles(lat,lon)"
  },
  "rating_value": { "order": "desc" },
  "_score": { "order": "asc" }
 }
}

Вы должны проверить структуру данных R-Tree https://en.wikipedia.org/wiki/R-tree .