Блог

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

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

 {
    "query" : {
        "bool" : {
            "must" : {
                "multi_match" : {
                  "type": "cross_fields",
                  "query":"store related query", 
                  "minimum_should_match": "30%",      
                  "fields": [ "field1^5", "field2^5", "field3^3", "field4^3", "firstLine", "field5", "field6", "field7"] 
                }
            },
            "filter": {
                "term": {
                    "businessKey": "storename"
                }
            }
            
        }
    }
}
  

Этот запрос выполняется массово около 20 миллионов раз в течение нескольких часов. В настоящее время я не могу пройти 21k / мин. Но это может быть связано с различными факторами. Будут оценены любые советы по повышению производительности для такого рода рабочего процесса (загрузка один раз и поиск много).

Однако мне особенно интересно узнать, могу ли я сначала упорядочить данные по бизнес-ключу при индексации, чтобы данные для этого бизнес-ключа находились в одном сегменте Lucene, и, следовательно, поиск был бы быстрее. Правильна ли эта мысль? Это то, что ES уже делает, учитывая, что это ключевое слово?

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

Я вижу, вы уже правильно строите запрос, то есть фильтруете записи на основе businessKey , а не выполняете поиск по оставшимся документам, таким образом, вы уже используете фильтр-кэш elasticsearch.

Поскольку у вас огромное количество документов ~ 40 МЛН документов, не имеет смысла помещать их все в отдельные сегменты, максимальный размер сегмента по умолчанию составляет 5 ГБ, а сверх этого процесс слияния будет заблокирован по сегментам, поэтому для вас практически невозможно иметь только 1 сегмент для ваших данных.

Я думаю, что пара вещей, которые вы можете сделать, это:

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

 GET your-index/_stats/request_cache?human
  

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

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

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

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

Может помочь просмотр ссылок ниже

Настройка для поиска

Настройка для индексации

Оптимизация поиска