ELK-ElasticSearch-官方文档note

1、getting started

1. use case 1.1 存储大数据，作查询 1.2 存储日志 1.3 从第三方收集数据，进行分析、查询 1.4 分析聚合数据，利用kibana展现

2. 基本概念 2.1 near realtime 近实时

   2.2 cluster（集群） 有多个node，每一个cluster有惟一的一个名字，默认是‘elasticsearch’

   2.3 node（节点） 一个集群中的其中一个服务节点，默认名字是一个uuid，能够指定它加入的集群的名字

   2.4 index（索引）是具备稍微相似特征文档的集合，至关于数据库中的一个数据库实例。

   一个索引也有一个名字，它在 对document（文档）执行 indexing（索引），search（搜索），update（更新）和 delete（删除）等操做时 会被涉及到。一个集群中能够有多个索引。

你也许已经注意到 索引 这个词在 Elasticsearch 语境中包含多重意思， 因此有必要作一点儿说明： 索引（名词）： 如前所述，一个 索引 相似于传统关系数据库中的一个 数据库 ，是一个存储关系型文档的地方。 索引 (index) 的复数词为 indices 或 indexes 。 索引（动词）： 索引一个文档 就是存储一个文档到一个 索引 （名词）中以便它能够被检索和查询到。这很是相似于 SQL 语句中的 INSERT 关键词，除了文档已存在时新文档会替换旧文档状况以外。 倒排索引： 关系型数据库经过增长一个 索引 好比一个 B树（B-tree）索引 到指定的列上，以便提高数据检索速度。Elasticsearch 和 Lucene 使用了一个叫作 倒排索引 的结构来达到相同的目的。

• 默认的，一个文档中的每个属性都是 被索引 的（有一个倒排索引）和可搜索的。一个没有倒排索引的属性是不能被搜索到的。咱们将在 倒排索引 讨论倒排索引的更多细节。

2.5 type （类型）至关于数据库中的一个表。

在 Index（索引）中，能够定义一个或多个类型。一个类型是索引中一个逻辑的种类/分区，它的语义彻底取决于您本身。

通常状况下，一个类型被定义成一组常见字段的文档。例如，假设您运行着一个博客平台而且在一个单独的索引中存储了全部的数据。在这个索引中，您也许定义了一个用户数据类型，博客数据类型，和评论数据类型。在高版本中会被移除。

2.6 document （文档）    是索引信息的基本单位，至关于数据库中的一条数据

例如，您有一存储 customer（客户）数据的文档，另外一个是存储 product（产品）数据的文档，还有一个是存储 order（订单）数据的文档。该文档可使用 JSON 来表示，它是一种无处不在的互联网数据交换格式。在索引/类型中，您能够存储许多文档。

注意，尽管一个文档物理的存在于索引中，实际上一个文档必须被 索引/分配 给索引内的类型。

---

3. exploring cluster 探索集群

3.1 集群健康：Cluster Health

curl -XGET 'localhost:9200/_cat/health?v&pretty'

能够得到 green，yellow，或者 red 的 status。Green 表示一切正常（集群功能齐全）， yellow 表示全部数据可用，可是有些副本还没有分配（集群功能齐全），red 意味着因为某些缘由有些数据不可用。注意，集群是 red，它仍然具备部分功能（例如，它将继续从可用的分片中服务搜索请求），可是您可能须要尽快去修复它，由于您已经丢失数据了。

3.2 操做索引：Create an Index

curl -XGET 'localhost:9200/_cat/indices?v&pretty' 列出全部索引

curl -XPUT 'localhost:9200/customer?pretty' 添加索引

curl -XDELETE 'localhost:9200/customer?pretty' 删除索引

3.3 操做文档：Modifying Your Data

PUT：

curl -XPUT 'localhost:9200/customer/external/1?pretty&pretty' -d'{ "name": "John Doe"}'

添加文档，若是文档已存在，则更新。其中external是type（类型），其中 1 是 类型的ID

POST：

curl -XPOST 'localhost:9200/customer/external/1/_update?pretty&pretty' -d'{ "doc": { "name": "Jane Doe" }}'

_update 更新文档

curl -XDELETE 'localhost:9200/customer/external/2?pretty&pretty' 删除文档

curl -XGET 'localhost:9200/customer/external/1?pretty' 获取文档

curl -XPOST 'localhost:9200/customer/external/_bulk?pretty&pretty' -d'

_bulk 批量处理：

POST /customer/_doc/_bulk?pretty
{"update":{"_id":"1"}}
{"doc": { "name": "John Doe becomes Jane Doe" } }
{"delete":{"_id":"2"}}

将 HTTP 命令由 PUT 改成 GET 能够用来检索文档，一样的，可使用 DELETE 命令来删除文档，以及使用 HEAD 指令来检查文档是否存在。若是想更新已存在的文档，只需再次 PUT 。 PUT 和 POST 区别：他们均可以用来提交和更新资源，可是PUT的接口是幂等的。

---

2、 查询操做：The Search API ----> _search

1.REST request URI 根据uri查询

GET bank/account/_search?q=age:39&pretty&pretty
对index为bank，type为account进行检索

Multi-Index, Multi-Type : 多index、多type查询

It also support wildcards, for example: test* or test or tet or test, and the ability to "add" (+) and "remove" (-), for example: +test*,-test3. 更多语法查询官网

/_search 在全部的索引中搜索全部的类型

/gb/_search 在 gb 索引中搜索全部的类型

/gb,us/_search 在 gb 和 us 索引中搜索全部的文档

