这里写自定义目录标题

• ES核心概念
• • 索引 index
  • 映射 mapping
  • 字段Field
  • 字段类型 Type
  • 文档 document
  • 集群 cluster
  • 节点 node
  • 分片和副本 shards&replicas
  • • 分片
    • 副本
• 基本操作
• • 索引
  • • 创建索引
    • 查询索引
    • 删除索引
  • 文档
  • • 添加文档
    • 查询文档
    • 删除文档
    • 条件查询文档
    • • 查询当前类型中的所有文档 _search
      • 条件查询, 如要查询age等于28岁的 _search?q=*:***
      • 范围查询
      • 根据多个ID进行批量查询 _mget
      • 查询年龄小于等于28岁的 :<=
      • 查询年龄大于28前的 :>
      • 分页查询 from=*&size=*
      • 对查询结果只输出某些字段 _source=字段,字段
      • 对查询结果排序 sort=字段:desc/asc
• DSL语法（重点）
• • DSL类型：查询DSL（query DSL）和过滤DSL（filter DSL）
  • • query DSL
    • filter DSL
    • 对比总结
  • 无查询条件
  • 有查询条件
  • • 叶子条件查询(单字段查询条件)
    • • 模糊匹配
      • • match查询
        • • match查询keyword字段
          • match查询text字段
      • 精确匹配
      • 组合条件查询(多条件查询)
      • 连接查询(多文档合并查询)
      • 总结:
• 提高搜索结果精准度
• • minimum_should_match
  • boost权重控制
  • 基于dis_max实现best fields策略进行多字段搜索
  • 基于tie_breaker参数优化dis_max搜索效果

ES核心概念

索引 index

一个索引就是一个拥有几分相似特征的文档的集合。比如说，可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引
一个索引由一个名字来标识（必须全部是小写字母的），并且当我们要对对应于这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字

映射 mapping

ElasticSearch中的映射（Mapping）用来定义一个文档
mapping是处理数据的方式和规则方面做一些限制，如某个字段的数据类型、默认值、分词器、是否被索引等等，这些都是映射里面可以设置的

字段Field

相当于是数据表的字段|列

字段类型 Type

每一个字段都应该有一个对应的类型，例如：Text、Keyword、Byte等

文档 document

一个文档是一个可被索引的基础信息单元，类似一条记录。文档以JSON（Javascript Object Notation）格式来表示；

集群 cluster

一个集群就是由一个或多个节点组织在一起，它们共同持有整个的数据，并一起提供索引和搜索功能

节点 node

一个节点是集群中的一个服务器，作为集群的一部分，它存储数据，参与集群的索引和搜索功能
一个节点可以通过配置集群名称的方式来加入一个指定的集群。默认情况下，每个节点都会被安排加入到一个叫做“elasticsearch”的集群中
这意味着，如果在网络中启动了若干个节点，并假定它们能够相互发现彼此，它们将会自动地形成并加入到一个叫做“elasticsearch”的集群中
在一个集群里，可以拥有任意多个节点。而且，如果当前网络中没有运行任何Elasticsearch节点，这时启动一个节点，会默认创建并加入一个叫做“elasticsearch”的集群。

分片和副本 shards&replicas

分片

一个索引可以存储超出单个结点硬件限制的大量数据。比如，一个具有10亿文档的索引占据1TB的磁盘空间，而任一节点都没有这样大的磁盘空间；或者单个节点处理搜索请求，响应太慢。

为了解决这个问题，Elasticsearch提供了将索引划分成多份的能力，这些份就叫做分片

当创建一个索引的时候，可以指定你想要的分片的数量。

每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。

分片很重要，主要有两方面的原因：

1. 允许水平分割/扩展你的内容容量
2. 允许在分片之上进行分布式的、并行的操作，进而提高性能/吞吐量

至于一个分片怎样分布，它的文档怎样聚合回搜索请求，是完全由Elasticsearch管理的，对于作为用户来说，这些都是透明的。

副本

在一个网络/云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的，Elasticsearch允许你创建分片的一份或多份拷贝，这些拷贝叫做副本分片，或者直接叫副本。

副本之所以重要，有两个主要原因：

1. 在分片/节点失败的情况下，提供了高可用性。
   注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的
2. 扩展搜索量/吞吐量，因为搜索可以在所有的副本上并行运行

每个索引可以被分成多个分片。一个索引有0个或者多个副本。
一旦设置了副本，每个索引就有了主分片和副本分片，分片和副本的数量可以在索引创建的时候指定。
在索引创建之后，可以在任何时候动态地改变副本的数量，但是不能改变分片的数量

基本操作

索引

创建索引

格式: PUT /索引名称

举例: PUT /es_db

查询索引

格式: GET /索引名称

举例: GET /es_db

删除索引

格式: DELETE /索引名称

举例: DELETE /es_db		 

文档

添加文档

格式: PUT /索引名称/类型/id

