ES学习笔记
概要
1、Elasticsearch对复杂分布式机制的透明隐藏特性
2、Elasticsearch的垂直扩容与水平扩容
3、增减或减少节点时的数据rebalance
4、master节点
5、节点对等的分布式架构
--------------------------------------------------------------------------------------------------------------------
1、Elasticsearch对复杂分布式机制的透明隐藏特性
Elasticsearch是一套分布式的系统，分布式是为了应对大数据量
隐藏了复杂的分布式机制
分片机制（我们之前随随便便就将一些document插入到es集群中去了，我们有没有care过数据怎么进行分片的，数据到哪个shard中去）
cluster discovery（集群发现机制，我们之前在做那个集群status从yellow转green的实验里，直接启动了第二个es进程，那个进程作为一个node自动就发现了集群，并且加入了进去，还接受了部分数据，replica shard）
shard负载均衡（举例，假设现在有3个节点，总共有25个shard要分配到3个节点上去，es会自动进行均匀分配，以保持每个节点的均衡的读写负载请求）
shard副本，请求路由，集群扩容，shard重分配
--------------------------------------------------------------------------------------------------------------------
2、Elasticsearch的垂直扩容与水平扩容
垂直扩容：采购更强大的服务器，成本非常高昂，而且会有瓶颈，假设世界上最强大的服务器容量就是10T，但是当你的总数据量达到5000T的时候，你要采购多少台最强大的服务器啊
水平扩容：业界经常采用的方案，采购越来越多的普通服务器，性能比较一般，但是很多普通服务器组织在一起，就能构成强大的计算和存储能力
普通服务器：1T，1万，100万
强大服务器：10T，50万，500万
扩容对应用程序的透明性
--------------------------------------------------------------------------------------------------------------------
3、增减或减少节点时的数据rebalance
保持负载均衡
--------------------------------------------------------------------------------------------------------------------
4、master节点
（1）创建或删除索引
（2）增加或删除节点
--------------------------------------------------------------------------------------------------------------------
5、节点平等的分布式架构
（1）节点对等，每个节点都能接收所有的请求
（2）自动请求路由
（3）响应收集
一、ES
提升吞吐量和性能
shard : primary shard
replica: replica share
replica 的优点 高可用性 提升搜索吞吐量和性能
primary shard 建立索引时一次设置，不能修改默认5个，replica shard 随时修改数量，默认1个，默认每个索引 10个 shard，5个 primary shard ，5个 replica shard ，最小高可用配置，2台服务器
Document 相当于数据库中的行
Type 相当于数据库中的表
Index 相当于数据库中的库
二、ES对复杂分布式机制的透明隐藏特性
分片机制
cluster discovery 集群发现机制
shard 负载均衡
shard 副本 请求路由 集群扩容 shard重分配
三、 垂直扩容 水平扩容
四、master节点
管理es集群的元数据：比如索引的创建和删除，master节点不承载请求，所以不会是一个单点故障，默认情况下，会自动选择出一台节点作为master节点
五、节点对等的分布式架构
六、shard replica 机制
1、index包含多个shard
2、每个shard都是一个最小的工作单元，承载部分数据，每个shard都是一个lucene实例，具有建立索引和处理请求的能力
3、增减节点时，shard会自动在nodes中负载均衡
4、每个document只存在于一个primary shard以及对应的replica shard中，不能存在于多个primary shard
5、replica shard是primary shard的副本，负责容错，以及承担读请求负载
6、primary shard的数量在创建索引的时候就固定了，replica shard的数量可以随时修改
7、primary shard的默认数量是5，replica默认是1，默认有10个shard，5个primary shard,5个replica shard
8、primary shard不能和自己的replica shard放在同一个节点上，否则宕机，primary shard和replica shard都丢失，起不到容错的作用，但是可以和其他primary shard的replica shard放在同一个节点上
七、单节点环境下创建index
1、单节点环境下，创建一个有3个primary shard和3个replica shard的index
2、3个primary shard分配仅有的一个node上去，另外3个replica shard是无法分配的
3、一是宕机，数据丢失
PUT /test_index
{
"settings" : {
"number of shards" ； 3
“number of replicas" : 1
}
}
八、横向扩容
1、primary replica 自动负载均衡
2、扩容的极限，每个shard可以占用单台服务器的所有资源
3、超出扩容权限，primary shard 数量是不能变的，动态修改replica数量
九、ES容错，master选举，replica容错，数据恢复
red状态代表不是所有的primary shard都是active
1、master node 宕机，master自动选举出来
2、新的master将replica提升为primary shard,状态为yellow,在所有primary shard都是激活状态的情况下，不是所有的replica shard是激活状态
3、重启宕机node,master copy replica到该node,使用原有的shard并同步宕机后修改，状态为green
十、document 的核心元数据
1、_index元数据
代表一个 document存放在哪个index中
类似的数据放在一个索引，非类似的数据放不同索引,类似的含义，document的fields 大部分相同
index 中包含很多类似的 document
索引名必须是小写的，不能用下划线开头，不能包含逗号
2、_type 元数据
代表document 属于 index中的哪个类别
一个索引通常会划分为多个type，逻辑上对index中有些许不同的几类数据进行分类
type名称可以是大写或者小写，但是同样不能用下划线开头，不能包含逗号
3、_id元数据
代表document的唯一标识，与index和type一起，可以唯一标识和定位一个document
我们可以手动指定document的id,也可以不指定，由es自动为我们创建一个id
十一、_document id 手动指定和自动生成
1、一般情况下，导入数据时，使用已有的数据标识，put /index/type/id
2、post /index/type，自动生成的id，长度为20个字符，URL安全，base64编码，GUID（全局唯一标识）算法保证了在分布式系统中并行生成是不会发生冲突
十二、 _document 的_source元数据 定制返回结果
1、_source元数据，默认情况下，会将全部信息返回给我们
2、?_source=fieldname1,filename2
十三、document 的全量替换 强制创建 删除,
1、全量替换，语法与创建文档是一样的，如果document id 不存在，就创建，如果document id 存在，那么就是全量替换，替换 document的json 的内容,document是不可改变的，如果要修改document的内容，第一种方式就是全量替换，直接对document重新建立索引，替换里面所有的内容,es会将原来的document标记为deleted,然后新增给定的doumnet,当我们创建越来越多的document的时候，es会在适当的时机在后台自动删除标记为deleted 的document
2、document的强制创建，当我们准备新建文档，PUT /index/type/id?op_type=create ,PUT /index/type/id/_create
3、document的删除 DELETE /index/type/id ,不是物理删除，只是标记为deleted，当数据越来越多的时候，后台自动删除
十四、并发控制 悲观锁 乐观锁
悲观锁 读取记录，同时对这一行加锁，只有一个线程能够读取某条记录的数据，优点是对应用程序是透明的，缺点是并发能力低
乐观锁 不加锁，引入版本号，写的时候判断版本号，若秘本号不同，说明数据已经被更改，重新读取最新数据版本，优点是并发能力很高，缺点是每次更新数据时，都需要对比版本号，重新加载数据，修改，写入，重复多次
十五、基于版本进行乐观锁的并发控制
_version元数据
创建一个document时，它的_version内部版本号就是1，以后每次对这个document进行修改和删除操作，版本号都会加1，即使是删除，版本号也会加1
es的后台，很多的这种类似于replica同步请求，都是多线程异步的，也就是说，多个修改请求之后间，是乱序的，没有顺序的，可能出现后修改的先到，先修改的后到，es是基于自己的_version版本时行乐观锁并发控制的，当先修改的后到时，此时会比较版本号，如果不相等，就直接丢弃
十六、基于 external version 进行乐观锁并发控制
external version 不用es提供的内部_version版本号进行并发控制，可以基于自身维护的一个版本号来时进行并发控制
?version=1
?version=1&version_type=external
当使用_version 时，版本号必须和es的version一致时，才可以更新
当使用_version_type=external时，版本号必须大于es的version才能完成更新
十七、partial update实现原理
post /index/type/id/_update
{
"doc":{
"数据”
}
}
每次就post要修改的field
es内部对partial update和全量替换方相似
先获取document 将传过来的field更新到document的json中 将旧的docment标记为deledted 将修改后document进行创建
partial update 相较于全量替换的优点
所有的查询、修改和回写操作都在es的一个shard内部，减少了网络开销
减少了时间间隔
十八、基于groovy 执行 partial update
es 内置脚本支持基于groovy的各种操作
es scripting module
内置脚本 ctx._source.fieldname=数值
外部脚本 脚本存放路径 ./config/scripts *.groovy
upsert操作
十九、
1、patital update内置乐观锁并发控制
2、retry_on_conflict
3、_version
二十、mget 批量查询api
1、查询不同index下的不同type的document
2、查询一个index下的不同type的document
3、同一个index下的同一个type下的document,指明ids即可
4、mget的重要性，一次性要查询多条数据，减少开销
二十一、bult 批量增删改
每一个操作都要两个json串，语法如下
{"action":{"metadata"}}
{"data"}
执行bulk操作
delete
create 类似 PUT /index/type/id/_create 强制创建
index 普通的PUT操作，可以是创建文档，也可以是全量替换文档
update 执行 partital update 操作
bulk api 对json的语法有严格的要求，每个json串不能换行，只能在同一行，两个json串之间有换行分开
bulk 操作中，其中一个操作失败，不会影响其他的操作，但是在返回中有异常
bulk size的问题，bulk request 会加载到内存里，注意大小，一般是 1000条到5000条，5M~15M
二十二、分布式文档系统
分布式文档存储系统
文档数据：es存储和操作json文档类型数据
存储系统：NoSQL存储引擎
二十四、document 增删改查 内部原理
1、客户端选择一个node发送请求，这个node是coordinating node（协调节点）
2、coordinating node 对document 进行路由，将请求转发给对应的node,包含有primary shard的node
3、实际上的primary shard处理请求，然后将数据同步到replica node
4、coordinating node发现primary node和所有replica node都完成工作后，就返回结果给客户端
二十五、写一致性 quorum机制
1、consistency one(primary shard) all(all shard) quorum(default)
put /index/type/id?consistency= one or all or quorum
one 只要在primary shard是active 活跃可用的，就可以执行
all 必须 primary shard replica shard 都是活跃的，才可以执行
quorum 大部分shard是活跃的，可以执行
2、quronum机制，写之前确保大多数shard都可用，int((primary+number_of_replicas)/2)+1,当number_of_replicas>1 时才生效
3、如果节点数少于quornum数量，可能因为quornum 不齐全，进而导致无法执行任何操作
4、quornum不齐全时，默认等待1分钟，也可加参数设置 put /index/type/id?timeout=30
二十六、
对于读请求，请求可以转发到primary shard,也可以转发到replica shard 上去，replica shard可以服务所有请求，采用round-robin随机算法
1、Elasticsearch对复杂分布式机制的透明隐藏特性
2、Elasticsearch的垂直扩容与水平扩容
3、增减或减少节点时的数据rebalance
4、master节点
5、节点对等的分布式架构
--------------------------------------------------------------------------------------------------------------------
1、Elasticsearch对复杂分布式机制的透明隐藏特性
Elasticsearch是一套分布式的系统，分布式是为了应对大数据量
隐藏了复杂的分布式机制
分片机制（我们之前随随便便就将一些document插入到es集群中去了，我们有没有care过数据怎么进行分片的，数据到哪个shard中去）
cluster discovery（集群发现机制，我们之前在做那个集群status从yellow转green的实验里，直接启动了第二个es进程，那个进程作为一个node自动就发现了集群，并且加入了进去，还接受了部分数据，replica shard）
shard负载均衡（举例，假设现在有3个节点，总共有25个shard要分配到3个节点上去，es会自动进行均匀分配，以保持每个节点的均衡的读写负载请求）
shard副本，请求路由，集群扩容，shard重分配
--------------------------------------------------------------------------------------------------------------------
2、Elasticsearch的垂直扩容与水平扩容
垂直扩容：采购更强大的服务器，成本非常高昂，而且会有瓶颈，假设世界上最强大的服务器容量就是10T，但是当你的总数据量达到5000T的时候，你要采购多少台最强大的服务器啊
水平扩容：业界经常采用的方案，采购越来越多的普通服务器，性能比较一般，但是很多普通服务器组织在一起，就能构成强大的计算和存储能力
普通服务器：1T，1万，100万
强大服务器：10T，50万，500万
扩容对应用程序的透明性
--------------------------------------------------------------------------------------------------------------------
3、增减或减少节点时的数据rebalance
保持负载均衡
--------------------------------------------------------------------------------------------------------------------
4、master节点
（1）创建或删除索引
（2）增加或删除节点
--------------------------------------------------------------------------------------------------------------------
5、节点平等的分布式架构
（1）节点对等，每个节点都能接收所有的请求
（2）自动请求路由
（3）响应收集
一、ES
提升吞吐量和性能
shard : primary shard
replica: replica share
replica 的优点 高可用性 提升搜索吞吐量和性能
primary shard 建立索引时一次设置，不能修改默认5个，replica shard 随时修改数量，默认1个，默认每个索引 10个 shard，5个 primary shard ，5个 replica shard ，最小高可用配置，2台服务器
Document 相当于数据库中的行
Type 相当于数据库中的表
Index 相当于数据库中的库
二、ES对复杂分布式机制的透明隐藏特性
分片机制
cluster discovery 集群发现机制
shard 负载均衡
shard 副本 请求路由 集群扩容 shard重分配
三、 垂直扩容 水平扩容
四、master节点
管理es集群的元数据：比如索引的创建和删除，master节点不承载请求，所以不会是一个单点故障，默认情况下，会自动选择出一台节点作为master节点
五、节点对等的分布式架构
六、shard replica 机制
1、index包含多个shard
2、每个shard都是一个最小的工作单元，承载部分数据，每个shard都是一个lucene实例，具有建立索引和处理请求的能力
3、增减节点时，shard会自动在nodes中负载均衡
4、每个document只存在于一个primary shard以及对应的replica shard中，不能存在于多个primary shard
5、replica shard是primary shard的副本，负责容错，以及承担读请求负载
6、primary shard的数量在创建索引的时候就固定了，replica shard的数量可以随时修改
7、primary shard的默认数量是5，replica默认是1，默认有10个shard，5个primary shard,5个replica shard
8、primary shard不能和自己的replica shard放在同一个节点上，否则宕机，primary shard和replica shard都丢失，起不到容错的作用，但是可以和其他primary shard的replica shard放在同一个节点上
七、单节点环境下创建index
1、单节点环境下，创建一个有3个primary shard和3个replica shard的index
2、3个primary shard分配仅有的一个node上去，另外3个replica shard是无法分配的
3、一是宕机，数据丢失
PUT /test_index
{
"settings" : {
"number of shards" ； 3
“number of replicas" : 1
}
}
八、横向扩容
1、primary replica 自动负载均衡
2、扩容的极限，每个shard可以占用单台服务器的所有资源
3、超出扩容权限，primary shard 数量是不能变的，动态修改replica数量
九、ES容错，master选举，replica容错，数据恢复
red状态代表不是所有的primary shard都是active
1、master node 宕机，master自动选举出来
2、新的master将replica提升为primary shard,状态为yellow,在所有primary shard都是激活状态的情况下，不是所有的replica shard是激活状态
3、重启宕机node,master copy replica到该node,使用原有的shard并同步宕机后修改，状态为green
十、document 的核心元数据
1、_index元数据
代表一个 document存放在哪个index中
类似的数据放在一个索引，非类似的数据放不同索引,类似的含义，document的fields 大部分相同
index 中包含很多类似的 document
索引名必须是小写的，不能用下划线开头，不能包含逗号
2、_type 元数据
代表document 属于 index中的哪个类别
一个索引通常会划分为多个type，逻辑上对index中有些许不同的几类数据进行分类
type名称可以是大写或者小写，但是同样不能用下划线开头，不能包含逗号
3、_id元数据
代表document的唯一标识，与index和type一起，可以唯一标识和定位一个document
我们可以手动指定document的id,也可以不指定，由es自动为我们创建一个id
十一、_document id 手动指定和自动生成
1、一般情况下，导入数据时，使用已有的数据标识，put /index/type/id
2、post /index/type，自动生成的id，长度为20个字符，URL安全，base64编码，GUID（全局唯一标识）算法保证了在分布式系统中并行生成是不会发生冲突
十二、 _document 的_source元数据 定制返回结果
1、_source元数据，默认情况下，会将全部信息返回给我们
2、?_source=fieldname1,filename2
十三、document 的全量替换 强制创建 删除,
1、全量替换，语法与创建文档是一样的，如果document id 不存在，就创建，如果document id 存在，那么就是全量替换，替换 document的json 的内容,document是不可改变的，如果要修改document的内容，第一种方式就是全量替换，直接对document重新建立索引，替换里面所有的内容,es会将原来的document标记为deleted,然后新增给定的doumnet,当我们创建越来越多的document的时候，es会在适当的时机在后台自动删除标记为deleted 的document
2、document的强制创建，当我们准备新建文档，PUT /index/type/id?op_type=create ,PUT /index/type/id/_create
3、document的删除 DELETE /index/type/id ,不是物理删除，只是标记为deleted，当数据越来越多的时候，后台自动删除
十四、并发控制 悲观锁 乐观锁
悲观锁 读取记录，同时对这一行加锁，只有一个线程能够读取某条记录的数据，优点是对应用程序是透明的，缺点是并发能力低
乐观锁 不加锁，引入版本号，写的时候判断版本号，若秘本号不同，说明数据已经被更改，重新读取最新数据版本，优点是并发能力很高，缺点是每次更新数据时，都需要对比版本号，重新加载数据，修改，写入，重复多次
十五、基于版本进行乐观锁的并发控制
_version元数据
创建一个document时，它的_version内部版本号就是1，以后每次对这个document进行修改和删除操作，版本号都会加1，即使是删除，版本号也会加1
es的后台，很多的这种类似于replica同步请求，都是多线程异步的，也就是说，多个修改请求之后间，是乱序的，没有顺序的，可能出现后修改的先到，先修改的后到，es是基于自己的_version版本时行乐观锁并发控制的，当先修改的后到时，此时会比较版本号，如果不相等，就直接丢弃
十六、基于 external version 进行乐观锁并发控制
external version 不用es提供的内部_version版本号进行并发控制，可以基于自身维护的一个版本号来时进行并发控制
?version=1
?version=1&version_type=external
当使用_version 时，版本号必须和es的version一致时，才可以更新
当使用_version_type=external时，版本号必须大于es的version才能完成更新
十七、partial update实现原理
post /index/type/id/_update
{
"doc":{
"数据”
}
}
每次就post要修改的field
es内部对partial update和全量替换方相似
先获取document 将传过来的field更新到document的json中 将旧的docment标记为deledted 将修改后document进行创建
partial update 相较于全量替换的优点
所有的查询、修改和回写操作都在es的一个shard内部，减少了网络开销
减少了时间间隔
十八、基于groovy 执行 partial update
es 内置脚本支持基于groovy的各种操作
es scripting module
内置脚本 ctx._source.fieldname=数值
外部脚本 脚本存放路径 ./config/scripts *.groovy
upsert操作
十九、
1、patital update内置乐观锁并发控制
2、retry_on_conflict
3、_version
二十、mget 批量查询api
1、查询不同index下的不同type的document
2、查询一个index下的不同type的document
3、同一个index下的同一个type下的document,指明ids即可
4、mget的重要性，一次性要查询多条数据，减少开销
二十一、bult 批量增删改
每一个操作都要两个json串，语法如下
{"action":{"metadata"}}
{"data"}
执行bulk操作
delete
create 类似 PUT /index/type/id/_create 强制创建
index 普通的PUT操作，可以是创建文档，也可以是全量替换文档
update 执行 partital update 操作
bulk api 对json的语法有严格的要求，每个json串不能换行，只能在同一行，两个json串之间有换行分开
bulk 操作中，其中一个操作失败，不会影响其他的操作，但是在返回中有异常
bulk size的问题，bulk request 会加载到内存里，注意大小，一般是 1000条到5000条，5M~15M
二十二、分布式文档系统
分布式文档存储系统
文档数据：es存储和操作json文档类型数据
存储系统：NoSQL存储引擎
二十四、document 增删改查 内部原理
1、客户端选择一个node发送请求，这个node是coordinating node（协调节点）
2、coordinating node 对document 进行路由，将请求转发给对应的node,包含有primary shard的node
3、实际上的primary shard处理请求，然后将数据同步到replica node
4、coordinating node发现primary node和所有replica node都完成工作后，就返回结果给客户端
二十五、写一致性 quorum机制
1、consistency one(primary shard) all(all shard) quorum(default)
put /index/type/id?consistency= one or all or quorum
one 只要在primary shard是active 活跃可用的，就可以执行
all 必须 primary shard replica shard 都是活跃的，才可以执行
quorum 大部分shard是活跃的，可以执行
2、quronum机制，写之前确保大多数shard都可用，int((primary+number_of_replicas)/2)+1,当number_of_replicas>1 时才生效
3、如果节点数少于quornum数量，可能因为quornum 不齐全，进而导致无法执行任何操作
4、quornum不齐全时，默认等待1分钟，也可加参数设置 put /index/type/id?timeout=30
二十六、
对于读请求，请求可以转发到primary shard,也可以转发到replica shard 上去，replica shard可以服务所有请求，采用round-robin随机算法