/g*,u*/_search 在任何以 g 或者 u 开头的索引中搜索全部的类型

/gb/user/_search 在 gb 索引中搜索 user 类型

/gb,us/user,tweet/_search 在 gb 和 us 索引中搜索 user 和 tweet 类型

/_all/user,tweet/_search 在全部的索引中搜索 user 和 tweet 类型

参数：

1. q ----> map to query string query !!! 看完query string query回过头来看！！!？？？
2. df 当没有指定查询的字段时，指定默认查询字段。
3. analyzer 指定查询分析器？？？
4. analyze_wildcard(通配符) 是否应分析通配符和前缀查询。默认为false。
5. batched_reduce_size 减小每一个分片查询的数据量。若是每次查询分片数大的话，减小这个值能够用来避免机器占用过多内存。
6. default_operator 默认的操做符为 OR ，还能够是AND。
7. lenient 宽容的。若是是true，则字段类型是敏感的，如向数字字段提供字符串查询，则会致使失败，默认是false
8. explain 解释对命中的得分。
9. _source 是否显示_source ，默认true。也可使用_source_include 或者_source_exclude选择显示的字段。
10. timeout
11. from
12. size
13. search_type
14. stored_fields ???
15. sort 排序：sort=age:asc，好像也能够根据分数来排序？？？
16. track_scores: ??? When sorting, set to true in order to still track scores and return them as part of each hit.
17. track_total_hits: ??? Set to false in order to disable the tracking of the total number of hits that match the query
18. terminate_after
19. search_type ：要执行的搜索操做的类型。能够是 dfs_query_then_fetch 或 query_then_fetch。默认为 query_then_fetch。有关能够执行的不一样类型搜索的更多详细信息，请参阅搜索类型。

举例：

curl -XGET 'localhost:9200/bank/_search?q=*&sort=account_number:asc&pretty'

在响应中，咱们能够看到如下几个部分 :

took - Elasticsearch 执行搜索的时间（毫秒）

time_out - 告诉咱们搜索是否超时

_shards - 告诉咱们多少个分片被搜索了，以及统计了成功/失败的搜索分片

hits - 搜索结果

hits.total - 搜索结果

hits.hits - 实际的搜索结果数组（默认为前 10 的文档）

sort - 结果的排序 key（键）（没有则按 score 排序）

score 和 max_score -如今暂时忽略这些字段

2.REST request body( 全文搜索编辑 ) : DSL

1. query: 使用DSL查询，具体查看DSL语法
2. from/size：
3. sort：
4. _source：
5. stored_fields ：存储字段。stored_fields 参数是关于显式标记为存储在映射中的字段，默认状况下关闭， ？？？？
6. script: 脚本。 看Modules » Scripting？？？
7. docvalue_fields ： Mapping » Mapping parameters » doc_values？？？？
8. filter/post_filter： filter先过滤再聚合，post_filter先聚合再过滤。
9. highlight： 高亮
10. rescoring: ??? 从新计算分数
11. search_type:
12. scroll API : 滚动api
13. preference：控制要对其执行搜索请求的分片副本的首选项
14. explain: 启用每次匹配对其评分计算方式的说明。
15. version: 返回每一个搜索匹配的版本。
16. index_boost: 容许在跨多个索引搜索时为每一个索引配置不一样的查询级别。好比更但愿从indexA中命中，则：

"indices_boost" : {
        "index1" : 1.4,
        "index2" : 1.3
    }

17. min_score： 排除 _score 小于 min_score 中指定的最小值的文档
18. named queries : ????
19. inner hits: ???
20. search_after：分页深度太深。search_after 参数经过提供活动光标来规避此问题。 这个想法是使用前一页的结果来帮助检索下一页。
21. field collapsing：字段折叠。容许基于字段对结果进行折叠。?????

Count API

_count 返回计数值

validate API

_validate 验证查询是否有效

Search 模板 ？？？

/_search/template

Search Shards API 查询分片API ？？？

_search_shards

suggesters ？？？

Multi Search API ？？？

_msearch 一次有多个query

Expliain API ： Explain API 计算查询和特定文档的分数说明

_explain

Profile API

在_search中，添加参数："profile": true 显示查询详细过程，能够用来判断为什么比较慢

3、聚合Aggregations：每一个聚合都是一个或者多个桶和零个或者多个指标的组合

1. Bucket：桶，知足特定条件的文档的集合，相似于sql中的group by。它也能够嵌套使用。 有各类构造桶的方式，如：
   1. terms桶：会为每一个碰到的惟一词项动态建立新的桶。 由于咱们告诉它使用 color 字段，因此 terms 桶会为每一个颜色动态建立新桶。其实就是当作一个分词是一个组。

"aggs" : { "popular_colors" : { 桶的名字 "terms" : { terms构建桶 "field" : "color" 构建的属性 } } }

2. date_histogram
	3. date_range
	4. Missing Aggregation
	5. range aggregation
	6.  "size":0    ,  去掉匹配的数据，只留aggregations
