В настоящее время OpenSearch предоставляет три различные техники для получения большого количества результатов: пагинация, поиск после и прокрутка.
Для каждого случая использования требуется своя техника. В этом руководстве мы рассмотрим все их особенности.
Когда вы создаете поисковое приложение для пользователя или API, использующее OpenSearch, очень важно продумать количество результатов, возвращаемых по одному поисковому запросу.
По умолчанию OpenSearch возвращает первые 10 хитов с помощью пагинации. Если вы хотите показать пользователю более 10 документов, вам необходимо выбрать правильную технику из следующих вариантов.
Пагинация
По умолчанию для получения большого количества результатов в OpenSearch используется механизм пагинации.
Когда вы посылаете запрос в OpenSearch, он всегда будет использовать значения по умолчанию и возвращать первые, или наиболее релевантные, 10 документов.
Для показа следующей страницы (в данном случае следующих 10 результатов) необходимо изменить параметр "from" в следующем запросе на 10 и так далее.
Как использовать пагинацию
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | # Первый запрос GET products/_search { "query": { "match": { "name": "bike" } }, "size": 10, "from": 0 } # Следующий запрос GET products/_search { "query": { "match": { "name": "bike" } }, "size": 10, "from": 10 } |
По умолчанию верхний предел для этого параметра составляет 10 000. Пагинация не позволит вам вернуть более 10 000 документов.
Существует способ изменить эту конфигурацию (index.max_result_window), и многие разработчики делают это, когда видят журнал ошибок, но это распространенный подводный камень.
Это один из немногих параметров конфигурации OpenSearch, который можно изменить - но не стоит.
Почему? В чем проблема при показе более 10000 совпадений?
Чтобы ответить на этот вопрос, необходимо немного углубиться в то, как работает поисковый запрос.
Поисковый запрос состоит из двух фаз. Фаза запроса и фаза получения.
На этапе запроса узлы данных вычисляют оценки совпадающих документов и, в основном, возвращают список оценок и идентификаторов документов.
Этот список создается на узле данных, передается узлу, обрабатывающему поисковый запрос, сортируется и хранится в памяти. Как вы можете себе представить, этот список оценок и идентификаторов для запроса может быть достаточно большим.
Затем наступает фаза выборки. На этапе выборки из каждого узла, где хранятся документы, извлекается их JSON-источник. По сути, это означает многократный Get-запрос по ID для всех документов, входящих в состав возвращаемой страницы.
Get-запросы очень эффективны. Однако следует помнить, что вся информация, связанная с запросом, должна оставаться в памяти до тех пор, пока ответ не будет отправлен обратно клиенту.
Поэтому обычно целесообразно использовать небольшой размер страницы.
Убийца производительности: Глубокая пагинация
Глубокая пагинация - один из главных убийц производительности вашего кластера. Глубокая пагинация означает предоставление пользователю доступа к слишком большому количеству страниц.
Вы никогда не должны предоставлять пользователям доступ ко всем страницам их поискового запроса. Если ваш PM недоволен этим, скажите ему, что даже Google показывает только ~50 страниц (500 хитов).
Почему глубокая пагинация является убийцей производительности?
Потому что OpenSearch постоянно приходится пересчитывать все хиты, сортировать и держать в памяти весь список Score-ID, даже если вы хотите показать всего 10 хитов, начиная с позиции 9990.
Хороший пользовательский интерфейс с фильтрами и т.д. и хороший релевантный скоринг сделают большинство пользователей счастливыми уже на первой странице, поэтому цель всегда должна заключаться в том, чтобы сделать глубокую пагинацию ненужной.
search_after
Если вам не нужен свободный доступ к страницам (например, переход с первой страницы на пятую и т.д.), но вас устраивает кнопка "далее" (или когда вы используете бесконечную прокрутку), то параметр search_after может оказаться для вас подходящим вариантом.
Как использовать search_after
| 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 | # Первый запрос GET products/_search { "query": { "match": { "name": "bike" } }, "size": 10, "sort": [ { "_score": "desc" }, { "id.keyword": "asc" } ] } # Следующий запрос GET products/_search { "query": { "match": { "name": "bike" } }, "size": 10, "sort": [ { "_score": "desc" }, { "id.keyword": "asc" } ], "search_after": [ 0.2876821, "1" ] } |
Как работает функция Search-After по сравнению с пагинацией?
С помощью search_after вы можете указать OpenSearch последний просмотренный результат, чтобы все предыдущие результаты были проигнорированы.
Вместо того чтобы хранить в памяти весь список score-ID для поискового запроса и сортировать его, чтобы выдать нужную страницу результатов, search_after будет использовать ничью из последнего просмотра предыдущего поискового запроса (можно подумать о закладке).
Это гораздо эффективнее, когда необходимо показать много результатов. При необходимости можно даже использовать search_after для показа более 10000 совпадений.
Как быть с обновлением индекса в реальном времени?
OpenSearch достаточно хорошо поддерживает обновление индекса в реальном времени, не вызывая при этом снижения производительности. Таким образом, вы можете легко добавлять документы, обновлять или удалять их и при этом выполнять запросы к одному и тому же индексу (интервал обновления является здесь ключевым понятием).
Хотя такое поведение достаточно полезно, когда речь идет о пагинации, оно может привести к несоответствиям на страницах результатов поиска, например, если вы вставили документ, релевантный запросу пользователя (среди первых 10 совпадений), пользователь щелкает на "Страница 2", и последний просмотренный им документ внезапно появляется на вершине страницы.
Пагинация и поиск после не имеют статического характера. Это означает, что нет никакой гарантии, что порядок результатов поиска будет неизменным, когда пользователь будет переходить от одной страницы к другой. Это, скорее всего, разочарует и запутает пользователей.
Если необходимо обеспечить одинаковый порядок результатов поиска в течение определенного времени, следует использовать технику пагинации с сохранением состояния.
В этом случае можно использовать API Point in Time. Он появился относительно недавно (функция ES 7.10 X-Pack), поэтому убедитесь, что ваша версия OpenSearch поддерживает его.
Если вы используете более старую версию OpenSearch, то вместо него можно использовать Scroll API.
API Point in Time
API Point in Time может быть использован для расширения пагинации или Search-After и придания им статуса stateful. Пользователь всегда будет видеть одну и ту же версию индекса за определенный период времени. Обновления будут игнорироваться или, по крайней мере, пользователь их не заметит, а поисковый опыт будет полностью согласован. Не будет никаких документов, внезапно появляющихся при переходе по страницам результатов поиска туда и обратно.
Как использовать пагинацию с помощью API Point in Time
| 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 | # Создать pit для индекса POST products/_pit?keep_alive=2m # First page GET _search { "from": 0, "size": 10, "query": { "match": { "name": "bike" } }, "pit": { "id": "85ezAwEIcHJvZHVjdHMWSzJZVTdKOU1RLU9SRVBsck43SGg3dwAWS3ptRzhJX3FUZE9iaGVpY3J5VmhTdwAAAAAAAAAABxZVYm5aNWF2U1NqcWJJdXhPc1dyS2hBAAEWSzJZVTdKOU1RLU9SRVBsck43SGg3dwAA", "keep_alive" : "2m" } } # Следующая страница GET _search { "from": 10, "size": 10, "query": { "match": { "name": "bike" } }, "pit": { "id": "85ezAwEIcHJvZHVjdHMWSzJZVTdKOU1RLU9SRVBsck43SGg3dwAWS3ptRzhJX3FUZE9iaGVpY3J5VmhTdwAAAAAAAAAABxZVYm5aNWF2U1NqcWJJdXhPc1dyS2hBAAEWSzJZVTdKOU1RLU9SRVBsck43SGg3dwAA", "keep_alive" : "2m" } } |
Как использовать Search After с API Point in Time
| 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 48 49 50 51 52 53 54 | # Создать PIT для индекса POST products/_pit?keep_alive=2m # Первая страница GET _search { "size": 10, "query": { "match": { "name": "bike" } }, "pit": { "id": "85ezAwEIcHJvZHVjdHMWSzJZVTdKOU1RLU9SRVBsck43SGg3dwAWS3ptRzhJX3FUZE9iaGVpY3J5VmhTdwAAAAAAAAAACRZVYm5aNWF2U1NqcWJJdXhPc1dyS2hBAAEWSzJZVTdKOU1RLU9SRVBsck43SGg3dwAA", "keep_alive" : "2m" }, "sort": [ { "_score": "desc" }, { "_shard_doc": "asc" } ] } # Следующая страница GET _search { "size": 10, "query": { "match": { "name": "bike" } }, "pit": { "id": "85ezAwEIcHJvZHVjdHMWSzJZVTdKOU1RLU9SRVBsck43SGg3dwAWS3ptRzhJX3FUZE9iaGVpY3J5VmhTdwAAAAAAAAAACRZVYm5aNWF2U1NqcWJJdXhPc1dyS2hBAAEWSzJZVTdKOU1RLU9SRVBsck43SGg3dwAA", "keep_alive" : "2m" }, "sort": [ { "_score": "desc" }, { "_shard_doc": "asc" } ], "search_after": [ 0.2876821, 0 ] } |
Scroll API
Scroll API может быть использован для итерационного просмотра большого количества документов, соответствующих запросу, или даже всех документов, соответствующих запросу.
Хотя API называется Scroll AP,I он не должен использоваться для реализации бесконечной прокрутки и не должен применяться для обслуживания частых запросов конечных пользователей.
В отличие от пагинации и Search-After, Scroll API является государственным. Это означает, что обновления индекса игнорируются в течение времени жизни запроса на прокрутку.
Для этого OpenSearch необходимо хранить снимок текущей версии индекса и сохранять его в течение всего времени существования контекста прокрутки.
Для активно обновляемых индексов сохранение исходного поискового контекста имеет высокую стоимость.
Как использовать Scroll API
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | # Первый запрос GET products/_search?scroll=1m { "size": 10, "query": { "match": { "name": "bike" } } } # Следующий запрос GET _search/scroll { "scroll": "1m", "scroll_id": "FGluY2x1ZGVfY29udGV4dF91dWlkDXF1ZXJ5QW5kRmV0Y2gBFlViblo1YXZTU2pxYkl1eE9zV3JLaEEAAAAAAAAAChZLem1HOElfcVRkT2JoZWljcnlWaFN3" } |
Резюме
Когда следует использовать пагинацию?
- Когда вам нужен свободный доступ к страницам и вы не планируете предлагать глубокую пагинацию.
Когда использовать поиск по сайту?
- Когда вам подходит кнопка "далее" и вы хотите предоставить эффективный доступ ко многим страницам.
Когда использовать API Point in Time?
- Когда вам нужен последовательный порядок на страницах результатов поиска.
- Если вы используете OpenSearch с X-Pack >7.10 или >7.13.
Когда использовать Scroll?
- Scroll может быть использован для вывода списка всех совпадений с запросом. Однако это должно быть редким запросом, возможно, только в экспертных приложениях или для очень редких запросов конечных пользователей.
- Когда требуется последовательный порядок на всех страницах результатов поиска.
- Если ваша версия OpenSearch не поддерживает функцию Point in Time.
