Зачем мне нужен "магазин": "да" в elasticsearch?

Я действительно не понимаю, почему в основные типы ссылке он говорит в описаниях атрибутов (например, для числа):

  1. store-установите значение да, чтобы сохранить фактическое поле в индексе, нет, чтобы не хранить его. По умолчанию нет (Примечание, сам документ JSON хранится, и его можно извлечь из него)
  2. index-установите значение нет, если значение не должно индексироваться. В этом случае store должен быть установлен в yes, так как если это не так индексируется и не хранится, тут нет ничего общего

две смелые части, кажется, противоречат. Если "index":"no", "store":"no" Я все еще могу получить значение из источника. Это может быть полезно, если у меня есть поле, содержащее URL, например. Нет?

у меня был небольшой эксперимент, где у меня было два отображения, в одном поле было установлено значение "store":"yes" и другое "store":"no".

в обоих случаях я все еще могу указать в моем запрос:

{"query":{"match_all":{}}, "fields":["my_test_field"]}

и я получил тот же ответ, возвращая поле.

Я думал, что если "store" установлено значение "no" это означало бы, что я не мог отступить в конкретное поле, но должен был получить все _source и разобрать его на стороне клиента.

Итак, какая польза есть в настройке "store" до "yes"? Это актуально только в том случае, если я исключаю поле из "_source" поле прямо?

2 55
elasticsearch

2 ответа:

Я думал, что если "магазин" установлен на "нет", это будет означать, что я не могу получить конкретное поле, но должен был получить весь _source и разобрать его на стороне клиента.

это именно то, что elasticsearch делает для вас, когда поле не хранится (по умолчанию) и _source поле включено (по умолчанию тоже).

вы обычно отправляете поле в elasticsearch, потому что вы либо хотите выполнить поиск по нему, либо получить его. Но это правда, что если вы не сохраните поле явно, и вы не отключите источник, который вы все еще можете получить поле с помощью _source. Это означает, что в некоторых случаях может иметь смысл иметь поле, которое не индексируется и не хранится.

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

всего в нескольких случаях может быть полезно хранить поля явно в lucene: когда _source поле отключено, или когда мы хотим избежать его разбора, даже если разбор выполняется автоматически с помощью elasticsearch. Имейте в виду, что получение многих сохраненных полей из lucene может потребовать одного поиска диска на поле, а с получением только _source от lucene и разбора его для того, чтобы получить необходимые поля просто один диск искать и просто быстрее в большинстве случаев.

100

по умолчанию в elasticsearch хранится _source (индексированный документ). Это означает, что при поиске, вы можете получить фактический источник документа обратно. Кроме того, elasticsearch будет автоматически извлекать поля / объекты из _source и возвращать их, если вы явно попросите об этом (а также, возможно, использовать его в других компонентах, таких как выделение).

можно указать, что определенное поле также сохраняется. Это означает, что данные для этого поля будет храниться "на собственный." Это означает, что если вы попросите "field1" (который хранится), elasticsearch определит, что его хранится, и загрузите его из индекса вместо того, чтобы получать его из _source (предполагая, что _source включен).

когда вы хотите включить хранение определенных полей? В большинстве случаев, вам не. Получение _source быстро и извлечение из него быстро, как хорошо. Если у вас очень большие документы, где стоимость хранения _source или стоимость разбора _source высока, вы можете явно карту некоторые поля, которые будут храниться.

обратите внимание, что существует стоимость извлечения каждого сохраненного поля. Так, например, если у вас есть json с 10 полями с разумным размером, и вы сопоставляете их все как сохраненные, и просите все из них, это означает загрузку каждого из них (больше дисков ищет), по сравнению с просто загрузкой _source (который является одним полем, возможно сжатым).

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

2