# Зачем нужен Payload?
**URL:** https://discuss.elastic.co/t/payload/183840
**Category:** Вопросы на русском языке
**Created:** [June 1, 2019, 9:34pm UTC](https://discuss.elastic.co/t/payload/183840 "2019-06-01T21:34:00Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@grefon](https://discuss.elastic.co/u/grefon)
#### Post date: [June 1, 2019, 9:34pm UTC](https://discuss.elastic.co/t/payload/183840/1 "2019-06-01T21:34:01Z")
В документации описан плагин "Delimited Payload Token Filter":
[https://www.elastic.co/guide/en/elasticsearch/reference/7.0/analysis-delimited-payload-tokenfilter.html](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/analysis-delimited-payload-tokenfilter.html)
Зачем он нужен и какая от него польза?
Можно ли как-то влиять на релевантность с помощью payload?
---
### Author:  [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [June 3, 2019, 10:43am UTC](https://discuss.elastic.co/t/payload/183840/2 "2019-06-03T10:43:44Z")
> [@grefon](#):
>
> Зачем он нужен и какая от него польза?
Payload это такая штука, что если вы про него спрашиваете, то вам он скорее всего не нужен 🙂 На релевантность он влиять может, но для этого вам надо написать свой плагин. Встроенных средств на данный момент нет. Польза от него в том, что можно с каждым термином определенную информацию сохранить, которая потом доступна при запросе.
---
### Author:  [@grefon](https://discuss.elastic.co/u/grefon)
#### Post date: [June 3, 2019, 1:20pm UTC](https://discuss.elastic.co/t/payload/183840/3 "2019-06-03T13:20:27Z")
Игорь, огромное спасибо за ответ!
Перечитал вроде бы всю документацию. Фильтр полезной нагрузки описан и больше ничего. Решил, что что-то упустил и решил переспросить.
До версии 2.4 payload был доступен в function\_score запросах:
[https://www.elastic.co/guide/en/elasticsearch/reference/2.4/modules-advanced-scripting.html#\_term\_positions\_offsets\_and\_payloads](https://www.elastic.co/guide/en/elasticsearch/reference/2.4/modules-advanced-scripting.html#_term_positions_offsets_and_payloads)
Проблема заключалась в том, что термины нужно было передавать вручную, а налету скрипт не имел к ним доступа - то есть отваливается нечеткость поиска.
Сейчас поставил 7 версию ElasticSearch - тут в документации вообще убрали все упоминания payload, оставили только фильтр. И то при установки index\_prefixes параметра нельзя использовать term\_vector=with\_positions\_offsets\_payloads, чтобы вытаскивать полезную нагрузку.
После версии 6.7 нет ни одного плагина, который бы расширял org.elasticsearch.index.similarity. Я в java не силен и даже примера нет, чтобы попытаться самому написать плагин.
К чему я это все: payload - это мощный инструмент! Печально, что его не только не довели до ума, но и окончательно забросили. Задать вес или коэффициент отдельному термину в строке - это же избавится от сложных запросов с разбиением данных на разные поля. Надеюсь, этот функционал еще доработают 🙄
---
### Author:  [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [June 7, 2019, 3:12pm UTC](https://discuss.elastic.co/t/payload/183840/4 "2019-06-07T15:12:11Z")
> [@grefon](#):
>
> Задать вес или коэффициент отдельному термину в строке - это же избавится от сложных запросов с разбиением данных на разные поля.
Разбиение данных на разные поля в данном случае более предпочтительное решение, так как оно не требует загрузки payload во время поиска.
Какую проблему вы пытаетесь с этим paypload-ом решить?
---
### Author:  [@grefon](https://discuss.elastic.co/u/grefon)
#### Post date: [June 8, 2019, 2:32pm UTC](https://discuss.elastic.co/t/payload/183840/5 "2019-06-08T14:32:43Z")
> [@Igor\_Motov](#):
>
> Какую проблему вы пытаетесь с этим paypload-ом решить?
Давайте в качестве примера рассмотрим распознавание адресов. Этакий аналог дадата.ру ))
Возьмем за основу несколько адресов:
_город_ Москва _улица академика Петра_ Анохина
_город_ Москва _улица **Юрия** _ Кондратюка
_город_ Киев _улица Гната_ **Юры**
Московская _область город_ Химки _улица_ Московская
Пользователь может написать слова в любом порядке, делать сокращения ( **ак.** Антохина или **Ю.** Кондратюка), видоизменять слова (Юрия = Юры), ошибаться в типах (перепутать проезд и переулок, или проспект с улицей), делать очепятки.
С помощью полезной нагрузки можно было бы в одном поле проставить для каждого термина вес, которым бы мы смогли влиять на релевантность:
**город** ^30 **Москва** ^100 **улица** ^20 **Юрия** ^70 **Кондратюка** ^100
**город** ^30 **Киев** ^100 **улица** ^20 **Гната** ^70 **Юры** ^100
Тип компонента адреса (город, улица...) имел бы меньший вес, должности (академика, генерала...) более высокий вес, имена еще больше вес, а точные названия и фамилии самый большой вес. Получается в одной строке есть ключи и дополнения к ключам для поднятия суммарного веса.
Если не делать разбивку по весу, то при запросе "Юры Кондратюка" мы получим вышеописанные две строки, которые будут иметь одинаковый score при similarity = boolean.
Я сейчас даю очень упрощенный пример, просто для обозначения сути проблемы!
Как можно решить задачу с подобным поиском? Делать энное количество полей в документе: отдельно под тип (город, улица), должности, имена, фамилии, варианты написания, сокращения и тд. Дальше делать multi\_match запрос с most\_fields типом. Это уже усложняет задачу по индексации! Сейчас мы знаем, что нужно к примеру 5 полей, а через месяц будут новые данные и полей будет не 5, а 10. Значит пересоздавать mappings и индекс.
А теперь давайте посмотрим на 4 пример: Московская _область город_ Химки _улица_ Московская - тут у нас слово Московская повторяется дважды. Значит нам нужно делать еще один should запрос match\_phrase\_prefix и большим slop, чтобы учесть, что это разные термины - рескоринг ([Improving Performance | Elasticsearch: The Definitive Guide [master] | Elastic](https://www.elastic.co/guide/en/elasticsearch/guide/master/_improving_performance.html#rescore-api))
Но! Поскольку у нас строка адреса разнесена на составляющие поля, чтобы задать вес каждому слову, то мы не сможем сделать match\_phrase\_prefix - значит нам нужно добавить в документ еще одно поле, в котором бы мы писали всю строку целиком.
Как итог:
1. вместо одного поля нужно заводить энное количество!
2. проблемное масштабирование и индексация
3. перечислять все поля при поиске с указанием веса для каждого поля
4. все равно создавать дополнительное поле для специфических "подзапросов", в котором хранить все слова
5. размер индекса больше
6. как мне кажется - скорость поиска будет все же меньше, особенно при длинных запросах
---
### Author:  [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [June 10, 2019, 6:13pm UTC](https://discuss.elastic.co/t/payload/183840/6 "2019-06-10T18:13:12Z")
> 1. вместо одного поля нужно заводить энное количество!
Это так, но распределиение разных компонентов по разным полям имеет несколько приемуществ. В частности, это позволяет производить аггрегацию, например, по городам, или фильтрацию по регионам.
> 1. проблемное масштабирование и индексация
С масштабированием проблема как раз с payload-ами, по скольку они подтягиваются после поиска и как результат вызывают дополнительную нагрузку на диск.
> 1. перечислять все поля при поиске с указанием веса для каждого поля
Да, но при этом вы динамически сможете менять вес каждого поля без переиндексации. А поля вам все-равно придется определять, хот я бы при индексации.
> 1. все равно создавать дополнительное поле для специфических "подзапросов", в котором хранить все слова
Это можно автоматизировать с помощью `copy_to`
> 1. размер индекса больше
Единственное, что тут больше - это размер `source`. Но, это не должно существенно повлиять на производительность.
> 1. как мне кажется - скорость поиска будет все же меньше, особенно при длинных запросах
Думаю, что наоборот, из-за неэффективности работы с payload.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 8, 2019, 6:13pm UTC](https://discuss.elastic.co/t/payload/183840/7 "2019-07-08T18:13:14Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.