なぜなのか本当に理解できないコアタイプリンク属性の説明には次のように書かれています (たとえば、数値の場合)。
- store - 実際のフィールドをインデックスに保存する場合はyesに設定し、保存しない場合はnoに設定します。デフォルトはnoです（注：JSON文書自体は保存されており、そこから取得できる。）
- index - 値をインデックスしない場合はnoに設定します。この場合、storeはyesに設定する必要があります。インデックスも保存もされていない場合は、それは何の関係もありません
太字の 2 つの部分は矛盾しているようです。"index":"no", "store":"no"それでもソースから値を取得できれば、たとえば URL を含むフィールドがある場合に、これをうまく活用できるかもしれません。そうではありませんか?
ちょっとした実験をしてみました。2 つのマッピングがあり、1 つのフィールドは に設定され"store":"yes"、もう 1 つのフィールドは に設定されました"store":"no"。
どちらの場合でも、クエリで次のように指定できます。
{"query":{"match_all":{}}, "fields":["my_test_field"]}
そして、フィールドを返して同じ答えが得られました。
"store"に設定されている場合"no"、特定のフィールドを取得できず、全体を取得して_sourceクライアント側で解析する必要があると考えました。
では、 を設定するとどのような利点があるのでしょうか"store"?"yes"フィールドを フィールドから"_source"明示的に除外した場合にのみ関係があるのでしょうか?
ベストアンサー1
「store」が「no」に設定されている場合、特定のフィールドを取得できず、_source 全体を取得してクライアント側で解析する必要があると考えました。
これは、フィールドが保存されていない (デフォルト) 場合と、フィールド_sourceが有効になっている (これもデフォルト) 場合に elasticsearch が行うこととまったく同じです。
通常、フィールドを elasticsearch に送信するのは、そのフィールドを検索するか、取得するためです。ただし、フィールドを明示的に保存せず、ソースを無効にしない場合でも、 を使用してフィールドを取得できることは事実です_source。つまり、場合によっては、インデックスも保存もされていないフィールドを持つことが実際に意味がある場合があります。
フィールドを保存すると、基礎となる Lucene で実行されます。Lucene は逆インデックスであり、高速な全文検索が可能で、テキスト クエリに対してドキュメント ID を返します。逆インデックスの他に、Lucene には、ドキュメント ID を指定して取得できるようにフィールド値を保存できるストレージがあります。通常、検索結果として返したいフィールドを Lucene に保存します。Elasticsearch は、送信されたすべてのドキュメントを常にデフォルトで保存するため、返したいすべてのフィールドを保存する必要はありません。そのため、送信されたすべてのものを常に検索結果として返すことができます。
ごく少数のケースでは、フィールドを明示的に Lucene に保存すると便利な場合があります。フィールド_sourceが無効になっている場合や、解析が Elasticsearch によって自動的に行われる場合でも解析を避けたい場合などです。ただし、Lucene から多数の保存フィールドを取得するには、フィールドごとに 1 回のディスク シークが必要に_sourceなる可能性があることに注意してください。一方、Lucene からフィールドのみを取得して解析し、必要なフィールドを取得する場合は、ディスク シークが 1 回だけになり、ほとんどの場合、より高速になります。