索引管理
创建索引
创建一个名为blog的索引命令如下，注意不能出现大写字母
PUT blog
响应结果:
"acknowledged": true,
"shards acknowledged": true
返回结果显示acknowledged 的值为true, 说明新建索引成功。
Elasticsearch 默认给一个索引设置5 个分片1 个副本，一个索引的分片数一经指定后就不
能再修改，副本数可以通过命令随时修改。如果想创建自定义分片数和副本数的索引，可以通
过setting 参数在索引时设置初始化信息。以创建3 个分片0 个副本名为blog 的索引为例，命
令如下：
PUT blog"settings":
{"number_of_shards": 3,nnumber_of_replicas": 0}
更新副本数
Elasticsearch 支持修改一个已存在索引的副本数，把blog 索引的副本数设置为2,命令如下:
PUT blog/_settings
{"number_of_replicas": 2}
读写权限
除了设置分片和副本，还可以对索引的读写操作进行限制，下面是三个读写权限的参数:
• blocks.read_only:true 设置当前索引只允许读不允许写或者更新。
• blocks.readitrue 禁止对当前索引进行读操作。
• blocks.write:true 禁止对当前索引进行写操作。
查看索引
删除索引
DELETE blog
如果删除成功，会有以下响应:
"acknowledged": true
关闭索引
POST blog/_close
索引关闭后，Head 插件中会显示关闭状态的索引，已关闭的索引不能进行读写操作。
个关闭的索引可以重新开启，命令如下：
POST blog/_open
同时关闭或开启多个索引也是允许的
POST testa,testb,teste/ close
索引的开关操作也支持通配符和all , 关闭集群中所有索引的命令如下:
POST all/ close
POST test*/ close
复制索引
目标索引不会复制源索引中的配置信息，_rdndex 操作之前需要设置目标索引的分片数、副本
数等信息。把blog 索引的文档复制到blog_new 索引中的命令如下：
POST reindex
{
"source": { "index": "blog"},
"dest": {"index": "blog_news"}
}
索引别名
索引别名就是给一个索引或者多个索引起的另一个名字。为名为test 1 的索引创建别名
alias1 , 命令格式如下：
查看某个索引的别名
GET /blog/ aliases
查看某个别名：mytest 对应哪些索引
GET /mytest/_ aliases
查看ES集群所有可用的别名：
GET /_aliases
文档管理
新建文档
准备一条JSON 格式博客文章，包括文章的id 标题、发布时间、文章内容。
PUT blog/article/1
{
"id": 1,
"title": "Git 简介" ,
"posttime": 2017-05-01 ,
"content": "Git 是一款免费、开源的分布式版本控制系统"
}
正确返回值
index": "blog",
type": "article",
id": "1
_version":
result": "created",
—shards": {
"total": 1,
"successful": 1,
"failed": 0 }，
"created": true
如果不指定文档的id Elasticsearch 会自动生成它，把上面的命令去掉id 参数，然后再次
执行索引文档命令：
POST blog/article
{"id": 1, "title": "Git 简介"， "posttime": "2017-05-01", "content": "Git 是一款免费、开源的分布式版本控制系统"}
响应结果
从响应结果中可以看到文档创建成功了，id 是自动生成的字符串。
获取文档
GET blog/article/1
结果如下
更新文档
查询更新
删除文档
DELETE blog/article/1
批量操作
如果文档数量非常大，一个一个操作文档显然不太符合实际，Elasticsearch 提供了文档的
批量操作机制，通过Bulk API 可以执行批量索引、批量删除、批量更新等操作。
版本控制
当我们使用Elasticsearch 的 API 进行文档更新的时候整个过程如下：首先读取源文档，对
原文档进行更新操作，更新操作执行完成以后再重新索引整个文档。不论执行多少次更新，最
后保存在Elasticsearch 中的是最后一次更新后的文档。但是如果有两个线程同时修改一个文
档，这时候就会发生冲突。处理方式主要有两种：悲观锁和乐观锁的形式。ES使用的是乐观锁的实现方式。
之前说过，文档每被修改一次， 文档版本号会自增一次。Elasticsearch 使用_version 字段确保
所有的更新都有序进行。如果一个低版本的文档在一个高版本的文档之后到达， 那么旧版本的
文档会被忽略。Elasticsearch 的文档版本控制机制主要有
内部版本控制和外部版本控制，内部版本控制机制要求每次操作请求，只有当版本号相等时才
能操作成功，外部版本控制要求外部文档版本比内部文档版本高时才能更新成功。
路由机制
Elasticsearch 是一个分布式系统，当索引一个文档时文档会被存储到master 节点上的一个
主分片上。那么Elasticsearch 是如何知道文档属于哪个分片的呢？再有当你创建一个新文档，
Elasticsearch 是如何知道应该存储在分片1 还是分片2 上？要想回答这些问题，就需要了解
Elasticsearch 的路由机制。Elasticsearch 的路由机制即是通过哈希算法，将具有相同哈希值的
文档放置到同一个主分片中，分片位置计算方法：
shard = hash(routing) % number_of_primary一shards
routing 值可以是一个任意字符串，Elasticsearch 默认将文档的id 值作为routing 值，通过哈
希函数根据routing 字符串生成一个数字，然后除以主切片的数量得到一个余数remainder) ,
余数的范围永远是0 到number_of_primary_shards -1 , 这个数字就是特定文档所在的分片。种
算法基本上会保持所有数据在所有分片上的一个平均分布，而不会造成数据分配不均衡的情
况。
也可以自定义routing 值。默认的路由模式可以保证数据平均分布，文档分配算法对我们
来说是透明的，很多时候性能也不是问题。自定义routing 值在深入理解数据特征之后，能够
带来很多使用上的方便和性能上的提升。.
假设存在一个有50 个分片的索引，在集群上执行一次查询的过程如下：
( 1) 查询请求首先被集群中的一个节点接收。
(2) 接收到这个请求的节点，将这个查询广播到这个索引的每个分片上。
(3) 每个分片执行完搜索查询并返回结果。
(4) 结果在通道节点上合并、排序并返回给用户。
默认情况下，Elasticsearch 使用文档的id 将文档平均分布于所有的分片上，这导致了
Elasticsearch 不能确定文档的位置，所以它必须将这个请求广播到所有的50 个分片上去执行。
主分片的数量在索引创建的时候是固定的，并且永远不能改变。因为如果分片的数量改变了,
所有先前的路由值就会变成非法，文档相当于丢失了。使用自定义的路由模式，可以使查询更
具目的性。你不必盲目地去广播查询请求，而是要告诉Elasticsearch 你的数据在哪个分片上。
Elasticsearch 的index get mget delete update 等文档API 都可以接收一个routing 参
数， 以索引文档为例， 执行index 操作时给文档设置一个routing 参数，具有相同muting 的文
档会被分配到同一个分片上。示例如下：
PUT /website/blog/l?routing=user123
{"title": "My first blog entry", "Just trying this out..."}
上述命令索引了一条文档到Elasticsearch 中，并指定routing 为user123 , 代表user123 发
布的所有博客。如果想要查询uSerl 23 发布了哪些博客，可以通过muting 值进行过滤，这样
可以避免Elasticsearch 向所有分片都发送查询请求， 大大减少系统的资源。带muting 参数的
查询命令如下：
GET /myblog/_search?routing=userl23
需要注意的是，可以为文档指定多个路由值，路由值之间使用逗号隔开。
使用自定义routing 值也会造成一些潜在的问题，比如user123 本身的文档就非常多，有
数十万个，而其他大多数的用户只有几个文档，这样的话就会导致USerl 23 所在的分片较大，
出现数据偏移的情况，特别是多个这样的用户处于同一分片的时候现象会更明显。具体的使用
还是要结合实际的应用场景来选择。
映射详解
映射也就是Mapping 用来定义一个文档以及其所包含的字段如何被存储和索引，可以在
映射中事先定义字段的数据类型、分词器等属性。例如DB创建表时候的DDL语句。
Elasticsearch 创建索引时同样可以设置字段的属性，作用是使索引的配置更加灵活和完善,
可以在Mapping 中设置字段的类型、字段的权重等信息。
映射分类
映射可分为动态映射和静态映射。文档写入Elasticsearch 中，它会根据字段的类型自动识别，
不用像DB那样需要先预置好映射关系，这种机制称为动态映射， 而静态映射则是写入数据之前
对字段的属性进行手工设置。
动态映射
动态映射是一种偷懒的方式， 可直接创建索引并写入文档， 文档中字段的类型是
Elasticsearch 自动识别的，不需要在创建索引的时候设置字段的类型。
在Mapping 中可以通过dynamic 设置来控制是否自动新增字段
true 默认值为true 自动添加字段。
• false 忽略新的字段。
• strict 严格模式， 发现新的字段抛出异常。
日期检测
当Elasticsearch 碰到一个新的字符串类型的字段时，它会检查这个字符串是否包含一个可
识别的日期，比如2014-01-01。如果看起来像日期，那么它会被识别为一个date 类型的字段,
否则会将它作为string 字段进行添加。这种自动检测机制有时会导致一些问题，假设一种情况,
比如索引一份这样的文档到Elasticsearch 中：
{ "note": "2014-01-01" }
如果note 字段第一次被发现，那么根据规则它会被作为date 字段添加。但是如果下一份
文档是这样的：
{ "note": "Logged out" }
这时该字段显然不是日期类型， 但是已经太迟了。该字段的类型已经是日期类型的字段
了，因此这会导致一个异常被抛出。可以通过在根对象上将date_detecti0n 设置为false 来关闭
日期检测， 命令如下：
关闭日期检测之后，字段总会被当成string处理。如果需要date字段的话，需要手动的进行添加
静态映射
静态映射是在创建索引时手工指定索引映射，和SQL 中在建表语句中指定字段属性类似。
相比动态映射，通过静态映射可以添加更详细、更精准的配置信息
string
Elasticsearch 5. X 之后的字段类型不再支持string, 由text 或keyword 取代。如果仍使用
string, 会给出警告。
text
如果一个字段是要被全文搜索的，比如邮件内容、产品描述、新闻内容，应该使用text
类型。设置text 类型以后，字段内容会被分析，在生成倒排索引以前，字符串会被分词器分成
一个一个词项。
keyword
keyword 类型适用于索引结构化的字段，比如email 地址、主机名、状态码和标签，通常
用于过滤（比如查找已发布博客中status 属性为 published 的文章）、排序、聚合。类型为
keyword的字段只能通过精确值搜索到，区别于text 类型。
数字类型
数字类型支持byte short integer long float double half_float 和 scaled float
date
JSON 中没有日期类型，所以在Elasticsearch 中的日期可以是以下几种形式：
(1) 格式化日期的字符串，如“2015-01-01 ” 或“2015/01/01 12:10:30”。
(2) 代表milliseconds-since-the-epoch 的长整型数( epoch 指的是一个特定的时间：
1970-01-01 00:00:00 UTC) 。
(3) 代表seconds-since-the-epoch 的整型数。
Elasticsearch 内 部 会 把 日 期 转 换 为 UTC ( 世 界 标 准 时 间 ） ， 并 将 其 存 储 为 表 示
milliseconds-since-the-epoch 的长整型数。日期格式可以自定义，如果没有自定义，默认格式
如下:"strict_date_optional_time||epoch—millis"
boolean：true or false
binary
binary 类型接受base64编码的字符串，默认不存储(这里的存储是指store 属性取值为false )
也不可搜索。
剩下的字段类型不在一一细说，用到的时候查询下API用法就OK了。
元字段
元字段是映射中描述文档本身的字段，从大的分类上来看，主要有文档属性的元字段、源
文档的元字段、索引的元字段、路由的元字段和自定义元字段
