一、文档
在Elasticsearch中，文档以JSON格式进行存储，可以是复杂的结构
元数据(metadata)
一个文档不只有数据。它还包含了元数据(metadata)——关于文档的信息。三个必须的元数据节点是：
| 节点 | 说明 |
| _index | 文档存储的地方 |
| _type | 文档代表的对象的类 |
| _id | 文档的唯一标识 |
_index
索引(index)类似于关系型数据库里的“数据库”——它是我们存储和索引关联数据的地方
事实上，我们的数据被存储和索引在分片(shards)中，索引只是一个把一个或多个分片分组在一起的逻辑空间。然而，这只是一些内部细节——我们的程序完全不用关心分片。对于我们的程序而言，文档存储在索引(index)中。剩下的细节由Elasticsearch关心既可。
_type
在应用中，我们使用对象表示一些“事物”，例如一个用户、一篇博客、一个评论，或者一封邮件。每个对象都属于一个类(class)，这个类定义了属性或与对象关联的数据。user 类的对象可能包含姓名、性别、年龄和Email地址。
在关系型数据库中，我们经常将相同类的对象存储在一个表里，因为它们有着相同的结构。同理，在Elasticsearch中，我们使用相同类型(type)的文档表示相同的“事物”，因为他们的数据结构也是相同的。
每个类型(type)都有自己的映射(mapping)或者结构定义，就像传统数据库表中的列一样。所有类型下的文档被存储在同一个索引下，但是类型的映射(mapping)会告诉Elasticsearch不同的文档如何被索引。
_type 的名字可以是大写或小写，不能包含下划线或逗号。我们将使用blog 做为类型名。
_id
id仅仅是一个字符串，它与_index 和_type 组合时，就可以在Elasticsearch中唯一标识一个文档。当创建一个文档，你可以自定义_id ，也可以让Elasticsearch帮你自动生成（32位长度）。
二、查询响应
2.1 pretty:可以在查询url后面添加pretty参数，使得返回的json更易查看。如：GET /haoke/user/d5oEnngBSJf5M_62xr_r?pretty
2.2 指定响应字段：
GET /haoke/user/1001?_source=name,age 响应： { "_index": "haoke", "_type": "user", "_id": "1001", "_version": 3, "found": true, "_source": { "name": "张三", "age": 23 } } #去掉元数据： GET /haoke/user/1001/_source 返回： { "id": 1001, "name": "张三", "age": 23, "sex": "女" }
三、判断文档是否存在：
如果我们只需要判断文档是否存在，而不是查询文档内容，那么可以这样：HEAD /haoke/user/1005
无返回结果，从返回响应码判断，404表示不存在
四、批量操作
有些情况下可以通过批量操作以减少网络请求。如：批量查询、批量插入数据
批量查询:某一条数据不存在，不影响整体响应，需要通过found的值进行判断是否查询到数据。如：
POST /haoke/user/_mget { "ids" : [ "1001", "1003" ] }
_bulk操作:批量增删改
请求格式如下：（请求格式不同寻常）
{ action: { metadata }}\n
{ request body }\n
{ action: { metadata }}\n
{ request body }\n
...
批量插入数据:
POST /haoke/user/_bulk {"create":{"_index":"haoke","_type":"user","_id":2001}} {"id":2001,"name":"name1","age": 20,"sex": "男"} {"create":{"_index":"haoke","_type":"user","_id":2002}} {"id":2002,"name":"name2","age": 20,"sex": "男"} {"create":{"_index":"haoke","_type":"user","_id":2003}} {"id":2003,"name":"name3","age": 20,"sex": "男"}
批量删除：
{"delete":{"_index":"haoke","_type":"user","_id":2001}}
{"delete":{"_index":"haoke","_type":"user","_id":2002}}
一次请求多少性能最高？
- 整个批量请求需要被加载到接受我们请求节点的内存里，所以请求越大，给其它请求可用的内存就越小。有一个最佳的bulk请求大小。超过这个大小，性能不再提升而且可能降低。
- 最佳大小，当然并不是一个固定的数字。它完全取决于你的硬件、你文档的大小和复杂度以及索引和搜索的负载。
- 幸运的是，这个最佳点(sweetspot)还是容易找到的：试着批量索引标准的文档，随着大小的增长，当性能开始降低，说明你每个批次的大小太大了。开始的数量可以在1000~5000个文档之间，如果你的文档非常大，可以使用较小的批次。
- 通常着眼于你请求批次的物理大小是非常有用的。一千个1kB的文档和一千个1MB的文档大不相同。一个好的批次最好保持在5-15MB大小间。
五、分页
和SQL使用LIMIT 关键字返回只有一页的结果一样，Elasticsearch接受from 和size 参数
size: 结果数，默认10
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个
你可以看到在分布式系统中，排序结果的花费随着分页的深入而成倍增长。这也是为什么网络搜索引擎中任何语句不能返回多于1000个结果的原因。
六、映射
前面我们创建的索引以及插入数据，都是由Elasticsearch进行自动判断类型，有些时候我们是需要进行明确字段类型
的，否则，自动判断的类型和实际需求是不相符的
自动判断的规则如下：
Elasticsearch中支持的类型如下：
string类型在ElasticSearch 旧版本中使用较多，从ElasticSearch 5.x开始不再支持string，由text和keyword类型替代。
- text 类型，当一个字段是要被全文搜索的，比如Email内容、产品描述，应该使用text类型。设置text类型以后，字段内容会被分析，在生成倒排索引以前，字符串会被分析器分成一个一个词项。text类型的字段不用于排序，很少用于聚合。
- keyword类型适用于索引结构化的字段，比如email地址、主机名、状态码和标签。如果字段需要进行过滤(比如查找已发布博客中status属性为published的文章)、排序、聚合。keyword类型的字段只能通过精确值搜索到。
创建明确类型的索引：
PUT /itcast { "settings": { "index": { "number_of_shards": "2", "number_of_replicas": "0" } }, "mappings": { "person": { "properties": { "name": { "type": "text" }, "age": { "type": "integer" }, "mail": { "type": "keyword" }, "hobby": { "type": "text" } } } } }
查看映射：GET /itcast/_mapping
七、结构化查询
7.1、term查询
