【ElasticSearch】 核心详解（五）

文档 

　　在Elasticsearch中，文档以JSON格式进行存储，可以是复杂的结构，如:

{
    "_index": "test",
    "_type": "doc",
    "_id": "1005",
    "_version": 2,
    "_seq_no": 10,
    "_primary_term": 1,
    "found": true,
    "_source": {
        "id": 1005,
        "name": "孙七",
        "age": 37,
        "sex": "女",
        "card": {
            "card_number": "123456789"
        }
    }
}

　　其中，card是一个复杂对象，嵌套的Card对象。

元数据(metadata)

　　一个文档不只有数据。它还包含了元数据(metadata)——关于文档的信息。三个必须的元数据节点是:

节点	说明
_index	文档存储的地方
_type	文档代表的对象的类
_id	文档的唯一标识

　　_index

　　索引(index)类似于关系型数据库里的“数据库”——它是我们存储和索引关联数据的地方。

　　提示: 事实上，我们的数据被存储和索引在分片(shards)中，索引只是一个把一个或多个分片分组在一起的逻辑空 间。然而，这只是一些内部细节——我们的程序完全不用关心分片。对于我们的程序而言，文档存储在索引 (index)中。剩下的细节由Elasticsearch关心既可。

　　_type

　　在应用中，我们使用对象表示一些“事物”，例如一个用户、一篇博客、一个评论，或者一封邮件。每个对象都属于一 个类(class)，这个类定义了属性或与对象关联的数据。 user 类的对象可能包含姓名、性别、年龄和Email地址。

　　在关系型数据库中，我们经常将相同类的对象存储在一个表里，因为它们有着相同的结构。同理，在Elasticsearch 中，我们使用相同类型(type)的文档表示相同的“事物”，因为他们的数据结构也是相同的。

　　每个类型(type)都有自己的映射(mapping)或者结构定义，就像传统数据库表中的列一样。所有类型下的文档被存储 在同一个索引下，但是类型的映射(mapping)会告诉Elasticsearch不同的文档如何被索引。

　　_id

　　id仅仅是一个字符串，它与 _index 和 _type 组合时，就可以在Elasticsearch中唯一标识一个文档。当创建一个文 档，你可以自定义 _id ，也可以让Elasticsearch帮你自动生成(32位长度)。

查询响应

1、pretty

　　可以在查询url后面添加pretty参数，使得返回的json更易查看。

　　

2、指定响应字段

　　在响应的数据中，如果我们不需要全部的字段，可以指定某些需要的字段进行返回。

GET /test/doc/1005?_source=id,name&pretty

#响应
{
  "_index" : "test",
  "_type" : "doc",
  "_id" : "1005",
  "_version" : 2,
  "_seq_no" : 10,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "name" : "孙七",
    "id" : 1005
  }
}

　　如不需要返回元数据，仅仅返回原始数据，可以这样:

GET /test/doc/1005/_source

#响应
{
  "id" : 1005,
  "name" : "孙七",
  "age" : 37,
  "sex" : "女",
  "card" : {
    "card_number" : "123456789"
  }
}

　　还可以这样:

GET /test/doc/1005/_source?_source=id,name

#响应
{
  "id" : 1005,
  "name" : "孙七"
}

3、判断文档是否存在

　　如果我们只需要判断文档是否存在，而不是查询文档内容，那么可以这样:

HEAD /test/doc/1005

　　判断响应状态码

4、批量操作

　　1、批量查询

POST /test/doc/_mget

{
   "ids" : [ "1001", "1003" ]
}

　　效果如下：

　　

　　2、_bulk操作

　　在Elasticsearch中，支持批量的插入、修改、删除操作，都是通过_bulk的api完成的。

　　请求格式如下:(请求格式不同寻常)

{ action: { metadata }}\n 
{ request body }\n 
{ action: { metadata }}\n 
{ request body }\n 
...

　　批量插入数据:

POST /test2/doc/_bulk

{"create":{"_index":"test2","_type":"doc","_id":2001}} 
{"id":2001,"name":"name1","age": 20,"sex": "男"} 
{"create":{"_index":"test2","_type":"doc","_id":2002}} 
{"id":2002,"name":"name2","age": 20,"sex": "男"} 
{"create":{"_index":"test2","_type":"doc","_id":2003}} 
{"id":2003,"name":"name3","age": 20,"sex": "男"}

　　效果如下：

　　　　

　　批量删除:

POST /test2/doc/_bulk