举例:
PUT /es_db/_doc/1
{
"name": "张三",
"sex": 1,
"age": 25,
"address": "广州天河公园",
"remark": "java developer"
}

备注：
POST和PUT都能起到创建/更新的作用

1. 需要注意的是PUT需要对一个具体的资源进行操作也就是要确定id才能进行更新/创建，而POST是可以针对整个资源集合进行操作的，如果不写id就由ES生成一个唯一id进行创建新文档，如果填了id那就针对这个id的文档进行创建/更新
2. PUT只会将json数据都进行替换, POST只会更新相同字段的值
3. PUT与DELETE都是幂等性操作, 即不论操作多少次, 结果都一样

查询文档

格式: GET /索引名称/类型/id

举例: GET /es_db/_doc/1

删除文档

格式: DELETE /索引名称/类型/id

举例: DELETE /es_db/_doc/1

条件查询文档

查询当前类型中的所有文档 _search

格式: GET /索引名称/类型/_search
举例: GET /es_db/_doc/_search
SQL: select * from student

条件查询, 如要查询age等于28岁的 _search?q=:**

格式: GET /索引名称/类型/_search?q=:**
举例: GET /es_db/_doc/_search?q=age:28
SQL: select * from student where age = 28

范围查询

如要查询age在25至26岁之间的 _search?q=*[ TO ] 注意: TO 必须为大写
格式: GET /索引名称/类型/_search?q=*[25 TO 26]
举例: GET /es_db/_doc/_search?q=age[25 TO 26]
SQL: select * from student where age between 25 and 26

根据多个ID进行批量查询 _mget

格式: GET /索引名称/类型/_mget
举例: GET /es_db/_doc/_mget
{
“ids”:[“1”,“2”]
}
SQL: select * from student where id in (1,2)

查询年龄小于等于28岁的 :<=

格式: GET /索引名称/类型/_search?q=age:<=**
举例: GET /es_db/_doc/_search?q=age:<=28
SQL: select * from student where age <= 28

查询年龄大于28前的 :>

格式: GET /索引名称/类型/_search?q=age:>**
举例: GET /es_db/_doc/_search?q=age:>28
SQL: select * from student where age > 28

分页查询 from=&size=

格式: GET /索引名称/类型/_search?q=age[25 TO 26]&from=0&size=1
举例: GET /es_db/_doc/_search?q=age[25 TO 26]&from=0&size=1
SQL: select * from student where age between 25 and 26 limit 0, 1

对查询结果只输出某些字段 _source=字段,字段

格式: GET /索引名称/类型/_search?_source=字段,字段
举例: GET /es_db/_doc/_search?_source=name,age
SQL: select name,age from student

对查询结果排序 sort=字段:desc/asc

格式: GET /索引名称/类型/_search?sort=字段 desc
举例: GET /es_db/_doc/_search?sort=age:desc
SQL: select * from student order by age desc

DSL语法（重点）

领域专用语言（Domain Specific Language），Elasticsearch提供了基于JSON的DSL来定义查询。
DSL由叶子查询子句和复合查询子句两种子句组成。

DSL类型：查询DSL（query DSL）和过滤DSL（filter DSL）

query DSL

在查询上下文中，查询会回答这个问题——“这个文档匹不匹配这个查询，它的相关度高么？”

如何验证匹配很好理解，如何计算相关度呢？ES中索引的数据都会存储一个_score分值，分值越高就代表越匹配。另外关于某个搜索的分值计算还是很复杂的，因此也需要一定的时间。

filter DSL

在过滤器上下文中，查询会回答这个问题——“这个文档匹不匹配？”

答案很简单，是或者不是。它不会去计算任何分值，也不会关心返回的排序问题，因此效率会高一点。

过滤上下文 是在使用filter参数时候的执行环境，比如在bool查询中使用must_not或者filter

另外，经常使用过滤器，ES会自动的缓存过滤器的内容，这对于查询来说，会提高很多性能。

对比总结

• query DSL
  • 计算相关度
  • 性能较低
• filter DSL
  • 不计算相关度
  • 性能较高

无查询条件

无查询条件是查询所有，默认是查询所有的，或者使用match_all表示所有

GET /es_db/_doc/_search
{
"query":{
"match_all":{}
}
}

有查询条件

叶子条件查询(单字段查询条件)

模糊匹配

模糊匹配主要是针对文本类型的字段，文本类型的字段会对内容进行分词，对查询时，也会对搜索条件进行分词，然后通过倒排索引查找到匹配的数据，模糊匹配主要通过match等参数来实现
match : 通过match关键词模糊匹配条件内容
prefix : 前缀匹配
regexp : 通过正则表达式来匹配数据

match的复杂用法
match条件还支持以下参数：
query : 指定匹配的值
operator : 匹配条件类型
and : 条件分词后都要匹配
or : 条件分词后有一个匹配即可(默认)
minmum_should_match : 指定最小匹配的数量

match查询

match查询keyword字段

match会被分词，而keyword不会被分词，match的需要跟keyword的完全匹配可以。

