Как получить количество на основе фильтра через серверную часть - PullRequest
1 голос
/ 21 июня 2020

Предположим, у нас есть довольно большая база данных продуктов, например, для мобильного телефона 50K. Эти данные мы храним в Elasti c Search. Теперь у меня есть страница со списком товаров для мобильных телефонов, на которой я перечисляю все 10 мобильных телефонов за раз, используя разбиение на страницы с их базовыми c деталями. На этой странице также есть раздел фильтров, таких как Марка, Диапазон цен, RAM, Avg. Рейтинг, дата выпуска и многие другие характеристики.

Теперь, когда я получаю данные для мобильного телефона компании Samsung и 6 ГБ оперативной памяти, я запускаю запрос elasti c и получаю результаты и их общее количество. Итак, здесь запрос подсчета становится сложным. Общее количество зависит от фильтра, и этот тип запроса увеличивает нагрузку на систему.

Мне нужна система, которая будет вычислять количество фильтров один раз и сохранять его где-нибудь, поэтому я не необходимо снова вычислить количество для одного и того же фильтра, что снова и снова снижает сложность одних и тех же фильтров. Сообщите мне свои знания. Как я могу решить эту проблему или как мне поддерживать свою систему?

Любые ссылки или статьи также приветствуются.

Ответы [ 3 ]

0 голосов
/ 21 июня 2020

Elasti c search предоставляет свои собственные методы кэширования, и вы можете использовать эти настройки для кэширования определенного c запроса

GET /my_index/_search?request_cache=true
{
  "size": 0,
  "aggs": {
    "popular_colors": {
      "terms": {
        "field": "colors"
      }
    }
  }
}

Вот ссылка для получения дополнительных сведений. Имейте в виду, что у вас столько аппаратной конфигурации для кеширования elasticsearch. https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-request-cache.html#_enabling_and_disabling_caching_per_request.

Также, если у вас несколько узлов данных, и есть несколько индексов, по которым часто выполняются запросы и агрегирование, и у вас разные аппаратные конфигурации разных узлов, тогда вам следует изучить концепцию горячих и холодных узлов elasticsearch и поместить индексы imp в горячие узлы вместо кеширования всего

https://www.elastic.co/blog/hot-warm-architecture-in-elasticsearch-5-x

https://www.elastic.co/blog/implementing-hot-warm-cold-in-elasticsearch-with-index-lifecycle-management

0 голосов
/ 27 июня 2020

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

0 голосов
/ 21 июня 2020

Не могли бы вы обновить вышеупомянутое сообщение образцом сложного запроса подсчета, который вы используете? Было бы полезно определить проблему, с которой вы столкнулись. Спасибо!

...