脚本宝典收集整理的这篇文章主要介绍了4 - 基于ELK的ElasticSearch 7.8.x技术整理 - 高级篇( 续 ) - 更新完毕,脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。
目录@H_777_5@
另外:
以前的全文检索是将整个文档集合弄成一个倒排索引,然后存入磁盘中,当要建立新的索引时,只要新的索引准备就绪之后,旧的索引就会被替换掉,这样最近的文档数据变化就可以被检索到
而索引一旦被存入到磁盘就是不可变的( 永远都不可以修改 ),而这样做有如下的好处:
当然:这种不可变的倒排索引有好处,那就肯定有坏处了“
又想保留不可变性,又想能够实现倒排索引的更新,咋办?
补充索引
,所谓的补充索引:有点类似于日志这个玩意儿,就是重建一个索引,然后用来记录最近指定一段时间内的索引中文档数据的更新。这样更新的索引数据就记录在补充索引中了,然后检索数据时,直接找补充索引即可,这样检索时不再重写整个倒排索引了,这有点类似于关系型中的拆表,大表拆小表嘛,但是啊:每一份补充索引都是一份单独的索引啊,这又和分片很像,可是:查询时是对这些补充索引进行轮询,然后再对结果进行合并,从而得到最终的结果,这和前面说过的读流程中说明的协调节点挂上钩了这里还需要了解一个配套的按段搜索
,玩过 Lucene 的可能听过。按段,每段也就可以理解为:补充索引,它的流程其实也很简单:
1、新文档被收集到内存索引缓存
2、不时地提交缓存
3、新的段被开启,让它包含的文档可见,以被搜索
4、内存缓存被清空,等待接收新的文档
一样的,段在查询的时候,也是轮询的啊,然后把查询结果合并从而得到的最终结果
另外就是涉及到删除的事情,段本身也是不可变的, 既不能把文档从旧的段中移除,也不能修改旧的段来进行文档的更新,而删除是因为:是段在每个提交点时有一个.del文件,这个文件就是一个删除的标志文件,要删除哪些数据,就对该数据做了一个标记,从而下一次查询的时候就过滤掉被标记的这些段,从而就无法查到了,这叫逻辑删除( 当然:这就会导致倒排索引越积越多,再查询时。轮询来查数据也会影响效率 ),所以也有物理删除,它是把段进行合并,这样就舍弃掉被删除标记的段了,从而最后刷新到磁盘中去的就是最新的数据( 就是去掉删除之后的 ,别忘了前面整的段的流程啊,不是白写的 )
首先来看一下主副操作
但是:这种去找寻节点的过程想都想得到会造成延时,而延时 = 主分片延时 + 主分片拷贝数据给副本的延时
而且并不是这样就算完了,前面提到了N多次的分段、刷新到磁盘还没上堂呢,所以接着看
但是:在flush到磁盘中的时候,万一断电了呢?或者其他原因导致出问题了,那最后数据不就没有flush到磁盘吗。因此:其实还有一步操作,把数据保存到另外一个文件中去
数据放到磁盘中之后,translog中的数据就会清空
同时更新到磁盘之后,用户就可以进行搜索数据了
注意:这里要区分一下,数据库中是先更新到log中,然后再更新到内存中,而ES是反着的,是先更新到Segment( 可以直接认为是内存,因它本身就在内存中 ),再更新到log中
可是啊,还是有问题,flush刷写到磁盘是很耗性能的,假如:不断进行更新呢?这样不断进行IO操作,性能好吗?也不行,因此:继续改造( 在Java的JDBC中我说过的 ———— 没有什么是加一层解决不了的,一层不够,那就再来一层 )
加入了缓存之后,这缓存里面的数据是可以直接用来搜索的,这样就不用等到flush到磁盘之后,才可以搜索了,这大大的提高了性能,而flush到磁盘,只要时间到了,让它自个儿慢慢flush就可以了( 操作系统缓存中的数据断电不会丢失啊,只会在下一次启动的时候,继续执行而已 ),上面这个流程也叫:持久化 / 持久化变更
写入和打开一个新段的轻量的过程叫做refresh。默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说 ES是近实时搜索:文档的变化并不是立即对搜索可见,但会在一秒之内变为可见
http://ip:port/index_name/_settings # 请求方式:put | |
# 请求体内容 | |
{ | |
"settings": { | |
"refresh_interval": "60s" | |
} | |
} | |
# 关闭自动刷新 | |
http://ip:port/users/_settings # 请求方式:put | |
# 请求体内容 | |
{ | |
"refresh_interval": -1 | |
} | |
# 每一秒刷新 | |
http://ip:port/users/_settings # 请求方式:put | |
# 请求体内容 | |
{ | |
"refresh_interval": "1s" | |
} | |
试想:我们在浏览器中,输入一条信息,如:搜索“博客园紫邪情”,为什么连“博客园也搜索出来了?我要的不是这个结果涩”
这就是全文检索,就是ES干的事情( 过滤数据、检索嘛 ),但是:它做了哪些操作呢?
在ES中有一个文档分析的过程,文档分析的过程也很简单:
将文本拆成适合于倒排索引的独立的词条,然后把这些词条统一变为一个标准格式,从而使文本具有“可搜索性”
而这个文档分析的过程在ES是由一个叫做“分析器 analyzer”的东西来做的,这个分析器里面做了三个步骤
在ES中,有提供好的内置分析器、我们也可以自定义、当然还有就是前面说的IK分词器也可以做到( 而重点需要了解的就是IK中文分词器 ,写到这里了,就突然想到一个事儿,牢骚一下:
在演示在前,先玩kibana吧,原本打算放在后面的,但是越早熟悉越好嘛,所以先把kibana说明了
准备工作:去Elastic官网下载kibana,官网地址如下:
下载好了kibana之后,解压到自己想要的目录( 注:解压会有点久,因为是用Vue写的,里面有模块module 要是解压快的话,可能还下错了 ),然后点击bin/kibana.bat即可启动kibana
启动之后就是上图中的样子,然后访问图中的地址即可,第一次进去会有一个选择页面,try / explore,选择explore就可以了,进去之后就是如下界面
这是英文版,要是没玩过大数据的话,那么里面的一些专业名词根据英文来看根本不知道,所以:汉化吧,kibana本身就提供得有汉化的功能,只需要改动一个配置即可 —— 就是一个i18n配置而已
进入config/kibana.yml,滑到最底部
加上上面的信息,然后重启kibana就可以了( 但是:个人建议,先汉化一段时间,等熟悉哪些名词了,然后再转成英文 ,总之最后建议用英文,一是增加英文词汇量,二是熟悉英文专业词 ,反正目前搞编程任何东西用英文比用汉语有优势,因为好多东西都是歪果仁的 )
汉化成功
kibana遵循的是rest风格( get、put、delete、post..... ),具体用法接下来玩分析器和后面都会慢慢熟悉
这是根据Unicode定义的单词边界来划分文本,将字母转成小写,去掉大部分的标点符号,从而得到的各种语言的最常用文本选择,另外:这是ES的默认分析器,接下来演示一下
启动ES( 这是用的单机,即重新解压启动的那种,另外方式也可以玩,但没演示 )和kibana,打开控制台
编写指令
GET _analyze | |
{ | |
"analyzer": "standard", # analyzer 分析器 standard 标准分析器 | |
"text": "my name is ZiXieQing" # text 文本标识 my name is ZiXieQing 自定义的文本内容 | |
} | |
# 响应内容 | |
{ | |
"tokens" : [ | |
{ | |
"token" : "my", # 分词之后的词条 | |
"start_offset" : 0, | |
"end_offset" : 2, # start和end叫偏移量 | |
"tyPE" : "<ALPHANUM>", | |
"position" : 0 # 当前词条在整个文本中所处的位置 | |
}, | |
{ | |
"token" : "name", | |
"start_offset" : 3, | |
"end_offset" : 7, | |
"type" : "<ALPHANUM>", | |
"position" : 1 | |
}, | |
{ | |
"token" : "is", | |
"start_offset" : 8, | |
"end_offset" : 10, | |
"type" : "<ALPHANUM>", | |
"position" : 2 | |
}, | |
{ | |
"token" : "zixieqing", | |
"start_offset" : 11, | |
"end_offset" : 20, | |
"type" : "<ALPHANUM>", | |
"position" : 3 | |
} | |
] | |
} | |
@H_360_990@
来个实验
它把我的名字进行拆分了,这不是我想要的,我想要的“紫邪情”应该是一个完整的词,同样道理:想要特定的词汇,如:ID号、用户名....,这些不应该拆分,而ES内置分析器并不能做到,所以需要IK中文分词器( 专门用来处理中文的 )
1、下载IK分词器
fast-github集成到goole之后如下:
这样以后下载github的东西时,就有一个加速下载了,点击即可快速下载,如:
2、把IK解压到ES/plugins中去,如我的:
3、重启ES即可( kibana开着的话,也要关了重启 ),注意观察:重启时会有一个IK加载过程
经过如上的操作之后,IK中文分词器就配置成功了,接下来就来体验一下( 启动ES和kibana ),主要是为了了解IK中的另外两种分词方式:ik_max_word和ik_smart
ik_max_word是细粒度的分词,就是:穷尽词汇的各种组成
ik_smart是粗粒度的分词
回到前面的问题,“紫邪情”是名字,我不想让它分词,怎么做?上面哪些分词都是在一个“词典”中,所以我们自己搞一个词典即可
1、创建一个.dic文件 dic就是dictionary词典的简写
2、在创建的dic文件中添加不分词的词组,保存
3、把自定义的词典放到ik中去,保存
4、重启ES和kibana
5、测试
可见,现在就把“紫邪情”组成词组不拆分了,前面玩的kibana汉化是怎么做的?和这个的原理差不多
在第一篇高级篇中我便说过:kibana重要,只是经过前面这些介绍了使用之后,并不算熟悉,因此:多玩几次吧
另外:就是前面说的kibana遵循rest风格,在ES中是怎么玩的?总结下来其实就下面这些,要上手简单得很,但理论却是一直弄到现在
现在用kibana来演示几个,其他的内容在在Postman中怎么弄,换一下即可( 其实不建议用postman测试,但是:前面用的一直是postman,专业的人做专业的事,kibana才是我们后端玩的 )
1、创建索引
2、查看索引
3、删除索引
4、创建文档( 自定义id )
5、查看文档( 通过id查询 )
6、修改文档( 局部修改 )
7、建字段类型
其他的也是差不多的玩法,在基础篇中怎么玩,稍微变一下就是kibana的玩法了
所谓的文档控制就是:不断更新的情况,试想:多进程不断去更新文档,会造成什么情况?会把其他人更新过的文档进行覆盖更新了,而ES是怎么解决这个问题的?
就是弄了一个锁来实现的,和Redis一样,也是用的乐观锁来实现的,这个其实没什么好说的,只需要看一下就知道了
上图中的三个字段就和锁挂钩的,version,版本号嘛,每次更新都会有一个版本号,这样就解决了多进程修改从而造成的文档冲突了( 必须等到一个进程更新完了,另一个进程才可以更新,才可以拿到版本号嘛 ),当然:需要注意旧版本的ES在请求中加上version即可,但是新版本的ES需要使用 "if_seq_no=value" & "if_Primary_term" =value来达到version的效果( 这两个字段一样的放在请求路径中即可 )
ES的所有索引和文档数据都是存储在本地的磁盘中的,所以:磁盘能处理的吞吐量越大,节点就越稳定
要修改的话,是在config/elasticsearch.yml中改动
1、选用固态硬盘( 即:SSD ),它比机械硬盘好是因为:机械硬盘是通过旋转马达的驱动来进行的,所以这就会造成发热、磨损,就会影响ES的效率,而SSD是使用芯片式的闪存来存储数据的,性能比机械硬盘好得多
2、使用RaiD 0 ( 独立磁盘冗余阵列 ),它是把连续的数据分散到多个磁盘上存取,这样,系统有数据请求就可以被多个磁盘并行的执行,每个磁盘执行属于它自己的那部分数据请求。这种数据上的并行操作可以充分利用总线的带宽,显著提高磁盘整体存取性( 不了解总线和带宽的,真的有必要去学一下:计算机组成原理,这个知识在计算机组成原理的数据总线那里有 , 当然:面向百度简单了解一下也行 )
3、由上面的RAID 0可以联想到另外一个解决方式:使用多块硬盘,也就可以达到同样的效果了( 有钱就行 ),是通过path data目录配置把数据条分配到这些磁盘上面
4、不要把ES挂载到远程上去存储
所以分片和副本遵循下面的原则就可以了
1、每个分片占用的磁盘容量不得超过ES的JVM的堆空间设置( 一般最大为32G ),假如:索引容量为1024G,那么节点数量为:1024 / 32 = 32左右
2、分片数不超过节点数的3倍,就是为了预防一个节点上有多个分片的情况,万一当前节点死了,那么就算做了副本,也很容易导致集群丢失数据
3、节点数 <= 主节点数 * ( 副本数 + 1 )
4、推迟分片分配
PUT /_all/_settings | |
{ | |
"settings": { | |
"index.unassigned.node_left.delayed_timeout": "5m" | |
} | |
} | |
前面说过:路由计算公式 shard = hash( routing ) % number_of_PRimary_shards
而routing默认值就是文档id,所以查询时把文档id带上,如:前面玩kibana做的操作
不带路由就会把分片和副本都查出来,然后进行轮询,这效率想都想得到会慢一点嘛
修改es的config/jvm.options
把上面的数字改了,XMs 表示堆的初始大小, Xmx 表示可分配的最大内存,ES默认是1G,这个数字在现实中是远远不够了,改它的目的是:为了能够在 Java 垃圾回收机制清理完堆内存后不需要重新分隔计算堆内存的大小而浪费资源,可以减轻伸缩堆大小带来的压力,但是也需要注意:改这两个数值,需要确保 Xmx 和 Xms 的大小是相同的,另外就是:这两个数值别超过32G啊,前面已经讲过了
参数名 | 参数值 | 说明 |
---|---|---|
cluster.name | elasticsearch | 配置 ES 的集群名称,默认值是 ES,建议改成与所存数据相关的名称, ES 会自动发现在同一网段下的 集群名称相同的节点 |
node.name | node-1001 | 集群中的节点名,在同一个集群中不能重复。节点 的名称一旦设置,就不能再改变了。当然,也可以 设 置 成 服 务 器 的 主 机 名 称 , 例 如 node.name: ${hostname} |
node.master | true | 指定该节点是否有资格被选举成为 Master 节点,默 认是 True,如果被设置为 True,则只是有资格成为 Master 节点,具体能否成为 Master 节点,需要通过选举产生 |
node.data | true | 指定该节点是否存储索引数据,默认为 True。数据的增、删、改、查都是在 Data 节点完成的 |
index.number_of_shards | 1 | 设置索引分片个数,默认是 1 片。也可以在创建索引时设置该值,具体设置为多大值要根据数据量的大小来定。如果数据量不大,则设置成 1 时效率最高 |
index.number_of_replicas | 1 | 设置默认的索引副本个数,默认为 1 个。副本数越多,集群的可用性越好,但是写索引时需要同步的数据越多 |
transport.tcp.comPress | true | 设置在节点间传输数据时是否压缩,默认为 False |
discovery.zen.minimum_master_nodes | 1 | 设置在选举 Master 节点时需要参与的最少的候选主节点数,默认为 1。如果使用默认值,则当网络不稳定时有可能会出现脑裂。 合理的 数 值 为 ( master_eligible_nodes / 2 )+1 , 其 中 master_eligible_nodes 表示集群中的候选主节点数 |
discovery.zen.ping.timeout | 3s | 设置在集群中自动发现其他节点时 Ping 连接的超时时间,同时也是选主节点的延迟时间,默认为 3 秒。 在较差的网络环境下需要设置得大一点,防止因误判该节点的存活状态而导致分片的转移 |
<dependency> | |
<groupId>org.elasticsearch.client</groupId> | |
<artifactId>elasticsearch-rest-high-level-client</artifactId> | |
<version>7.8.0</version> | |
</dependency> | |
建议:有时间去研究一下官网
java操作篇链接:https://www.cnblogs.com/xiegongzi/p/15690534.html
1、首先选主是由ZenDiscovery来完成的( 它做了两件事:一个是Ping过程 ———— 发现节点嘛 、二是Unicast过程 ———— 控制哪些节点需要Ping通 )
2、对所有可以成为master的节点( 文件中设置的node.master: true )根据nodeid字典排序,每次“选举节点( 即:参与投票选举主节点的那个节点 )”都把自己知道的节点排一次序,就是把排好序的第一个节点( 第0位 )认为是主节点( 投一票 )
3、当某个节点的投票数达到一个值时( ( 可以成为master节点数n / 2 ) + 1 ),而该节点也投自己,那么这个节点就是master节点,否则重新开始,直到选出master
另外注意:master节点的职责主要包括集群、节点和索引的管理,不负责文档级别的管理;data节点可以关闭http功能
导致的原因:
脑裂问题解决方案:
减少误判:discovery.zen ping_ timeout 节点状态的响应时间,默认为3s,可以适当调大,如果master在该响应时间的范围内没有做出响应应答,判断该节点已经挂掉了。调大参数( 如6s,discovery.zen.ping_timeout:6 ),可适当减少误判
选举触发:discovery.zen.minimum. master nodes:1,该参數是用于控制选举行为发生的最小集群主节点数量。当备选主节点的个數大于等于该参数的值,且备选主节点中有该参数个节点认为主节点挂了,进行选举。官方建议为(n / 2) +1, n为主节点个数(即有资格成为主节点的节点个数)
角色分离:即master节点与data节点分离,限制角色
1、让我弄知识点的哪些人,可能会让你们失望了,原本我的打算是后续集合SpringBoot+Redis+ES做一个小Demo,但是:最近没时间弄了,我需要去做另外一件重要的事情,因此:你们想巩固ES知识的,去网上找ES实操项目吧
2、你们这些人,看完了我博客的全系列ES知识、把实操项目弄了之后,记得再搜一下:ES面试题
以上是脚本宝典为你收集整理的4 - 基于ELK的ElasticSearch 7.8.x技术整理 - 高级篇( 续 ) - 更新完毕全部内容,希望文章能够帮你解决4 - 基于ELK的ElasticSearch 7.8.x技术整理 - 高级篇( 续 ) - 更新完毕所遇到的问题。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。