{"delete":{"_index":"test2","_type":"doc","_id":2001}}
{"delete":{"_index":"test2","_type":"doc","_id":2002}}
{"delete":{"_index":"test2","_type":"doc","_id":2003}}

　　其他操作就类似了。 一次请求多少性能最高?

　　整个批量请求需要被加载到接受我们请求节点的内存里，所以请求越大，给其它请求可用的内存就越小。有一 个最佳的bulk请求大小。超过这个大小，性能不再提升而且可能降低。 最佳大小，当然并不是一个固定的数字。它完全取决于你的硬件、你文档的大小和复杂度以及索引和搜索的负 载。 幸运的是，这个最佳点(sweetspot)还是容易找到的:试着批量索引标准的文档，随着大小的增长，当性能开始 降低，说明你每个批次的大小太大了。开始的数量可以在1000~5000个文档之间，如果你的文档非常大，可以 使用较小的批次。 通常着眼于你请求批次的物理大小是非常有用的。一千个1kB的文档和一千个1MB的文档大不相同。一个好的 批次最好保持在5-15MB大小间。

5、分页

　　和SQL使用 LIMIT 关键字返回只有一页的结果一样，Elasticsearch接受 from 和 size 参数:

1. size: 结果数，默认10

2. 2  from: 跳过开始的结果数，默认0

　　如果你想每页显示5个结果，页码从1到3，那请求如下:

GET /_search?size=5
GET /_search?size=5&from=5
GET /_search?size=5&from=10

　　应该当心分页太深或者一次请求太多的结果。结果在返回前会被排序。

　　但是记住一个搜索请求常常涉及多个分 片。每个分片生成自己排好序的结果，它们接着需要集中起来排序以确保整体排序正确。

　　在集群系统中深度分页

　　为了理解为什么深度分页是有问题的，让我们假设在一个有5个主分片的索引中搜索。当我们请求结果的第一 页(结果1到10)时，每个分片产生自己最顶端10个结果然后返回它们给请求节点(requesting node)，它再 排序这所有的50个结果以选出顶端的10个结果。

　　现在假设我们请求第1000页——结果10001到10010。工作方式都相同，不同的是每个分片都必须产生顶端的 10010个结果。然后请求节点排序这50050个结果并丢弃50040个!

6、映射

　　前面我们创建的索引以及插入数据，都是由Elasticsearch进行自动判断类型，有些时候我们是需要进行明确字段类型的，否则，自动判断的类型和实际需求是不相符的。

　　自动判断的规则如下:

JSON type	Field type
Boolean: true or false	"boolean"
Whole number: 123	"long"
Floating point: 123.45	"double"
String, valid date: "2014-09-15"	"date"
String: "foo bar"	"string"

　　

　　Elasticsearch中支持的类型如下:

类型	表示的数据类型
String	string,text,keyword
Whole number	byte,short,integer,long
Floating point	float,double
Boolean	boolean
Date	date

　　

• string类型在ElasticSearch 旧版本中使用较多，从ElasticSearch 5.x开始不再支持string，由text和 keyword类型替代。
• text 类型，当一个字段是要被全文搜索的，比如Email内容、产品描述，应该使用text类型。设置text类型 以后，字段内容会被分析，在生成倒排索引以前，字符串会被分析器分成一个一个词项。text类型的字段 不用于排序，很少用于聚合。 
• keyword类型适用于索引结构化的字段，比如email地址、主机名、状态码和标签。如果字段需要进行过 滤(比如查找已发布博客中status属性为published的文章)、排序、聚合。keyword类型的字段只能通过精 确值搜索到。

　　创建明确类型的索引:

PUT /person


{
    "settings": {
        "index": {
            "number_of_shards": "2",
            "number_of_replicas": "0"
        }
    },
    "mappings": {
        "properties": {
            "name": {
                "type": "text"
            },
            "age": {
                "type": "integer"
            },
            "mail": {
                "type": "keyword"
            },
            "hobby": {
                "type": "text"
            }
        }
    }
}

　　效果如下：

　　

　　查看映射:

GET /person/_mapping

　　效果如下：

　　

　　插入数据:

POST /person/_bulk

{"index":{"_index":"person"}}
{"name":"张三","age": 20,"mail": "111@qq.com","hobby":"羽毛球、乒乓球、足球"} 
{"index":{"_index":"person"}}
{"name":"李四","age": 21,"mail": "222@qq.com","hobby":"羽毛球、乒乓球、足球、篮球"} 
{"index":{"_index":"person"}}
{"name":"王五","age": 22,"mail": "333@qq.com","hobby":"羽毛球、篮球、游泳、听音乐"} 
{"index":{"_index":"person"}}
{"name":"赵六","age": 23,"mail": "444@qq.com","hobby":"跑步、游泳"} 
{"index":{"_index":"person"}}
{"name":"孙七","age": 24,"mail": "555@qq.com","hobby":"听音乐、看电影"}

