标签：节点 服务 over ppi document rms clu 其他 健康
es支持集群模式，是一个分布式系统，其好处主要有两个：
es集群由多个es实例组成，不同集群通过集群名字来区分，可通过cluster.name来进行修改，默认为elasticsearch。每个es实例本质上是一个JVM进程，且有自己的名字，可以通过node.name来进行修改
运行如下命令可以快速启动一个es节点的实例( -d 后台隐式启动 无控制台日志输出)
bin/elasticsearch -Ecluster.name=my_cluster -Epath.data=my_cluster_node1 -Enode.name=node1 -Ehttp.port=5100 -d
es 集群相关的数据称为 cluster state,主要记录如下信息：节点信息，比如节点名称、链接地址等索引信息，比如索引名称、配置等 ，可以通过 http://localhost:9200/_cluster/state?pretty 进行查看
master 节点有以下几个特点：
相关配置：node.master:true，对于每一种可视化工具来说，对于各个节点的状态都有对应的标识方式，以 cerebro 来说：
处理请求的节点称为coordinating节点，该节点为所有节点的默认角色，不能取消，路由请求到正确的节点处理，比如创建索引的请求到master节点
存储数据的节点称为 data节点，默认节点都是data类型，相关配置如下：node.data:true
只要保证启动的时候 cluster.name 保持一致，就会自动加入该集群，若不在一个网络下则需要通过 discovery.zen.ping.unicast.hosts: ["127.0.0.1"] 集群的 IP 组，配置主节点 IP 即可。
bin/elasticsearch -Ecluster.name=my_cluster -Epath.data=my_cluster_node2 -Enode.name=node2 -Ehttp.port=5200 -d
通过可视化工具我们可以创建一个索引：
这个时候可以通过控制台查看该索引的分片与副本：
数据扩容：
那么如何将数据分布到所有节点上？
接下去通过es的Rest API来创建索引，其中我们设置分片数为3、副本数为1
如上图此时增加节点是否能够提高test_index的数据容量吗？答案是不能，因为只有3个分片，已经分布到3个节点上，新增的节点无法利用
此时增加副本数是否能提高test_index的读取吞吐量呢？答案是不能，因为新增的副本是分布在3个节点上，还是利用了同样的资源，
如果要增加吞吐量，还需要增加节点。增加数据容量对应增加副本数
分片数的设定非常重要，需要提前规划好，分片数太少，导致后续无法通过增加节点实现水平扩容分片数过大，导致一个节点上分布多个分片，造成资源浪费，同时会影响查询性能
ElasticSearch引擎把文档数据写入到倒排索引（Inverted Index）的数据结构中，倒排索引建立的是分词（Term）和文档（Document）之间的映射关系，在倒排索引中，数据是面向词（Term）而不是面向文档的。一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文档列表示例：
倒排索引-查询过程
倒排索引-组成
单词词典（Term Dictionary）单词词典的实现一般用B+树,如上图所示。
倒排索引一旦生成，不能更改,有如下好处：
坏处：
解决方案：新文档直接生成新的倒排索引文件，查询的时候同时查询所有的倒排文件，然后对查询结果做汇总计算即可.
Lucene采用了这种方案，它构建的单个倒排索引称为segment，合在一起称为Index，与ES中的Index概念不同。ES中的一个Shard对应一个Lucene Index。Lucene会有一个专门的文件来记录所有的segment信息，称为Commit Point
segment写入磁盘的过程依然很耗时，可以借助文件系统缓存的特性，先将segment在缓存中创建并开放查询来进一步提升实时性，该过程在es中被称为refresh。在refresh之前文档会先存储在一个buffer中，refresh时将buffer中的所有文档清空并生成segmentes默认每1秒执行一次refresh，因此文档的实时性被提高到1秒，这也是es被称为近实时（Near Real Time）的真正原因
如果在内存中的segment还没有写入磁盘前发生了宕机，那么内存中的文档就无法恢复了。那么如何解决这个问题呢？es引入translog机制。写入文档到buffer时，同时将该操作写入translog。translog 文件会即时写入磁盘（fsync），6.x默认每个请求都会落盘，可以修改为每5秒写一次，这样风险便是丢失5秒内的数据，相关配置为index.translog.*es重新启动时会自动检查translog文件，并从中恢复数据
flush负责将内存中的segment写入磁盘，主要做如下的工作：
refresh发生的时机主要有以下几种情况：
segment一旦生成就不能更改，那么如果要删除文档该如何操作？
lucene会专门维护一个.del的文件，记录所有已经删除的文档，注意.del上记录的是文档在Lucene的内部id,在查询结果返回前会过滤掉.del中所有的文档
更新文档如何进行呢？
首先删除文档，然后再创建新的文档
随着segment的增多，由于一次查询的segment数增多，查询速度会变慢,es会定时在后台进行segment merge的操作，减少segment的 数量，通过force_merge api可以手动强制做segment merge的操作
通过如下api可以查看集群健康状况，包括以下三种：
三种状态只是代表分片的工作状态，并不是代表整个es集群是否能够对外提供服务,可以通过 GET _cluster/health 获取集群状态：
集群由3个节点组成，如下所示，此时集群状态是green
master 所在机器宕机导致服务终止，此时集群会如何处理？
脑裂问题，英文为split-brain，是分布式系统中的经典网络问题，如下图所示：
此时master断开了，slave-1与slave-2会重新选举master，比如slave-1成为了新master，此时会更新cluster state。而此时此刻，master复活了。自己组成集群后，也会更新cluster state。同一个集群有两个master，而维护不同的cluster state，网络恢复后无法选择正确的master，这就是脑裂问题，一个身体有两个大脑，不知道听谁的了
解决方案为仅在可选举master-eligible节点数据大于等于quorum时才可以进行master选举,quorum = master-eligible 节点数/2 + 1，例如 3个master-eligible节点时，quorum为2。
解决：配置 discovery.zen.mininum_master_nodes为quorum即可避免脑裂。
比如执行以下插入操作，这个doc会落到那个分片上呢？：
假设doc/1最终存储在分片1上,那么是如何存储到分片1的呢？选择1的依据是什么呢？这里就需要文档到分片的映射算法
目的：使得文档均匀分布在所有分片上，以充分利用资源
es通过如下公司计算文档对应的分片：shard = hash(routing) % number_of_primary_shards
该算法与主分片数相关，这也是分片数一旦确定后便不能更改的根本原因。看到这里是不是想到了 kafka Topic消息的路由规则呢？可以说是一模一样的效果。
文档的创建流程：
文档读取请求流程：
Search执行的时候实际分两个步骤运行的
Query阶段:
Fetch阶段：
node3根据Query阶段获取到文档Id列表对应的shard上获取文档详情数据
相关性算分在shard与shard间是相互独立的，也就意味着同一个Tearm的IDF等值在不同shard上是不同的。文档的相关性算法和它所处的shard相关在文档数量不多时，会导致相关性算分严重不准的情况发生
解决思路有两个：
DFS Query-then-Fetch是拿到所有文档后再重新完整的计算一次相关性算法，耗费更多的cpu和内存，执行性能也比较低下，一般不建议使用。操作方式如下：
如果不采用DFS Query-then-Fetch，则结果的顺序就不尽人意了：
创建非结构化的索引:
创建结构化的索引，当然也可以通过 postman操作：
这里需要注意的是在6.0.0或者更高版本中仅支持单Mapping。对于5.X版本中多个Mapping依旧可以使用。计划在7.0.0中完全移除Mapping【移除是符合情理的，你看现在就只支持单Mapping，跟直接访问index没啥区别了】
插入数据,自动生成文档 ID 插入:
指定文档 ID 插入
修改文档：
删除文档：
基础查询，先创建一个索引，对应一个 type，然后3个属性：
然后初始化一批数据：
查询所有：book/_search，默认显示10条，可以通过 "from" : 0, "size" : 20,来修改
条件查询: book/_search，然后编辑如下内容：查询书籍中包含 spring关键字，且按发版日期降序排序。
聚合查询: book/_search，然后编辑如下内容：根据书籍价格和发版日期进行分组
{
"aggs": {
"group_by_price": {
"terms": {
"field": "price"
}
},
"group_by_publication_date": {
"terms": {
"field": "publication_date"
}
}
}
}
结果如下，结果很长，我就截取了一部分：
聚合统计:book/_search，然后如下内容：根据书籍的价格进行聚合统计。
{
"aggs": {
"grades_price": {
"stats": {
"field": "price"
}
}
}
}
结果如下，结果很长，我就截取了一部分：
模糊匹配，book/_search，查询标题中包含”spri”和”j”关键字的书籍
多字段匹配 查询价格和标题中都是”100”的书籍
Query 语法查询，查询名称和价格中同时包含 100和 200，或者包含 300的书籍。
{
"query": {
"query_string": {
"query": "(100 AND 200) OR 300",
"fields": [
"name",
"price"
]
}
}
}
查询价格在 120到 200之间的数据
查询 2018-01-01 至今发版的所有书籍
filter 条件：筛选出符合条件的数据
复合查询：
标签：节点 服务 over ppi document rms clu 其他 健康
原文地址：https://www.cnblogs.com/wuzhenzhao/p/12891210.html
