Производительность межкластерного поиска ElasticSearch с агрегацией

Question

Я создаю мультитенантное приложение Java.Учитывая довольно маленький размер арендатора 100, я начал думать, как масштабировать вещи.В моем приложении у каждого арендатора есть список товаров.Каждый арендатор может импортировать продукты из основного ОГРОМНОГО списка из 1 млн записей.

Итак, если каждый арендатор импортирует все продукты, у меня будет индекс ES из 100 млн документов.Каждый документ имеет 30 полей.

Поскольку этот огромный список продуктов одинаков для всех арендаторов, я решил не дублировать данные для каждого арендатора, а иметь центральный индекс с 1 миллионом продуктов для непосредственного запроса.

Итак, в итоге у меня будет:

1. Один кластер для основного центрального списка продуктов
2. Один или несколько кластеров для индексов арендаторов

Когдаарендатор хочет найти продукт, будет выполнен межкластерный запрос (https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cross-cluster-search.html), чтобы найти «на лету» все продукты из основного индекса + продукты из индекса арендатора.

Фактически, когдаарендатор хочет отредактировать продукт из основного индекса, этот продукт также копируется в индекс арендатора.

Таким образом, здесь возникает другая проблема: мне нужно удалить дубликаты (измененный продукт остается тем же из основногоиндекс только с некоторыми изменениями, такими как цена). Как это сделать? Я могу использовать функцию агрегирования, как описано здесь: https://stackoverflow.com/a/29886871/2012635

Итак, наконец, мой вопрос:

1. Является ли моделирование центрального ONE BIG-индекса лучше, чем наличие 100 BIG-индексов?Я должен сэкономить деньги, потому что у меня было бы намного меньше данных.
2. Является ли межкластерный запрос слишком дорогим для выполнения, учитывая, что я также должен использовать агрегацию для удаления дубликатов?
3. Есть лилучший подход больше подходит для моих требований?

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

{
  "bool" : {
    "filter" : [     
      {
        "bool" : {
          "must" : [
            {
              "bool" : {
                "must" : [
                  {
                    "range" : {
                      "sphereMin" : {
                        "from" : "-17",
                        "to" : null,
                        "include_lower" : true,
                        "include_upper" : true,
                        "boost" : 1.0
                      }
                    }
                  },
                  {
                    "range" : {
                      "sphereMax" : {
                        "from" : null,
                        "to" : "5",
                        "include_lower" : true,
                        "include_upper" : true,
                        "boost" : 1.0
                      }
                    }
                  }
                ],
                "adjust_pure_negative" : true,
                "boost" : 1.0
              }
            }
          ],
          "should" : [
            {
              "range" : {
                "sphereMin" : {
                  "from" : null,
                  "to" : "-17",
                  "include_lower" : true,
                  "include_upper" : true,
                  "boost" : 1.0
                }
              }
            }
          ],
          "adjust_pure_negative" : true,
          "boost" : 1.0
        }
      },
      {
        "bool" : {
          "must" : [
            {
              "bool" : {
                "must" : [
                  {
                    "range" : {
                      "sphereMax" : {
                        "from" : "-17",
                        "to" : null,
                        "include_lower" : true,
                        "include_upper" : true,
                        "boost" : 1.0
                      }
                    }
                  },
                  {
                    "range" : {
                      "sphereMax" : {
                        "from" : null,
                        "to" : "5",
                        "include_lower" : true,
                        "include_upper" : true,
                        "boost" : 1.0
                      }
                    }
                  }
                ],
                "adjust_pure_negative" : true,
                "boost" : 1.0
              }
            }
          ],
          "should" : [
            {
              "range" : {
                "sphereMax" : {
                  "from" : "5",
                  "to" : null,
                  "include_lower" : true,
                  "include_upper" : true,
                  "boost" : 1.0
                }
              }
            }
          ],
          "adjust_pure_negative" : true,
          "boost" : 1.0
        }
      }
    ],
    "adjust_pure_negative" : true,
    "boost" : 1.0
  }
}

У меня также есть несколько агрегатов и matchQuery для edge_ngramфильтр.

Answer 1

100 м не так велико, зависит от доступных ресурсов, требований к времени ожидания и т. Д.Непонятно, зачем вам нужны отдельные кластеры (и межкластерный поиск), что, по-видимому, лучше подходит для поиска по нескольким индексам или для псевдонимов.Еще одна вещь, которая не ясна, - это необходимость включить в поисковый запрос исходный индекс продукта, а затем обработать дубликаты.

Чтобы ответить на ваши вопросы:

Является ли центральное моделирование ONE BIG индексалучше, чем 100 больших индексов?Я должен сэкономить деньги, потому что у меня было бы намного меньше данных.

100 индексов дают вам больше гибкости для масштабирования и запросов.

Является ли межкластерный запрос слишком дорогим дляВы считаете, что я также должен использовать агрегацию для удаления дубликатов?

Слишком дешево или слишком дорого - это зависит.Если все отфильтровано и только несколько документов соответствуют запросу, то дедупликация «дешевая».Но, опять же, лучше

Есть ли лучший подход, более подходящий для моих требований?

Если 100 арендаторов (или 100 м документов) не ваш предел, и вы хотитемасштабировать горизонтально, тогда имея отдельные индексы - лучший подход.Использование одного большого индекса потребует повторного разделения при каждом достижении пределов вертикального масштабирования.