Lucence 到 Elastic-Search

参考这里

lucence就是倒排索引,很快。NB的文章,lucence在底层使用FST的存储结构,就是对数据进行了压缩。

这结构

在项目中使用lucence,直接拿Util就可以了,就是使用NRTManager这个近实时的搜索类,方面实现lucence的搜索。有人问,什么时候重建索引,就添加文档,帖子的时候直接建立,这些都是在内存中进行的。

直观
近似实时搜索

简单几句话说清楚Elastic-Search

了解集群

1:可能搜索的数据量太大,要多几个机器存放,把Lucence服务分布到几台服务上面。一个搜索请求所有的机器,结果合并回来。搜索量太大,你要netty吧,数据丢失,你要备份,增加机器,数据分割。这些都不用做了,这就是ES,Y就是干这个的。

使用ES,就是索引--类型--文档 同时考虑到集群,有shard和replica(备份)两种结点类型。直接安装,增删改查一下,你看到聚合的过程对你是透明的,感觉跟用一个lucence服务一样,json语法,马上就能入门了。负载均衡,路由,集群扩容,shard重分配都跟你透明。

ES就长这个样子

就这样

里面的结点是shard和replica,但是,他们都提供服务。有master结点,但是,他只是维护一下集群信息而已。搜索请求会到所有的结点,每一个都能提供搜索和聚合功能。master不会成为瓶颈,换个名称更合适。结点对等,有点类似redis3.0的集群模式,但是,这里没有slave,都负载提供服务

创建一个index进来的时候,默认是5个Primary Shard,每一个配一个Replica Shard。这个PrimaryShard是固定的,因为他的路由算法要使用这个基数,这个不能改变。

自动实现这种分配
3台机器的分配过程

然后是集群的容错管理

集群

就是这样!


集群的样子了解了,看一下

增删改查

1:增加的时候,自动生成的id,长度为20个字符,URL安全,base64编码,GUID,分布式系统并行生成时不可能会发生冲突。这个可以借鉴一下。

2:查询的时候,就是get/{}写你的json,match等,指定字段_source,这些都直接百度即可。

3:删除的时候,是懒删除。就是删除并没有真正的删除,只是标记了deleted标记,当我们创建越来越多的document的时候,es会在适当的时机在后台自动删除标记为deleted的document。

4:修改问题,这里有并发的问题。一句话吧,es使用版本号的乐观锁机制完成并发修改。

对查询+修改的时候,要在修改的时候,加上你查询的条件

post /index/type/id/_update?retry_on_conflict=5&version=6 还提供了这种重试,就是我一直修改,连续5次还是没有修改成功,并发量太大呗,就修改失败,别浪费了。

批量增删改查

1:就一个命令_mget即可,就好像你mysql批量插入的时候,一条或者values()()(),效率高些。

2:批量修改_bulk。好像mysql里面的存储过程吧。bulk request会加载到内存里,如果太大的话,性能反而会下降,因此需要反复尝试一个最佳的bulk size。一般从1000~5000条数据开始,尝试逐渐增加。另外,如果看大小的话,最好是在5~15MB之间。就在内存里面玩呗。

到目前为止,我们就是类似对lucence一样,通过restful api+json的方式对es操作,感觉很简单,增删改查,扩容,集群。那他强大,可能就是数据组织的灵活,json格式,感觉没有硬货


搜索的时候

一个查询搜索请求过来,到集群的任何一个结点上面,结点都是对等的。会怎样?默认会把doc的id,就是生成的GUID,作为路由编号。shard = hash(routing) % number_of_primary_shards,找到数据在的shard。这里也说了,primary shard数量不可变的谜底。我去,那这就是不能扩容呗?我增加一个Primary shard结点呢?只能重启集群吗?只能这样,这个问题也无解,一致性Hash也会有问题,redis数据分片,这里直接干脆重启吧要造成重建吗? 太弱了。

一个增删改请求来的时候,(1)客户端选择一个node发送请求过去,这个node就是coordinating node(协调节点)(2)coordinating node,对document进行路由,将请求转发给对应的node(有primary shard)(3)实际的node上的primary shard处理请求,然后将数据同步到replica node(4)coordinating node,如果发现primary node和所有replica node都搞定之后,就返回响应结果给客户端  这是全同步的方式呀?全同步?这个同步操作,全同步从结点都搞定返回。异步直接返回,等都不等从。半同步,至少等一个从结点返回。Fuck,我以为这里是等待大多数从结点反馈呢?不是,es就是全同步的。put /index/type/id?consistency=quorum,他这个参数是说