2. Metric(度量、指标)：对桶内的文档进行统计计算。如：计数：value_count、平均值：avg、最大值max，最小值min。。。
```json
计算age字段的最大值，赋值给max_age。计算age的最小值，赋值给min_age
"aggs":{
    "min_age":{
      "min":{"field":"age"}
    },
    "max_age":{
      "max":{"field":"age"}
    }
  }
  结果：
  "aggregations": {
    "max_age": {
      "value": 40
    },
    "min_age": {
      "value": 20
    }
  }

3. Matrix: 矩阵，与文件有关
4. Pipeline： 将其余的聚类方法的输出结果以及与其相连的度量进行聚合。
5. Structuring Aggregations：结构化聚合
6. Values Source

4、索引API

1. 建立、删除、获取、存在等。

如下特别重要：

正排索引是从文档到关键字的映射（已知文档求关键字）；

倒排索引是从关键字到文档的映射（已知关键字求文档）。

搜索时，咱们须要一个“词”到“文档”列表的映射

排序时，咱们须要一个“文档”到“词“列表的映射，换句话说，咱们须要一个在倒排索引的基础上创建的“正排索引”

在默认状况下许多字段都是 indexed（被索引的）,这使得它们能够被搜索.反向索引容许查询经过惟一性排序的 term（词根）列表来查询 term（词根）,而且能够当即访问包含该 term（词根）的文档.

这里的“正排索引”结构一般在其余系统中（如关系型数据库）被称为“列式存储”。本质上，它是在数据字段的一列上存储全部value，这种结构在某些操做上会表现得很高效，好比排序。

在ES里这种“列式存储”就是咱们熟悉的“doc values”，默认状况下它是被启用的，doc values在index-time（索引期）被建立：当一个字段被索引时，ES会把“词”加入到倒排索引中，同时把这些词也加入到面向“列式存储”的doc values中（存储在硬盘上）。

搜索须要回答一个问题 “哪一个 document（文档） 包含这个 term（词条）”,然而排序和聚合须要回答一个不一样的问题 " 这个字段在这个 document（文档）中的值是多少？".!!!!!!!!!!!!!!!!

5、cat API

将如下信息在终端中显示的更好看

• /_cat/allocation
• /_cat/shards
• /_cat/shards/{index}
• /_cat/master
• /_cat/nodes
• /_cat/tasks
• /_cat/indices
• /_cat/indices/{index}
• /_cat/segments
• /_cat/segments/{index}
• /_cat/count
• /_cat/count/{index}
• /_cat/recovery
• /_cat/recovery/{index}
• /_cat/health
• /_cat/pending_tasks
• /_cat/aliases
• /_cat/aliases/{alias}
• /_cat/thread_pool
• /_cat/thread_pool/{thread_pools}
• /_cat/plugins
• /_cat/fielddata
• /_cat/fielddata/{fields}
• /_cat/nodeattrs
• /_cat/repositories
• /_cat/snapshots/{repository}
• /_cat/templates

6、集群API

• Cluster Allocation Explain API -> 它的目的是帮助回答这个问题 “为何这个分片没有被分配”。为了说明分片的分配（未分配状态），发出一个这样的请求 :
• Cluster Health
• Cluster Reroute 路由
• Cluster State 状态
• Cluster Stats 统计
• Cluster Update Settings
• Nodes hot_threads
• Nodes Info （集群节点信息）API 能够获取集群中一个或多个节点的信息。
• Nodes Stats 节点统计信息
• Pending cluster tasks -> pending cluster tasks（添加集群任务）API 返回一个集群级别中尚未被执行的操做的列表（例如，建立索引，更新映射，分配或故障的分片）。
• Task Management API

7、es的各个Module（模块）

本章节负责介绍Elasticsearch包含的各个模块的功能，每一个模块的配置均可以经过以下方式进行配置：

• 静态的

  这些配置项必须基于节点来进行设置，在启动节点前能够经过elasticsearch.yml配置文件、环境变量、命令行参数方式来进行配置。他们必须明确地在集群中的每一个节点上进行设置。

• 动态的

  这些配置能够经过群集的cluster-update-settings API进行动态更新。

本节介绍的模块有：

1. Cluster-level routing and shard allocation（集群级别的路由与分片分配））   用来控制在何处、什么时候、以及如何给节点分配分片。

2. Discovery（发现）   构成一个集群的节点彼此之间是如何发现的。

3. Gateway（网关）   集群启动恢复前须要多少个节点加入。

4. HTTP   用来控制配置HTTP REST接口。

5. Indices（索引）   全部跟索引相关的设置。

6. Network（网络）   控制默认的网络设置。

7. Node client（节点客户端）   一个加入集群的Java客户端节点，但不能保存数据或做为主节点。

8. Painless   Elasticsearch内置的脚本语言，遵循尽量的安全设计。

9. Plugins（插件）   经过插件来扩展Elasticsearch的功能。

10. Scripting（脚本）   经过Lucene表达式、Groovy、Python、以及Javascript来自定义脚本。你也可使用内置的脚本语言Painless。

11. Snapshot/Restore（快照/还原）   经过快照与还原模块来备份你的数据。

12. Thread pools（线程池）   Elasticsearch专用的线程池的信息。

13. Transport（传输）   Elasticsearch内部各节点之间的网络传输层通讯配置。

14. Tribe nodes   Tribe节点能加入一个或多个集群，并做为它们之间的联合客户端。

15. Cross cluster Search（跨集群搜索）   跨集群搜索功能能够经过一个不加入集群、而且能做为它们之间的联合客户端来实现一个以上集群的搜索。

8、索引模块

包括索引的各个设置和信息查看 Settings in other index modules（其余索引模块的设置） 在索引模块中其余可用的索引设置 :

1. Analysis（分析） 定义 analyzers（分析器）、tokenizers（分词器）、token filters（词元过滤器）和 character filters（字符过滤器）。

2. Index shard allocation（索引分片分配） 控制索引分配给节点的位置、时间、以及分片的方式。

3. Mapping（映射） 启用或禁用索引的动态映射。

4. Merging（合并） 控制后台合并线程如何合并分片。

5. Similarities（类似性） 配置自定义类似性设置以自定义搜索结果的计分方式。

6. Slowlog（慢日志） 控制记录搜索和索引请求的响应时间。

7. Store（存储)） 配置用于存储分片数据的文件系统类型。

8. Translog（事务日志） 控制事务日志和后台刷新操做。

9、查询DSL

Elasticsearch 提供了一个基于 JSON 的完整的查询 DSL 来定义查询。将查询 DSL 视为查询的 AST，由两种类型的子句组成：

一个查询语句 的典型结构!!!!!!!!!!!!!：

{
    QUERY_NAME: {
        ARGUMENT: VALUE,
        ARGUMENT: VALUE,...
    }
}

若是是针对某个字段，那么它的结构以下：

{
    QUERY_NAME: {
        FIELD_NAME: {
            ARGUMENT: VALUE,
            ARGUMENT: VALUE,...
        }
    }
}

1. 叶查询子句 -> 叶查询子句在特定查询中查找特定值，例如匹配match、项值term、范围查询range。这些查询均可以给本身使用。

2. 复合查询子句 -> 主要用于 合并其它查询语句，用于以逻辑方式组合多个查询（例如 bool 或 dis_max 查询），或更改其行为（如 constant_score 查询）。 好比，一个 bool 语句 容许在你须要的时候组合其它语句，不管是 must 匹配、 must_not 匹配仍是 should 匹配，同时它能够包含不评分的过滤器（filters）：

{
    "bool": {
        "must":     { "match": { "tweet": "elasticsearch" }},
        "must_not": { "match": { "name":  "mary" }},
        "should":   { "match": { "tweet": "full text" }},
        "filter":   { "range": { "age" : { "gt" : 30 }} }
    }
}

一条复合语句能够合并 任何 其它查询语句，包括复合语句，了解这一点是很重要的。这就意味着，复合语句之间能够互相嵌套，能够表达很是复杂的逻辑。

{
    "bool": {
        "must": { "match":   { "email": "business opportunity" }},
        "should": [
            { "match":       { "starred": true }},
            { "bool": {
                "must":      { "match": { "folder": "inbox" }},
                "must_not":  { "match": { "spam": true }}
            }}
        ],
        "minimum_should_match": 1
    }
}

Elasticsearch 使用的查询语言（DSL） 拥有一套查询组件，这些组件能够以无限组合的方式进行搭配。这套组件能够在如下两种状况下使用：过滤状况（filtering context）和查询状况（query context）。

当使用于 过滤状况 时，查询被设置成一个“不评分”或者“过滤”查询。即，这个查询只是简单的问一个问题：“这篇文档是否匹配？”。回答也是很是的简单，yes 或者 no ，两者必居其一。 最重要的是，filter不须要统计评分，并且es会缓存，所以更快，更高效！！！！

查询子句的行为有所不一样，具体取决于它们是在查询上下文仍是过滤器上下文中使用。

查询上下文: query

在查询上下文中使用的查询子句回答了问题“此文档与此查询子句匹配程度如何？”除了决定文档是否匹配以外，查询子句还计算一个得分（ _score ）表示文档相对于其余文档的匹配程度。 每当将查询子句传递给 query 参数（例如，search API中的 query 参数）时，查询上下文都有效。

过滤上下文: filter

在过滤器上下文中，查询子句回答问题“此文档是否匹配此查询子句？”答案是一个简单的是或否——不计算得分。 过滤器上下文主要用于过滤结构化数据，例如：

此 timestamp 是否在2015年至2016年的范围内？ status 字段是否设置为 "published"

1. 单个查询条件 0. match_all / match_none -> match_all 查询简单的 匹配全部文档。在没有指定查询方式时，它是默认的查询

   1. match -> 匹配查询（match） 用于执行全文查询的标准查询，包括模糊匹配和词组或邻近程度的查询。

      • match -> {"query":{"bool":{"must":[{"match":{"age":20}},{"match":{"age":30}}]}}}

   2. 短语匹配查询（match_phrase） 与匹配查询相似，可是是用于更加精确的匹配类似的词组或单词。

   3. 短语前缀匹配查询（match_phrase_prefix） 这是一种弱类型的查询，相似短语匹配查询，可是它对最终要查询的单词的前缀进行模糊匹配的查询

   4. 多字段查询（multi_match） 能够用来对多个字段的版本进行匹配查询

   5. 经常使用术语查询（common） 能够对一些比较专业的偏门词语进行的更加专业的查询

   6. 查询语句查询（query_string） 与lucene查询语句的语法结合的更加紧密的一种查询，容许你在一个查询语句中使用多个 特殊条件关键字（如：AND|OR|NOT ）对多个字段进行查询，固然这种查询仅限专家用户去使用。

   7. 简单查询语句（simple_query_string） 是一种适合直接暴露给用户的简单的且具备很是完善的查询语法的查询语句

   8. 范围查询语句（range） gt大于、gte大于等于、lt小于、lte小于等于

   9. 精确匹配 (term / trems) term 查询对于输入的文本不 分析 ，因此它将给定的值进行精确查询。

   10. 是否存在查询 (exists / missing)

   11.查询语句查询 （query_string ） 使用查询解析器为了解析其内容的查询。

   12. boost -> 咱们能够经过指定 boost 来控制任何查询语句的相对的权重， boost 的默认值为 1 ，大于 1 会提高一个语句的相对权重。boost 参数被用来提高一个语句的相对权重（ boost 值大于 1 ）或下降相对权重（ boost 值处于 0 到 1 之间），可是这种提高或下降并非线性的，换句话说，若是一个 boost 值为 2 ，并不能得到两倍的评分 _score 。

{ "match": {
                    "content": {
                        "query": "Lucene",
                        "boost": 2 
                    }
                }
}

2. 组合查询（将上面多个单查询组合起来）

   1. must 文档 必须 匹配这些条件才能被包含进来。
   2. must_not 文档 必须不 匹配这些条件才能被包含进来。
   3. should 若是知足这些语句中的任意语句，将增长 _score ，不然，无任何影响。它们主要用于修正每一个文档的相关性得分。
   4. filter 必须 匹配，但它以不评分、过滤模式来进行。这些语句对评分没有贡献，只是根据过滤标准来排除或包含文档。

3. 复合查询（将上面多个组合查询 组合起来）

   1. bool 如：age=30而且gender=F

{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "age": 30
          }
        },
        {
          "match": {
            "gender": "F"
          }
        }
      ]
    }
  }
}

2. constant_score 查询
这是一个包装其余查询的查询，而且在过滤器上下文中执行。与此查询匹配的全部文件都须要返回相同的“常量” _score 。

3. dis_max 即分离 最大化查询（Disjunction Max Query）-> 分离（Disjunction）的意思是 或（or） ，这与能够把结合（conjunction）理解成 与（and） 相对应。分离最大化查询（Disjunction Max Query）指的是： 将任何与任一查询匹配的文档做为结果返回，但只将最佳匹配的评分做为查询的评分结果返回 ：

4. Function_Score -> function_score 容许你修改一个查询检索文档的分数。 

5. boosting 查询 -> 能够用来有效地降级能匹配给定查询的结果

3. 上述基本都是针对整个词的操做，接下来是部分匹配
   1. Term Query（项查询） 查询包含在指定字段中指定的确切值的文档。
   2. Terms Query（多项查询） 查询包含任意一个在指定字段中指定的多个确切值的文档。
   3. Range Query（范围查询） 查询指定字段包含指定范围内的值（日期，数字或字符串）的文档。
   4. Exists Query（非空值查询） 查询指定的字段包含任何非空值的文档。
   5. Prefi Query（前缀查询） 查找指定字段包含以指定的精确前缀开头的值的文档。
   6. Wildcard Query（通配符查询） 查询指定字段包含与指定模式匹配的值的文档，其中该模式支持单字符通配符（？）和多字符通配符（），如："wildcard" : { "user" : "kiy" }
   7. Regexp Query（正则表达式查询） 查询指定的字段包含与指定的正则表达式匹配的值的文档。如："regexp":{"name.first":"s.*y"}
   8. Fuzzy Query（模糊查询） 查询指定字段包含与指定术语模糊类似的术语的文档。模糊性测量为1或2的 Levenshtein。
   9. Type Query（类型查询） 查询指定类型的文档。
   10. Ids Query（ID查询） 查询具备指定类型和 ID 的文档。

8、Mapping映射

映射索引myindex中的mytype类型，这个类型中有一个text类型的title属性和一个text类型的content属性。
（其余字段类型见文档）
PUT myindex
{
  "mappings": {
    "mytype": {
      "properties": {
        "title": {
          "type": "text"
        },
        "content": {
          "type": "text"
        }
      }
    }
  }
}

一个文档的被映射的字段类型有两种：元数据类型 和 属性(properties)， 元数据类型是每一个字段固有的，而属性是用来描述这个字段的，用法以下：

1. 1、元数据类型(能够理解成每一个类型都会有的字段！！！！)：Meta-Fields，如

• _all
• _field_names（字段名）
• _id
• _index
• _meta
• _parent
• _routing
• _source
• _type

其中：

• _all 该字段容许您搜索文件中的值不知道哪一个字段包含的值。这使其成为一个有用的选项时,开始使用一种新的数据集。但他须要消耗更多的资源，所以默认是禁用的。例如:

"query": {
    "match": {
      "_all": "john smith 1970"
    }
  }

• text 该字段用于索引全文文本，例如电子邮件的正文或产品的描述。 对这些字段进行analyzed ，即经过分析器将其转换成索引以前的各个术语列表。 分析过程容许Elasticsearch搜索每一个全文本字段中的单个单词。 文本字段不用于排序，不多用于聚合（尽管重要的术语聚合是一个显着的例外）。若是您须要索引结构化内容（如电子邮件地址，主机名，状态代码或标签），则可能您应该使用keyword字段。 对于代码或标签，您也可能应该使用keyword字段。

2. 2、字段(属性，也就是自定义的，能够指定类型和参数映射)：Fields or properties。 默认状况下，每一个字段都是被索引的(使用倒排索引)，全部字段是默认被 indexed（被索引的），这使得它们是可搜索的.能够在脚本中排序,聚合和获取字段值,可是须要不一样的搜索模式.

如

• analyzer（分析器）
• normalizer(归一化)
• boost(提高权重)
• Coerce（强制类型转换）
• copy_to（合并参数）
• doc_values（文档值）-> 默认开启，Doc values 是在 document 索引时间内构建在磁盘上的数据结构,这使得上面所说的数据访问模式成为可能.它们存储与 _source 相同的值,可是以列为主的方式存储.这使得排序和聚合效率更高。默认状况下,支持 doc values 的全部字段都是开启的.若是你肯定不须要在字段上进行排序和聚合,活从脚本中访问字段值,则能够禁用 doc values 来节省磁盘空间.
• dynamic（动态设置）-> 默认状况下,字段会动态的添加到 document 或者 document 的 inner objects（内部对象），只须要经过索引包含这个新字段的 document。
• enabled（开启字段）-> enabled 设置只能够应用于映射类型和 object 字段,致使 Elasticsearch 彻底跳过字段内容的解析.这个 JSON 仍然能够从 _source 字段中检索,可是不能以任何其余方式搜索或存储：
• fielddata（字段数据）-> 许多字段可使用 index-time，在磁盘上的 doc_values 支持这种数据访问模式, 可是 text 字段不支持 doc_values。相反,text 字段使用查询时存在于内存的数据结构 fielddata.这个数据结构是第一次将字段用于聚合,排序,或者脚本时基于需求构建的。它是经过读取磁盘上的每一个 segment（片断）的整个反向索引来构建的，将 term（词条）和 document（文档）关系反转,并将结果存储在内存中,在JVM的堆中.
• format （日期格式）
• ignore_above（忽略超越限制的字段）
• ignore_malformed（忽略格式不对的数据）
• include_in_all（是否在 _all 查询包含该字段）
• index_options（索引设置）
• index （是否创建索引，若是设置成false，则没法被搜索）
• fields（字段) -> 咱们常常会由于不一样的目的将同一个字段用不一样的方式索引。这就至关于实现了 multi-fields。例如，一个 string 类型字段能够被映射成 text 字段做为 full-text 进行搜索，同时也能够做为 keyword 字段用于排序和聚合：
• Norms （标准信息）
• null_value（空值）
• position_increment_gap（短语位置间隙）
• properties （属性）
• search_analyzer （搜索分析器）
• similarity （匹配方法）
• store（存储）-> 默认状况下，字段值会被索引使他们能搜索，但他们不会被 stored（存储）。意思就是这个字段能查询，但不能取回他的原始值。
• Term_vectors（词根信息）

fielddata 和 doc_value的比较

4.1 相同点

都要建立正排索引，数据结构相似于列式存储

都是为了能够聚合，排序之类的操做

4.2 不一样点

存储索引数据的方式不同：

fielddata: 内存存储；doc_values: OS Cache+磁盘存储

对应的字段类型不同

fielddata: 对应的字段类型是text; doc_values：对应的字段类型是keyword

针对的类型，也不同

field_data主要针对的是分词字段；doc_values针对大是不分词字段

是否开启

fielddata默认不开启；doc_values默认是开启

fields（字段） 咱们常常会由于不一样的目的将同一个字段用不一样的方式索引。这就至关于实现了 multi-fields。例如，一个 string 类型字段能够被映射成 text 字段做为 full-text 进行搜索，同时也能够做为 keyword 字段用于排序和聚合：

"lastname": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",      -->  由于fieldfata默认是关闭的，因此直接对这个字段聚合会报错，因此使用.keyword就能够进行聚合了！！！
                "ignore_above": 256
              }
            }
          }

举例！！！！：

GET /bank/account/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "prefix": {
            "firstname": "m"
          }
        }
      ]
    }
  },
  "aggs":{
    "gender":{
      "terms":{
        "field":"gender.keyword"
      },
      "aggs":{
        "avg_age":{
          "avg":{
            "field":"age"
          }
        }
      }
    }
  }
}

结果：

"aggregations": {
    "gender": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": [
        {
          "key": "F",
          "doc_count": 59,
          "avg_age": {
            "value": 30.93220338983051
          }
        },
        {
          "key": "M",
          "doc_count": 52,
          "avg_age": {
            "value": 30.23076923076923
          }
        }
      ]
    }
  }

3. 3、Dynamic Mapping（动态映射）

9、管理、监控、部署

10、词汇表

• analysis（分析） Analysis（分析）是将 full text（全文）转化为 terms（词条）的过程。使用不一样的 analyzer（分词器）， FOO BAR，Foo-Bar，foo，bar 这些短语可能都会生成 foo 和 bar 两个词条，实际的 index（索引）里面存储的就是这些 terms（词条）。针对 FoO:bAR 的 full text query（全文检索），会先将其分析成为 foo,bar 这样的词条，而后匹配存储在 index（索引）中的 term（词条）。正是这个 analysis（分析）的过程（发生在索引和搜索时）使得 elasticsearch 可以执行 full text queries（全文检索）。也能够参阅 text（文本）和 term（词条）了解更多细节信息。

• term （词条） term（词条）是elasticsearch中被索引的确切值。foo, Foo, FOO 这些term（词条）不相等。term（词条）能够经过词条搜索来检索。查询text（文本）和anaylsis（分词）获取更多信息。

• text （文本） text（文本）（或者说全文）是普通的非结构化文本，如一个段落。默认状况下，text（文本）会被analyzed（分词）成term（词条），term（词条）是实际存储在索引中的内容。文本的field（属性）必须在索引时完成analyzed（分词）来支持全文检索的功能，全文检索使用的关键词也必须在搜索时analyzed（分词）成索引时产生的相同term（词条）。查询term（词条）和analysis（分词）获取更多信息。

• cluster （集群） cluster（集群）是由拥有同一个集群名的一个或者多个节点组成。每一个集群拥有一个主节点，它由集群自行选举出来，在当前主节点挂了，能被其余节点取代。

• index （索引） index（索引）相似于关系型数据库中的表。它有一个mapping（映射）来定义索引中的fields（属性），这些属性被分组成多种type（类型）。索引是一个逻辑命名空间，它对应一到多个primary shards（主分片）和零到多个replica shards（副本分片）。

• document （文档） document（文档）是存储在elasticsearch中的json文档。相似于关系型数据库中的一行记录。每一个文档存储在一个index（索引）中，它具备一个type（类型）和一个id。文档是包含零到多个fields（属性）或者键值对的json对象（相似于其余语言中的hash/hashmap/associative array）。当一个文档被indexed（索引）的时候，它的原始json文档会被存储成_source属性，对该文档进行get或者search操做时，默认返回的就是改属性。

• term （词条） term（词条）是elasticsearch中被索引的确切值。foo, Foo, FOO 这些term（词条）不相等。term（词条）能够经过词条搜索来检索。查询text（文本）和anaylsis（分词）获取更多信息。

• text （文本） text（文本）（或者说全文）是普通的非结构化文本，如一个段落。默认状况下，text（文本）会被analyzed（分词）成term（词条），term（词条）是实际存储在索引中的内容。文本的field（属性）必须在索引时完成analyzed（分词）来支持全文检索的功能，全文检索使用的关键词也必须在搜索时analyzed（分词）成索引时产生的相同term（词条）。查询term（词条）和analysis（分词）获取更多信息。

• type （类型） type（类型）表明文档的类型，如一封邮件，一个用户，一条推文。搜索API能够经过文档类型来过滤。index（索引）能够包涵多个类型，每个type（类型）有一系列的fields（属性）。同一个index（索引）中不一样type（类型）的同名fields（属性）必须使用相同的mapping（映射）（定义文档的属性如何索引以及是文档能被搜索）。

• id 文档的ID标识一个文档。文档的index/type/id必须惟一。若是没有提供ID，elasticsearch会自动生成一个ID。（查询routing（路由）获取更多信息）

• field（属性） 一个文档包涵一系列的属性或者键值对。它的值能够是简单标量值（如字符串，整型数，日期），或者是像数组和对象同样的嵌套结构。属性相似于关系型数据库中的列。每一个属性的mapping（映射）都有其类型（不一样于document（文档）的type（类型）），代表该属性能存储成改类型的数据，例如 integer, string, object。mapping（映射）也容许你定义属性的值是否须要analyzed（分词）。

• mapping （映射） mapping（映射）相似于关系型数据库中的元数据定义。每个index（索引）对应一个mapping（映射），它定义了index（索引）中的每个type（类型），另外还有一些索引级别的设置。mapping（映射）能够显式定义，或者当一个文档进行索引时自动生成。

• node （节点） node（节点）是从属于一个elasticsearch集群的正在运行的节点。当以测试为目的时，能够在一台主机上启动多个节点，可是一般一台主机最好运行一个节点。在启动时，节点会使用广播的方式，自动感知（网络中）具备相同集群名的集群，并尝试加入它。

• primary shard （主分片） 每一个文档存储在单primary shard （主分片）中。当索引一个文档时，它会首先被索引到主分片上，而后索引到主分片的全部副本上。默认状况下，一个index（索引）有5个primary shard （主分片）。根据index（索引）的处理能力，你能够指定更少或者更多的primary shard （主分片）来扩展文档数量。当index（索引）建立以后，primary shard （主分片）的数量不可更改。查询routing（路由）获取更多信息。

• replica shard （副本分片） 每个primary shard （主分片）拥有零到多个副本。副本是primary shard （主分片）的拷贝，它的存在有两个目的：

1. 增长容错：当主分片失败时，一个replica shard（副本分片）能够提高为primary shard （主分片）
2. 提高性能：primary shard （主分片）和replica shard（副本分片）都能处理get和shearch请求。默认状况下，每一个primary shard （主分片）有一个副本，副本的个数能够动态的修改。replica shard（副本分片）不会和primary shard （主分片）分配在同一个节点上。

• routing （路由） 当你索引一个文档时，它会被存储在一个单独的主分片上。经过对routing值进行哈希计算来决定具体是哪个主分片。默认状况下，routing值是来自于文档ID，若是文档指定了一个父文档，则经过其父文档ID（保证父子文档存储在同一个分片上）。若是你不想使用默认的文档ID来做为routing值,你能够在索引时直接指定一个routing值，或者在mapping中指定一个字段的值来做为routing值。

• shard （分片） 一个Shard就是一个Lucene实例，是一个完整的搜索引擎。一个索引能够只包含一个Shard，只是通常状况下会用多个分片，能够拆分索引到不一样的节点上，分担索引压力。 shard（分片）是一个Lucene实例。它是由elasticsearch管理的低层次的工做单元。index（索引）是指向 主分片和副本分片的逻辑命名空间。除了定义index（索引）应该具备的primary shard（主分片）和replica shard（副本分片）的数量以外，你不须要对shard（分片）做其它的工做。相反，你的代码应该只处理index（索引）。elasticsearch将shards（分片）分配到整个集群的全部节点上，当节点失败时能够自动将分片迁移到其余节点或者新增的节点上。

• segment elasticsearch中的每一个分片包含多个segment，每个segment都是一个倒排索引；在查询的时，会把全部的segment查询结果汇总归并后最为最终的分片查询结果返回； 在建立索引的时候，elasticsearch会把文档信息写到内存bugffer中（为了安全，也一块儿写到translog），定时（可配置）把数据写到segment缓存小文件中，而后刷新查询，使刚写入的segment可查。 虽然写入的segment可查询，可是尚未持久化到磁盘上。所以，仍是会存在丢失的可能性的。 因此，elasticsearch会执行flush操做，把segment持久化到磁盘上并清除translog的数据（由于这个时候，数据已经写到磁盘上，不在须要了）。 当索引数据不断增加时，对应的segment也会不断的增多，查询性能可能就会降低。所以，Elasticsearch会触发segment合并的线程，把不少小的segment合并成更大的segment，而后删除小的segment。 segment是不可变的，当咱们更新一个文档时，会把老的数据打上已删除的标记，而后写一条新的文档。在执行flush操做的时候，才会把已删除的记录物理删除掉。

• source field （源属性） 在默认状况下，你索引的json document（文档）会存储在_source field（属性）中，get和search请求会返回该field（属性）。这样能够直接在搜索结果中获取原始文档对象，不须要经过ID再检索一次文档对象。

截止目前的搜索相对都很简单：单个姓名，经过年龄过滤。如今尝试下稍微高级点儿的全文搜索——一项 传统数据库确实很难搞定的任务。

搜索下全部喜欢攀岩（rock climbing）的雇员：

GET /megacorp/employee/_search
{
    "query" : {
        "match" : {
            "about" : "rock climbing"
        }
    }
}

拷贝为 CURL在 SENSE 中查看 显然咱们依旧使用以前的 match 查询在about 属性上搜索 “rock climbing” 。获得两个匹配的文档：

{
   ...
   "hits": {
      "total":      2,
      "max_score":  0.16273327,
      "hits": [
         {
            ...
            "_score":         0.16273327, 
            "_source": {
               "first_name":  "John",
               "last_name":   "Smith",
               "age":         25,
               "about":       "I love to go rock climbing",
               "interests": [ "sports", "music" ]
            }
         },
         {
            ...
            "_score":         0.016878016, 
            "_source": {
               "first_name":  "Jane",
               "last_name":   "Smith",
               "age":         32,
               "about":       "I like to collect rock albums",
               "interests": [ "music" ]
            }
         }
      ]
   }
}

相关性得分 - _score

Elasticsearch 默认按照相关性得分排序，即每一个文档跟查询的匹配程度。第一个最高得分的结果很明显：John Smith 的 about 属性清楚地写着 “rock climbing” 。

但为何 Jane Smith 也做为结果返回了呢？缘由是她的 about 属性里提到了 “rock” 。由于只有 “rock” 而没有 “climbing” ，因此她的相关性得分低于 John 的。

这是一个很好的案例，阐明了 Elasticsearch 如何 在 全文属性上搜索并返回相关性最强的结果。Elasticsearch中的 相关性 概念很是重要，也是彻底区别于传统关系型数据库的一个概念，数据库中的一条记录要么匹配要么不匹配。

短语搜索编辑 - match_phrase

找出一个属性中的独立单词是没有问题的，但有时候想要精确匹配一系列单词或者短语 。 好比， 咱们想执行这样一个查询，仅匹配同时包含 “rock” 和 “climbing” ，而且 两者以短语 “rock climbing” 的形式紧挨着的雇员记录。

为此对 match 查询稍做调整，使用一个叫作 match_phrase 的查询：

GET /megacorp/employee/_search
{
    "query" : {
        "match_phrase" : {
            "about" : "rock climbing"
        }
    }
}

拷贝为 CURL在 SENSE 中查看 毫无悬念，返回结果仅有 John Smith 的文档。

{
   ...
   "hits": {
      "total":      1,
      "max_score":  0.23013961,
      "hits": [
         {
            ...
            "_score":         0.23013961,
            "_source": {
               "first_name":  "John",
               "last_name":   "Smith",
               "age":         25,
               "about":       "I love to go rock climbing",
               "interests": [ "sports", "music" ]
            }
         }
      ]
   }
}

3.5 REST request body方法查询

curl -XGET 'localhost:9200/bank/_search?pretty' -d'

{

  "query": {

    "bool": {

      "must": [

        { "match": { "address": "mill" } },

        { "match": { "address": "lane" } }

过滤:

{

"query": {

"bool": {

  "must": { "match_all": {} },

  "filter": {

    "range": {

      "balance": {

        "gte": 20000,

        "lte": 30000

      }

聚合：

{

"size": 0,

"aggs": {

"group_by_state": {

  "terms": {

    "field": "state.keyword"

  }

}

4. setup es 暂时跳过，某些生产上的设置相当重要

5. API 规范

   5.1 Multiple Indices（多个索引）

   /g*,u*/_search      在任何以 g 或者 u 开头的索引中搜索全部的类型

   5.2 Date math support in index names（索引名称对 Date 和 Math 的支持）

   Date math 索引名称解析可让您搜索一系列 time-series indices（时间序列索引），而不是搜索全部时间序列索引并过滤结果或维护 aliases（别名）。限制搜索的索引数量减小了集群上的负载，并提升了执行性能。例如，若是您在平常日志中 searching for errors（搜索错误 )，则可使用 date math name 模板将搜索限制为过去两天。

6. document api

7. search api

8. aggregation api 聚合api

9. index api 索引api

10. cat api

11. cluster api

12. 查询 DSL Elasticsearch提供了一个基于JSON的完整的查询DSL来定义查询。将查询DSL视为查询的AST，由两种类型的子句组成：

叶查询子句

叶查询子句在特定查询中查找特定值，例如匹配、项值、范围查询。这些查询均可以给本身使用。

复合查询子句

复合查询子句包装其余叶子或复合查询，用于以逻辑方式组合多个查询（例如bool或dis_max查询），或更改其行为（如constant_score查询）。

查询子句的行为有所不一样，具体取决于它们是在查询上下文仍是过滤器上下文中使用。

13. mapping 映射