相关性评分与 TF-IDF算法#
relevance score 相关度评分算法, 直白说就是算出一个索引中的文本和搜索文本之间的相似程度
Elasticsearch使用的是 TF-IDF算法 (term-frequency / inverser document frequency)
- term-frequency: 表示当前搜索的文本中的词条在field文本中出现了多少次,出现的次数越多越相关
- inverse document frequency : 表示搜索文本中的各个词条在整个index中所有的document中出现的次数,出现的次数越多越不相关
- field-length: field长度越长,越不相关
向量空间模式
ES会根据用户输入的词条在所有document中的评分情况计算出一个空间向量模型 vector model, 他是空间向量中的一个点
然后会针对所有的doc都计算出一个vector model出来, 将这个
如果存在多个term,那么就是一个多维空间向量之间的运算,但是我们假设是二维的,就像下面这张图
一目了然,Doc2和目标词条之间的弧度小,于是认为他们最相似,它的得分也就越高
分词器#
什么是分词器?#
我们使用分词将将一段话拆分成一个一个的单词,甚至进一步对分出来的单词进行词性的转换,师太的转换,单复数的转换的操作, 为什么使用分词器? 就是为了提高检索时的召回率,让更多的doc被检索到
分词器的组成#
character filter:#
在一段文本在分词前先进行预处理,比如过滤html标签, 将特殊符号转换成123..这种阿拉伯数字等特殊符号的转换
tokenizer#
进行分词,拆解句子,记录词条的位置(在当前doc中占第几个位置term position)及顺序
token filter#
进行同义词的转换,去除同义词,单复数的转换等等
ES内置的分词器#
- standard analyzer(默认)
- simple analyzer
- whitespace
- language analyzer(特定语言的分词器,English)
知识补充#
- ES隐藏了复杂分布式机制,如分片,副本,负载均衡
- 增加或者减少节点时,ES会自动的进行rebalance,使数据平均分散在不同的节点中
- master节点: master节点用来管理集群中的元数据,默认会在集群中选出一个节点当成master节点,而且master节点并不会承载全部请求,所以不存在单点瓶颈
- 元数据: 创建或者删除索引,增加或者删除节点
- 扩容方案: 更推荐横向扩容,这也符合ES分片的特定,购置大量的便宜的机器让他们成为replica shard加入集群中
每一个分片地位相同,都能接受请求,处理请求,当当用户的一个请求发送到某一个shard中后,这个shard会自动就请求路由到真正存储数据的shard上去,但是最终总是由接受请求的节点响应请求
图解: master的选举,容错,以及数据的恢复
如上图为初始状态图
假如,图上的第一个节点是master节点,并且它挂掉,在挂掉的一瞬间,整个cluster的status=red,表示存在数据丢失了集群不可用
下面要做的第一步就是完成master的选举,自动在剩下的节点中选出一个节点当成master节点, 第二步选出master节点后,这个新的master节点会将Po在第三个节点中存在一个replica shard提升为primary shard,此时cluster 的 status = yellow,表示集群中的数据是可以被访问的但是存在部分replica shard不可用,第三步,重新启动因为故障宕机的node,并且将右边两个节点中的数据拷贝到第一个节点中,进行数据的恢复
并发冲突问题#
ES的实现#
ES内部的多线程异步并发修改时,是通过_version版本号进行并发控制的,每次创建一个document,它的_version内部版本号都是1,以后对这个doc的修改,删除都会使这个版本号增1
ES的内部需在Primary shard 和 replica shard之间同步数据,这就意味着多个修改请求其实是乱序的不一定按照先后顺序执行
相关语法:
PUT /index/type/2?version=1{ "name":"XXX" }
上面的命令中URL中的存在?version=1,此时,如果存在其他客户端将id=2的这条记录修改过,导致id=2的版本号不等于1了,那么这条PUT语句将会失败并有相应的错误提示
基于external的版本号控制,ES提供了一个Futrue,也就是说用户可以使用自己维护的版本号进行并发访问控制,比如:
PUT /index/type/2?version=1&version_type=external
假设当前ES中的版本号是1, 那么只有当用户提供的版本号大于1时,PUT才会成功
路由原理#
- 什么是数据路由?
一个index被分成了多个shard,文档被随机的存在某一个分片上,客户端一个请求打向index中的一个分片,但是请求的doc可能不存在于这个分片上,接受请求的shard会将请求路由到真正存储数据的shard上,这个过程叫做数据路由
其中接受到客户端请求的节点称为coordinate node,协调节点,比如现在是客户端往服务端修改一条消息,接受A接受到请求了,那么A就是 coordnate node协调节点,数据存储在B primary shard 上,那么协调节点就会将请求路由到B primary shard中,B处理完成后再向 B replica shard同步数据,数据同步完成后,B primary shard响应 coordinate node, 最后协调节点响应客户端结果
- 路由算法,揭开primary_shard数量不可变的面纱
shard = hash(routing) % number_of_primary_shards
其实这个公式并不复杂,可以将上面的routing当成doc的id,无论是用户执行的还是自动生成的,反正肯定是唯一,既然是唯一的经过每次hash得到的结果也是一样的, 这样一个唯一的数对主分片的数进行取余数,得到的结果就会在0-最大分片数之间
可以手动指定routing value的值,比如PUT /index/type/id?routing=user_id ,在保证这类doc一定被路由到指定的shard上,而且后续进行应用级负载均衡时会批量提升读取的性能
写一致性及原理#
我们在发送任何一个增删改查时,都可以带上一个 consistency 参数,指明我们想要的写一致性是什么,如下
PUT /index/type/id?consistency=quorum
有哪些可选参数呢?
- one: 当我们进行写操作时,只要存在一个primary_shard=active 就能写入成功
- all: cluster中全部shard都为active时,可以写入成功
- quorum: 意味:法定的,也是ES的默认值, 要求大部分的replica_shard存活时系统才可用
quorum数量的计算公式: int((primary+number_of_replicas)/2)+1, 算一算,假如我们的集群中存在三个node,replica=1,那么cluster中就存在3+3*1=6个shard
int((3+1)/2)+1 = 3
结果显示,我们只有当quorum=3,即replica_shard=3时,集群才是可用的,但是当我们的单机部署时,由于ES不允许同一个server的primary_shard和replica_shard共存,也就是说我们的replica数目为0,为什么ES依然可以用呢? 这是ES提供了一种特殊的处理场景,即当number_of_replicas>1时才会生效
quorum不全时,集群进入wait()状态, 默认1分钟,,在等待期间,期望活跃的shard的数量可以增加,到最后都没有满足这个数量的话就会timeout
我们在写入时也可以使用timeout参数, 比如: PUT /index/type/id?timeout=30通过自己设置超时时间来缩短超时时间
运行流程#
ES的底层运行流程探秘:#
用户的写请求将doc写入内存缓冲区,写的动作被记录在translog日志文件中,每隔一秒中内存中的数据就会被刷新到index segment file中,index segment file中的数据随机被刷新到os cache中,然后index segement file处理打开状态,对外提供检索服务,ES会重复这个过程,每次重复这个过程时,都会先清空内存buffer,处理打开状态的 index segment file可以对外提供检索
直到translog日志文件体积太大了,就会进一步触发flush操作,这个flush操作会将buffer中全部数据刷新进新的segment file中,将index segment file刷新进os cache, 写一个commit point 到磁盘上,标注有哪些index segment,并将OS cache中的数据刷新到OS Disk中,完成数据的持久化
上面的flush动作,默认每隔30分钟执行一次,或者当translog文件体积过大时也会自动flush
数据恢复时,是基于translog文件和commit point两者判断,究竟哪些数据在日志中存在记录,却没有被持久化到OSDisk中,重新执行日志中的逻辑,等待下一次的flush完成持久化
merge segment file#
看上面的图中,为了实现近实时的搜索,每1秒钟就会产生一个segment文件,文件数目会特别多,而恰巧对外提供搜索的就是这些segment文件,因此ES会在后台进行segement 文件的合并,在合并的时候,被标记deleted的docment会会被彻底的物理删除
每次merge的操作流程
- 选择大小相似的segment文件,merge成一个大的segement文件
- 将新的segment文件flush到磁盘上去
- 写一个新的commit point,包括了新的segement,然后排除那些就的segment
- 将新的segment打开提供搜索
- 将旧的segement删除