没关系呀

请求落到具体Doc上,为了效率

具体到docement上面,再细化一次,上面没有说负载均衡。

1、客户端发送请求到任意一个node,成为coordinate node。(Fuck,他们都是均等的)2、coordinate node对document进行路由,将请求转发到对应的node,此时会使用round-robin随机轮询算法,在primary shard以及其所有replica中随机选择一个,让读请求负载均衡。3、接收请求的node返回document给coordinate node。4、coordinate node返回document给客户端。5、特殊情况:document如果还在建立索引过程中,可能只有primary shard有,任何一个replica shard都没有,此时可能会导致无法读取到document,但是document完成索引建立之后,primary shard和replica shard就都有了。Fuck,如果落到了正在构建的replica shard就会说没有,就不能重定向一下吗?可能为了效率吧

2:_bluk批量增删改操作对api有要求,最大的优势在于,不需要将json数组解析为一个JSONArray对象,形成一份大数据的拷贝,浪费内存空间,尽可能地保证性能。不能使用一般的json格式

搜索图解 

为了更快

1:超时,一个搜索请求打到所有的结点上面,聚合,这个过程可能很慢。我就指定,比如5s,在5s内你拿到多少返回多少就行了,不要影响UI显示。GET /_search?timeout=10m

2:一个搜索,结果肯定可能每一个分片都有的。他会达到一个shard的primary或者replica。

3:es是简单的,你期待的分页搜索,GET /_search?size=10&from=20  这Y根本就没有考虑深排序的问题,我要查询10000,100010,他也是内存聚合,返回。没有二次查询的优化等。

4:建立一个doc的时候,会给你来一个字段,_all field。GET /test_index/test_type/_search?q=test这种查询没有指定字段。{"name": "jack","age": 26,"email": "jack@sina.com","address": uamgzhou"}默认的还会给你加一个_all metadata:"jack 26 jack@sina.com guangzhou"就这样。

5:doc中的各个字段,会默认的哟一个mapping映射。对不同的字段,比如日期是不会分词的,对搜索有影响。GET /index/_mapping/type 查看mapping。这里有一个问题!复杂类型的mapping,我们的java类映射过来的时候,底层的存储,横向的存储转换为列式存储。

object底层

6:搜索的时候,有同义词,近义词,复数,这些搜索,normalization,建立倒排索引的时候,会执行一个操作,也就是说对拆分出的各个单词进行相应的处理,以提升后面搜索的时候能够搜索到相关联的文档的概率。

7:他默认的分词器我们不感兴趣,就是IK中文分词器。

8:各种搜索自己百度,没有干货,keyword,不分词的搜索。

搜索相关

1:就是TF/IDF,就是在一个doc里面出现越多越好,但是,在多个doc里面出现越多越低。

2:搜索的结果排序,doc value(就是文档对应分词,这名字)在建立索引的时候,一方面会建立倒排索引,以供搜索用;一方面会建立正排索引,也就是doc values,以供排序,聚合,过滤等操作使用 es不仅仅是搜索,关键就是他的聚合下钻分析功能

3:每一次的搜索结果都不一样,bouncing results问题,还起了个名字,就是你每一次的搜索都可能打到不同的shard上面。简单说,就是指定一下rote_id即可。

4:_scroll大数据的分页搜索,根据上一次的scroll_id继续搜索即可,这都不是什么知识。如果一次性要查出来比如10万条数据,那么性能会很差,此时一般会采取用scoll滚动查询,一批一批的查,直到所有数据都查询完处理完。scoll,看起来挺像分页的,但是其实使用场景不一样。分页主要是用来一页一页搜索,给用户看的;scoll主要是用来一批一批检索数据,让系统进行处理的

5:定制自己的分词器,百度,都不用google的。

6:type的底层存储。

就这

mapping的时候,还可以指定type的策略,true:遇到陌生字段,就进行dynamic mapping ,false:遇到陌生字段,就忽略,strict:遇到陌生字段,就报错

倒排索引近实时搜索

1:不停机的重建索引,可能你一个index下面的type字段设置错了。就是不操作索引,操作索引的别名,真正的索引错误,新建索引,然后更改别名的指向,解决问题。先起个别名,操作别名

有点干货

就是,写入内存中,刷到segment,很多很多的segment,写入系统缓存,写到磁盘才能搜索。实时就是在写入系统缓存这里就可以提供搜索了,osCahe聚集了大量的数据,防止,丢失又提供了translog,这和lucence是差不多类似的






推荐阅读更多精彩内容