doc_values
デフォルトでは、フィールドのほとんどは、インデックス付きなので、これらのフィールドを検索することができるのまま。転置インデックス（逆索引）は、クエリが用語のリストで検索語（検索語）を見つけ、すぐに単語エントリを含むドキュメントのリストを取得することができます。
転置インデックス（逆索引）：
我々は茶色の単語を含むすべての文書の完全なリストを取得したい場合は、我々は次のクエリを作成します。
GET / my_index / _search
{
"クエリ"：{
"一致"：{
「身体」：「ブラウン」
}
}、
"aggs"：{
"popular_terms"：{
"条項" ： {
「フィールド」：「身体」
}
}
}
}
逆索引は、項目の言葉に従ってソートされたので、私たちは最初に茶色含まれている文書を検索するために、すべての列をスキャンし、その後、茶色に用語のリストを見つけます。私たちは、すぐにDoc_1は茶色とDoc_2このトークンが含まれて見ることができます。
その後、重合部分のために、我々はすべてのエントリにDoc_1とDoc_2だけの単語を見つける必要があります。高価な転置インデックスでこれを実行します。私たちは、エントリ内のインデックスにすべての単語をイテレーションとトークン内部Doc_1とDoc_2列を収集します。これは、スケールに遅いと難しいです：用語やドキュメントの数の増加に伴い、実行時間が増加します。
両者の関係を入れ替えることにより、この問題を解決するためのドキュメント値。用語の転置インデックスは、ドキュメントの値は、彼らが含まれているという点で、条件にドキュメントをマッピングするために、それらを含む文書にマップされます。
データは転置された場合、ユニークなトークンDoc_1とDoc_2を収集することは非常に簡単になります。各文書の行を取得し、すべての語彙項目を取得し、2つのセットを検索して設定します。
ドク値は、重合はより速く、より多くのメモリ効率的かつ友好的であることができます。DOC値転置インデックスがあるため、特定の操作のためにのみ有効です。
逆インデックスの利点：単一の文書が存在する場合、重合は、このアクセス・モードを必要とするアイテムを決定するために別の操作と反対方向、すなわち、効率的ではないが、アイテムをその文書を検索します。
Elasticsearchにドキュメントの値の列記憶構造の一種であり、デフォルトでは、各フィールドのドキュメントの値がアクティブで、ドキュメントの値が場合、インデックス作成されます。フィールドインデックス、elasticsearch順序はすぐに転置インデックスに追加されるフィールドの値を取得することができるように、それはまた `ドクValues`フィールドを格納した場合。
多くの場合、次のシナリオに適用されるElasticsearchドク値：
-
フィールドの並べ替え
-
重合させるためのフィールド
-
そのような地理的位置フィルターなどの一部のフィルタ、
-
コンピューティング分野に関連したいくつかのスクリプト
文書（DOC値）の値がディスクにシリアライズされているので、我々は、高速アクセスのためのオペレーティングシステムの助けに頼ることができます。ノードのワーキングセットが使用可能なメモリよりもはるかに小さい場合には非常に高速な読み取りと書き込みのように、システムが自動的にすべての文書の値は、メモリに保存されます。それが利用可能なメモリよりもはるかに大きい場合、オペレーティングシステムが自動的にページバッファドク値システムにロードされますJVMのヒープメモリオーバーフロー例外を避けるためです。
そのため、検索や集計は、相互に緊密に巻かれています。データで収集し、集計業務重合ドキュメント値、ドキュメントを検索するために、反転インデックス検索を使用します。
DOC値は、ほとんどのフィールドタイプをサポートしていますが、（分析された）テキストフィールドのタイプがサポートされていません。
（1）STATUS_CODEのdoc_valuesのデフォルトのスタートアップは、フィールド属性。
（2）は、明示的doc_valuesが= falseを設定SESSION_ID、まだ照会することができます。
如果确信某字段不需要排序或者聚合，或者从脚本中访问字段值，那么我们可以设置 doc_values = false，这样可以节省磁盘空间。
fielddata
与 doc values 不同，fielddata 构建和管理 100% 在内存中，常驻于 JVM 内存堆。这意味着它本质上是不可扩展的。
fielddata可能会消耗大量的堆空间，尤其是在加载高基数（high cardinality）text字段时。一旦fielddata已加载到堆中，它将在该段的生命周期内保留。此外，加载fielddata是一个昂贵的过程，可能会导致用户遇到延迟命中。这就是默认情况下禁用fielddata的原因。
如果需要对 text 类型字段进行排序、聚合、或者从脚本中访问字段值，则会出现如下异常：
Fielddata is disabled on text fields by default. Set fielddata=true on [your_field_name] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory.
但是，在启动fielddata 设置之前，需要考虑为什么针对text 类型字段进行排序、聚合、或脚本呢？通常情况下，这是不太合理的。
text字段在索引时，例如New York，这样的词会被分词，会被拆成new、york 2个词项，这样当搜索new 或 york时，可以被搜索到。在此字段上面来一个terms的聚合会返回一个new的bucket和一个york的bucket，但是你可能想要的是一个单一new york的bucket。
怎么解决这一问题呢？
你可以使用 text 字段来实现全文本查询，同时使用一个未分词的 keyword 字段，且启用doc_values，来处理聚合操作。
(1) 使用my_field 字段用于查询；
(2) 使用my_field.keyword 字段用于聚合、排序、或脚本；
可以使用 PUT mapping API 在现有text 字段上启用 fielddata，如下所示：
《Elasticsearch 7.x从入门到精通》专栏会通过理论与实践相结合的方式，带领你一步一步走进Elasticsearch的世界，使你轻松掌握Elasticsearch的基本概念，学习Elasticsearch的服务搭建，了解Elasticsearch的常用技巧，并通过案例项目让你拥有实际的应用能力。 同时，也会讲解Elastic Stack中其他相关组件，如Logstash、Beats和Kibana等等。
