ElasticSearch search perfomance

Question

У нас есть кластер из двух узлов (VM в частном облаке, 64 ГБ оперативной памяти, 8 основных процессоров для каждого узла, CentOS), несколько небольших индексов (~ 1 млн. Документов) и один большой индекс с ~ 220 мил docs (2 осколка, 170 ГБ пространства). 24 ГБ памяти выделяется для упругого поиска на каждом ящике.

Структура документа:

{ 
     'article_id': { 
      'index': 'not_analyzed', 
      'store': 'yes', 
      'type': 'long' 
     }, 
     'feed_id': { 
      'index': 'not_analyzed', 
      'store': 'yes', 
      'type': 'string' 
     }, 
     'title': { 
      'index': 'analyzed', 
      'type': 'string' 
     }, 
     'content': { 
      'index': 'analyzed', 
      'type': 'string' 
     }, 
     'lang': { 
      'index': 'not_analyzed', 
      'type': 'string' 
     } 
    } 

занимает около 1-2 секунд, чтобы выполнить следующий запрос:

{ 
    "query" : { 
     "multi_match" : { 
      "query" : "some search term", 
      "fields" : [ "title", "content" ], 
      "type": "phrase_prefix" 
     } 
    }, 
    "size": 20, 
    "fields" :["article_id", "feed_id"] 
} 

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

Заранее благодарен!

Answer 1

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

Макс Expansions

Первое, что я хотел бы сделать это предел max_expansions. Как работает префикс-запрос, создается список префиксов, соответствующих последнему токену в вашем запросе. В вашем поисковом запросе «какой-то поисковый запрос» последний токен «термин» будет расширен с использованием «term» в качестве префиксного семени. Вы можете создать список, как это:

• термин
• термины
• прекратить
• терминатор
• термитов

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

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

Если ограничить процесс расширения, чтобы что-то разумное, вы можете поддерживать скорость и до сих пор, как правило, получить хорошее соответствие префиксов:

{ 
    "query" : { 
     "multi_match" : { 
      "query" : "some search term", 
      "fields" : [ "title", "content" ], 
      "type": "phrase_prefix", 
      "max_expansions" : 100 
     } 
    }, 
    "size": 20, 
    "fields" :["article_id", "feed_id"], 

} 

Вы должны играть с сколько расширений вы хотите. Это компромисс между скоростью и отзывом.

Фильтрация

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

В конце дня, чем меньше документов будет оцениваться запрос, тем быстрее будет выполняться запрос.Фильтры уменьшают количество документов, которые будут видеть запросы, кэшируются, работают очень быстро и т. Д.

В вашей ситуации могут не быть применимых фильтров, но если это так, они могут действительно помочь!

файловой системы Кэширование

Этот совет полностью зависит от остальной части системы. Если вы не полностью используете свою кучу (24gb), потому что вы выполняете простой поиск и фильтрацию (например, не факел/гео/тяжелые сорта/сценарии), вы можете перераспределить свою кучу в кеш файловой системы.

Например, если максимальное использование кучи достигает 12 ГБ, может иметь смысл уменьшить размер кучи до 15 гб. Дополнительные 10gb, которые вы освободили, вернутся в ОС и помогут сегменты кеша, что поможет повысить производительность поиска просто из-за того, что больше операций бездисковых.