Скорость поиска - главное достоинство OpenSearch. Чаще всего именно из-за нее люди решают использовать OpenSearch в первую очередь, поэтому очень важно обеспечить быстрое получение результатов.
Оптимизируя и поддерживая скорость поиска в OpenSearch, вы можете улучшить пользовательский опыт и, в свою очередь, повысить конверсию вашего продукта.
В этой статье мы подробно расскажем, как увеличить скорость OpenSearch за счет оптимизации запросов и настроек OpenSearch.
Как обнаружить медлительность в OpenSearch
Прежде чем мы узнаем, как увеличить скорость поиска в OpenSearch, необходимо рассказать о том, как обнаружить медлительность в OpenSearch. Вот несколько различных способов, с помощью которых вы можете это сделать:
Использование медленных журналов
OpenSearch предоставляет очень удобную функцию, называемую медленными журналами. При правильной настройке OpenSearch будет печатать все медленные запросы, которые вы можете отладить, чтобы вы могли улучшить эти конкретные запросы. Вы можете настроить медленные журналы на уровне индекса или на уровне OpenSerch.
Чтобы настроить его на уровне индекса:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | curl --request PUT \ --url http://localhost:9200/search-speed \ --header 'Content-Type: application/json' \ --data '{ "settings": { "index.search.slowlog.threshold.query.warn": "10s", "index.search.slowlog.threshold.query.info": "5s", "index.search.slowlog.threshold.query.debug": "2s", "index.search.slowlog.threshold.query.trace": "500ms", "index.search.slowlog.threshold.fetch.warn": "1s", "index.search.slowlog.threshold.fetch.info": "800ms", "index.search.slowlog.threshold.fetch.debug": "500ms", "index.search.slowlog.threshold.fetch.trace": "200ms", "index.search.slowlog.level": "info" } }' |
Чтобы настроить его на уровне OpenSearch, вы можете изменить свойства:
| 1 2 3 4 5 6 7 8 9 10 | index.search.slowlog.threshold.query.warn: 10s index.search.slowlog.threshold.query.info: 5s index.search.slowlog.threshold.query.debug: 2s index.search.slowlog.threshold.query.trace: 500ms index.search.slowlog.threshold.fetch.warn: 1s index.search.slowlog.threshold.fetch.info: 800ms index.search.slowlog.threshold.fetch.debug: 500ms index.search.slowlog.threshold.fetch.trace: 200ms index.search.slowlog.level: info |
Если вы хотите узнать больше о медленных журналах, вы можете ознакомиться с нашей статьей о том, как правильно настроить медленные журналы.
Оптимизация запросов
Оптимизация запросов - это одна из мер, которую вы можете предпринять для повышения производительности поиска в OpenSerch. Плохой запрос, который собирает больше результатов документов, чем нужно, снижает скорость поиска.
Не ставьте большое число в параметр size
Параметр size в OpenSerch определяет, сколько документов OpenSerch будет возвращать в ответах. Большое значение параметра size снизит скорость поиска, так как OpenSearch придется создавать большое количество документов. Кроме того, задержка передачи данных между OpenSearch и клиентом также снизит скорость поиска.
Рекомендуется дважды проверить и убедиться, что вы установили значение, соответствующее необходимому количеству документов.
По умолчанию размер запроса составляет 10. Вы можете изменить размер в параметре поиска:
| 1 2 3 | curl --request GET \ --url 'http://localhost:9200/search-speed/_doc/_search?size=100' \ --header 'Content-Type: application/json' |
Получайте только нужные поля
Как и в случае с получением большего количества документов, чем вам нужно, получение слишком большого количества неиспользуемых полей также замедлит скорость поиска. Это происходит по той же причине, о которой мы говорили ранее - OpenSearch придется создавать и передавать клиенту больше документов. Если вы сочетаете большой параметр размера и большое количество полей, то все вместе это значительно снизит скорость поиска.
Поэтому рекомендуется получать только те поля, которые вам действительно нужны.
Существует несколько методов настройки того, какие поля вы хотите получить. Вот несколько методов, которые вы можете использовать:
Использование _source в теле запроса:
| 1 2 3 4 5 6 | curl --request POST \ --url http://localhost:9200/search-speed/_doc/_search \ --header 'Content-Type: application/json' \ --data '{ "_source":["name"] }' |
Использование "fields" в теле запроса и отключение _source:
| 1 2 3 4 5 6 7 8 9 10 | curl --request POST \ --url http://localhost:9200/search-speed/_doc/_search \ --header 'Content-Type: application/json' \ --data '{ "fields": [ "name", "description" ], "_source": false }' |
Обратите внимание, что результат поиска при использовании этого метода будет отличаться, вам нужно будет получить значение документов в полях вместо _source:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 | { "took": 2, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 2, "relation": "eq" }, "max_score": 1.0, "hits": [ { "_index": "search-speed", "_type": "_doc", "_id": "r2cy4HUB4Qqjzh5nmZLw", "_score": 1.0, "fields": { "name": [ "hello" ], "description": [ "world" ] } }, { "_index": "search-speed", "_type": "_doc", "_id": "sGc14HUB4Qqjzh5n6JJx", "_score": 1.0, "fields": { "name": [ "g-soft" ], "description": [ "g-soft" ] } } ] } } |
Doc Value Fields, обратите внимание, что этот метод не поддерживается для типа текстового поля:
| 1 2 3 4 5 6 7 8 | curl --request POST \ --url http://localhost:9200/search-speed/_doc/_search \ --header 'Content-Type: application/json' \ --data '{ "docvalue_fields": [ "name.keyword" ] }' |
Существуют и другие методы, такие как хранимые поля, поля скриптов и поля времени выполнения, но вышеперечисленные являются самыми основными решениями для выбора полей, которые OpenSearch должен возвращать.
Избегайте использования скриптов
Сценарии - это функция в OpenSearch, которая позволяет оценивать пользовательские выражения. Это мощная функция, но она может сильно повлиять на скорость поиска.
Вы должны быть осторожны при использовании скриптов, потому что OpenSearch будет применять скрипт к каждому результату. Чем больше данных в индексе, тем медленнее будет работать поиск, так как он перебирает все результаты.
Избегайте ведущих подстановочных знаков в запросах
Запросы с подстановочными знаками в OpenSerch похожи на запросы LIKE в SQL. Например, если вы запросите *OpenSearch*, запрос получит все результаты, содержащие слово OpenSearch. Настоящая проблема с запросами с подстановочными знаками в OpenSerch заключается в использовании ведущего подстановочного знака, например *OpenSearch.
OpenSerch разработан для эффективного поиска точных лексем. Однако при использовании запроса с ведущим подстановочным знаком OpenSearch не может эффективно выполнять поиск. Когда вы ищете в OpenSearch запрос с ведущим подстановочным символом, запрос должен пройти через весь Инвертированный индекс, чтобы обнаружить, какие термины во всем индексе содержат запрашиваемый термин.
В связи с этим рекомендуется настроить анализатор таким образом, чтобы он поддерживал нужный вам запрос, а не использовать запрос с ведущим подстановочным знаком.
Используйте таймаут при поиске
Медленный запрос использует значительные вычислительные ресурсы, часто блокирует поток и замедляет работу вашего сервера OpenSearch. Чтобы избежать слишком долгого выполнения запросов, OpenSearch предлагает функцию таймаута. Используя функцию таймаута, вы можете остановить запрос, если он слишком долго не завершается. Это очень важная функция, которую необходимо настроить.
Чтобы установить таймаут поиска, вы можете задать его в параметре поиска:
| 1 2 3 4 | curl --request POST \ --url 'http://localhost:9200/search-speed/_doc/_search?timeout=5s' \ --header 'Content-Type: application/json' \ --data '{}' |
Вы также можете задать его в глобальных настройках с помощью этой клавиши:
| 1 | search.default_search_timeout |
Избегайте сложных агрегаций, если они вам не нужны
Агрегации - это мощная функция OpenSearch, которую можно использовать для множества различных целей. Многие люди, особенно в сфере анализа данных, используют OpenSearch только из-за его функции агрегации. Но за использование слишком большого количества агрегаций приходится платить - снижается скорость поиска. Вы должны быть осторожны с агрегациями, особенно если ваш запрос требует быстрой скорости поиска, например автозаполнения.
Настройка параметров OpenSearch
Настраивать параметры OpenSearch всегда непросто. Вы хотите обеспечить высокую доступность, спланировать масштабируемость и добиться отличной производительности поиска, стараясь при этом минимизировать затраты. Кроме того, вам нужно постоянно менять настройки в зависимости от пользователей ваших продуктов. В этом разделе мы рассмотрим советы по настройке, которые вы можете применить к параметрам OpenSearch для повышения производительности поиска.
Заморозка неиспользуемых индексов
Индексы OpenSearch используют память для хранения структуры данных для повышения производительности. Проблема в том, что неиспользуемые индексы все равно будут использовать эту память. Слишком много неиспользуемых индексов будут отнимать память и загромождать ее, замедляя скорость поиска в других индексах. К счастью, вы можете использовать API заморозки OpenSearch, чтобы остановить использование памяти неиспользуемыми индексами. Вы по-прежнему можете искать по замороженному индексу, но учтите, что поиск будет медленнее, потому что индекс больше не использует память.
Чтобы заморозить индекс, вы можете использовать API _freeze:
| 1 2 | curl --request POST \ --url http://localhost:9200/search-speed/_freeze \ |
Увеличение интервала обновления
Если вы уже некоторое время используете OpenSearch, то могли заметить, что вы не можете искать документ сразу после того, как он проиндексирован. Это происходит потому, что перед тем, как документы будут проиндексированы в шард (доступны для поиска), они сначала проходят через буфер в памяти. OpenSearch использует буфер в памяти, потому что при больших процессах индексирования эффективнее сначала хранить маркеры в памяти. Процесс перехода токенов из буфера in-memory в шард называется "обновлением".
Обновление - это очень дорогой процесс, который может снизить производительность шарда, а значит, и производительность поиска. По умолчанию процесс обновления происходит каждые 1 секунду. Уменьшать этот интервал обычно не рекомендуется. Уменьшение интервала обновления означает, что буфер в памяти будет работать неэффективно, поскольку он не сможет хранить много токенов перед индексацией в шард.
Итак, если уменьшение интервала снизит производительность, то как насчет его увеличения? Ну, здесь не все так просто.
Увеличение интервала обновления, как правило, повышает производительность поиска, но нужно быть осторожным. Если вы увеличите интервал обновления слишком сильно, процесс обновления будет тяжелым и займет больше времени, что может навредить производительности поиска, а не улучшить ее. Еще один момент, на который следует обратить внимание при увеличении интервала обновления, - это то, что документ будет дольше становиться доступным для поиска.
Вам придется методом проб и ошибок определить наиболее эффективный интервал обновления для вашей системы. Обычно интервал обновления по умолчанию составляет 1 секунду и вполне подходит для большинства случаев использования.
Интервал обновления можно изменить в настройках индекса:
| 1 2 3 4 5 6 7 8 9 10 | curl --request PUT \ --url http://localhost:9200/search-speed/_settings \ --header 'Content-Type: application/json' \ --data '{ "settings": { "index": { "refresh_interval": "5s" } } }' |
Также вы можете изменить его в настройках OpenSearch с помощью ключа:
| 1 | index.refresh_interval |
Увеличение размера кэша запросов узла
OpenSearch использует кэш запросов узла для кэширования результатов запросов, чтобы быстрее возвращать их при повторном запросе. Кэш реализует политику LRU, поэтому, когда он переполняется, из него удаляются данные, которые использовались в последнее время меньше всего.
Если размер кэша запросов узла слишком мал, часть запроса может быть не кэширована, и из-за этого производительность поиска в OpenSearch может снизиться.
Чтобы изменить размер, вы можете изменить глобальную настройку с помощью этого ключа:
| 1 | indices.queries.cache.size |
Оптимизация шардов и реплик
Осколки и реплики являются частью фундамента OpenSearch. Они отвечают за высокую доступность, масштабируемость и высокую производительность OpenSearch. Шарды и реплики позволяют OpenSearch выполнять поиск одновременно и, следовательно, повышают производительность поиска. Однако при увеличении их количества нужно быть осторожным, так как слишком большое количество шардов и реплик снизит производительность поиска и может привести к остановке сервера OpenSearch.
Увеличение аппаратных ресурсов
Увеличение аппаратных ресурсов - самый очевидный способ повысить производительность. Проблема этого подхода в том, что он очень дорогой. Увеличение аппаратных ресурсов OpenSearch должно быть последним, что вы делаете, когда пытаетесь улучшить производительность OpenSearch, и во многих случаях оно не решит проблемы с задержкой поиска или не улучшит его производительность.