　　测试搜索:

POST /person/_search

{
    "query": {
        "match": {
            "hobby": "音乐"
        }
    }
}

　　效果如下：　　

　　　　

7、结构化查询

7.1、term查询

　　term 主要用于精确匹配哪些值，比如数字，日期，布尔值或 not_analyzed 的字符串(未经分析的文本数据类型):

{ "term": { "age": 26 }} 
{ "term": { "date": "2014-09-01" }} 
{ "term": { "public": true }} 
{ "term": { "tag": "full_text" }}

　　示例:

POST /person/_search

{
    "query": {
        "term": {
            "age": 20
        }
    }
}

　　效果如下：

　　

7.2、terms查询

　　terms 跟 term 有点类似，但 terms 允许指定多个匹配条件。 如果某个字段指定了多个值，那么文档需要一起去做匹配:

　　格式：

{
    "terms": {
        "tag": [
            "search",
            "full_text",
            "nosql"
        ]
    }
}

　　示例：

POST /person/_search

{
    "query": {
        "terms": {
            "age": [20, 21]
        }
    }
}

　　效果如下：

　　

 7.3、range查询

　　range 过滤允许我们按照指定范围查找一批数据:

{
    "range": {
        "age": {
            "gt": 20,
            "lt": 30
        }
    }
}

　　范围操作符包含:

• gt ::大于
• gte :: 大于等于 
• lt ::小于
• lte :: 小于等于

　　示例：

POST /person/_search

{
    "query": {
        "range": {
            "age": {
                "gt": 20,
                "lt": 30
            }
        }
    }
}

　　效果如下：

　　

7.4、exists 查询

　　exists 查询可以用于查找文档中是否包含指定字段或没有某个字段，类似于SQL语句中的IS_NULL条件

{
    "exists": {
        "field": "title"
    }
}

　　示例：

POST /person/_search

{
    "query": {
        "exists": {
            "field": "name"
        }
    }
}

　　效果如下：

　　

6.5、match查询

　　match 查询是一个标准查询，不管你需要全文本查询还是精确查询基本上都要用到它。

　　如果你使用 match 查询一个全文本字段，它会在真正查询之前用分析器先分析 match 一下查询字符:

{
    "match": {
        "tweet": "About Search"
    }
}

　　如果用match下指定了一个确切值，在遇到数字，日期，布尔值或者not_analyzed 的字符串时，它将为你搜索你 给定的值:

　　示例：

POST /person/_search

{
    "query": {
        "match": {
            "name": "孙七"
        }
    }
}

　　效果如下：

　　

7.6、bool查询

• bool 查询可以用来合并多个条件查询结果的布尔逻辑，它包含一下操作符: must :: 多个查询条件的完全匹配,相当于 and 。
• must_not :: 多个查询条件的相反匹配，相当于 not 。
• should :: 至少有一个查询条件匹配, 相当于 or 。
• 这些参数可以分别继承一个查询条件或者一个查询条件的数组:

{
    "bool": {
        "must": {
            "term": {
                "folder": "inbox"
            }
        },
        "must_not": {
            "term": {
                "tag": "spam"
            }
        },
        "should": []
    }
}

　　示例效果：

　　

7.7、过滤查询

　　前面讲过结构化查询，Elasticsearch也支持过滤查询，如term、range、match等。

　　示例:查询年龄为20岁的用户。

　　

　　查询和过滤的对比

• 一条过滤语句会询问每个文档的字段值是否包含着特定值。
• 查询语句会询问每个文档的字段值与特定值的匹配程度如何。
  • 一条查询语句会计算每个文档与查询语句的相关性，会给出一个相关性评分 _score，并且 按照相关性对匹配到的文档进行排序。 这种评分方式非常适用于一个没有完全配置结果的全文本搜索。
• 一个简单的文档列表，快速匹配运算并存入内存是十分方便的， 每个文档仅需要1个字节。这些缓存的过滤结果 集与后续请求的结合使用是非常高效的。
• 查询语句不仅要查找相匹配的文档，还需要计算每个文档的相关性，所以一般来说查询语句要比 过滤语句更耗 时，并且查询结果也不可缓存。

　　建议:

　　做精确匹配搜索时，最好用过滤语句，因为过滤语句可以缓存数据。