match查询text字段

match分词，text也分词，只要match的分词结果和text的分词结果有相同的就匹配。

精确匹配

term : 单个条件相等
terms : 单个字段属于某个值数组内的值
range : 字段属于某个范围内的值
exists : 某个字段的值是否存在
ids : 通过ID批量查询

POST /es_db/_doc/_search
{
"query": {
"term": {
"name": "admin"
}
}
}

组合条件查询(多条件查询)

组合条件查询是将叶子条件查询语句进行组合而形成的一个完整的查询条件
bool : 各条件之间有and,or或not的关系
must : 各个条件都必须满足，即各条件是and的关系
should : 各个条件有一个满足即可，即各条件是or的关系
must_not : 不满足所有条件，即各条件是not的关系
filter : 不计算相关度评分，它不计算_score即相关度评分，效率更高
constant_score : 不计算相关度评分
must/filter/shoud/must_not 等的子条件是通过 term/terms/range/ids/exists/match 等叶子条件为参数的
注：以上参数，当只有一个搜索条件时，must等对应的是一个对象，当是多个条件时，对应的是一个数组

连接查询(多文档合并查询)

父子文档查询：parent/child
嵌套文档查询: nested

总结:

1. match

match：模糊匹配，需要指定字段名，但是输入会进行分词，比如"hello world"会进行拆分为hello和world，然后匹配，如果字段中包含hello或者world，或者都包含的结果都会被查询出来，也就是说match是一个部分匹配的模糊查询。查询条件相对来说比较宽松。

2. term

term: 这种查询和match在有些时候是等价的，比如我们查询单个的词hello，那么会和match查询结果一样，但是如果查询"hello world"，结果就相差很大，因为这个输入不会进行分词，就是说查询的时候，是查询字段分词结果中是否有"hello world"的字样，而不是查询字段中包含"hello world"的字样。当保存数据"hello world"时，elasticsearch会对字段内容进行分词，“hello world"会被分成hello和world，不存在"hello world”，因此这里的查询结果会为空。这也是term查询和match的区别。

3. match_phase

match_phase：会对输入做分词，但是需要结果中也包含所有的分词，而且顺序要求一样。以"hello world"为例，要求结果中必须包含hello和world，而且还要求他们是连着的，顺序也是固定的，hello that world不满足，world hello也不满足条件。

4. query_string

query_string：和match类似，但是match需要指定字段名，query_string是在所有字段中搜索，范围更广泛。

提高搜索结果精准度

minimum_should_match

minimum_should_match表示最小匹配多少个才返回结果。
minimum_should_match可以使用百分比或固定数字。百分比代表query搜索条件中词条百分比，如果无法整除，向下匹配（如，query条件有3个单词，如果使用百分比提供精准度计算，那么是无法除尽的，如果需要至少匹配两个单词，则需要用67%来进行描述。如果使用66%描述，ES则认为匹配一个单词即可。）。固定数字代表query搜索条件中的词条，至少需要匹配多少个。

GET /es_db/_search
{
"query": {
"match": {
"remark": {
"query": "java architect assistant",
"minimum_should_match": "68%"
}
}
}
}

boost权重控制

boost可以将某个搜索条件的权重加大，默认情况下，搜索条件的权重都是一样的，都是1。

GET /forum/article/_search 
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "title": {
              "query": "elasticsearch"
            }
          }
        },
        {
          "match": {
            "title": {
              "query": "spark",
              "boost": 5
            }
          }
        }
      ]
    }
  }
}

基于dis_max实现best fields策略进行多字段搜索

dis_max 即分离最大化查询（Disjunction Max Query）
dis_max原理： 直接获取搜索的多条件中的，单条件query相关度分数最高的数据，以这个数据做相关度排序。

best fields最佳字段策略： 搜索的document中的某一个field，尽可能多的匹配搜索条件。与之相反的是，尽可能多的字段匹配到搜索条件（most fields策略）。
优点：精确匹配的数据可以尽可能的排列在最前端，且可以通过minimum_should_match来去除长尾数据，避免长尾数据字段对排序结果的影响。
长尾数据比如说我们搜索4个关键词，但很多文档只匹配1个，也显示出来了，这些文档其实不是我们想要的
缺点：相对排序不均匀。

应用场景：可自动选择最佳搜索字段
核心原理：搜索java springboot ，使用dis_max策略后，会将java springboot连着一起出现的文档排在前面。

基于tie_breaker参数优化dis_max搜索效果

dis_max是将多个搜索query条件中相关度分数最高的用于结果排序，忽略其他query分数，在某些情况下，可能还需要其他query条件中的相关度介入最终的结果排序，这个时候可以使用tie_breaker参数来优化dis_max搜索。
tie_breaker参数代表的含义是：将其他query搜索条件的相关度分数乘以参数值，再参与到结果排序中。如果不定义此参数，相当于参数值为0。所以其他query条件的相关度分数被忽略。