阿里妹导读
本文是技术人面试系列ES篇,面试中关于ES都需要了解哪些基础?一文带你详细了解,欢迎收藏!
Elasticsearch可以实现秒级的搜索,cluster是一种分布式的部署,极易扩展(scale )这样很容易使它处理PB级的数据库容量。最重要的是Elasticsearch使它搜索的结果可以按照分数进行排序,它能提供我们最相关的搜索结果(relevance) 。
特点
功能
分布式的搜索引擎
分布式:Elasticsearch自动将海量数据分散到多台服务器上去存储和检索。
全文检索
提供模糊搜索等自动度很高的查询方式,并进行相关性排名,高亮等功能。
数据分析引擎(分组聚合)
社区网站,最近一周用户登录、最近一个月各功能使用情况。
对海量数据进行近实时(秒级)的处理
海量数据的处理:因为是分布式架构,可以采用大量的服务器去存储和检索数据。
场景
搜索类场景
比如说人员检索、设备检索、App内的搜索、订单搜索。
日志分析类场景
经典的ELK组合(Elasticsearch/Logstash/Kibana),实现日志收集,日志存储,日志分析。
数据预警平台及数据分析场景
例如社区团购提示,当优惠的价格低于某个值时,自动触发通知消息,通知用户购买。
分析竞争对手商品销量Top10,供运营分析等等。
商业BI(Business Intelligence)系统
比如社区周边,需要分析某一地区用户消费金额及商品类别,输出相应的报表数据,并预测该地区的热卖商品,通过区域和人群特征划分进行定向推荐。Elasticsearch执行数据分析和挖掘,Kibana做数据可视化。
竞品分析
LuceneJava编写的信息搜索工具包(Jar包),Lucene只是一个框架,熟练运用Lucene非常复杂。Solr基于Lucene的HTTP接口查询服务器,是一个封装了很多Lucene细节搜索引擎系统。Elasticsearch基于Lucene分布式海量数据近实时搜索引擎。采用的策略是将每一个字段都编入索引,使其可以被搜索。对比
1)Solr利用Zookeeper进行分布式管理,而Elasticsearch自身带有分布式协调管理功能。2)Solr比Elasticsearch实现更加全面,而Elasticsearch本身更注重于核心功能, 高级功能多由第三方插件提供。3)Solr在传统的搜索应用中表现好于Elasticsearch,而Elasticsearch在实时搜索应用方面比Solr表现好。目前主流依然是Elasticsearch7.x 最新的是7.8。优化:默认集成JDK、升级Lucene8大幅提升TopK性能、引入熔断机制避免OOM发生。
IK分词器
IKAnalyzer是一个开源的,基于java语言开发的轻量级的中文分词工具包。新版本的IKAnalyzer3.0则发展为 面向Java的公用分词组件,独立于Lucene项目,同时提供了对Lucene的默认优化实现。IK分词器3.0的特性如下:1. 采用了特有的“正向迭代最细粒度切分算法“,具有60万字/秒的高速处理能力。 2. 采用了多子处理器分析模式,支持:英文字母(IP地址、Email、URL)、数字(日期,常用中文数量词,罗马数字,科学计数法),中文词汇(姓名、地名处理)等分词处理。 3. 支持个人词条的优化的词典存储,更小的内存占用。 4. 针对Lucene全文检索优化的查询分析器IKQueryParser;采用歧义分析算法优化查询关键字的搜索 5. 排列组合,能极大得提高Lucene检索的命中率。
索引(类数据库)
settings:设置索引库,定义索引库的分片数副本数等映射(类表设计)
文档(数据)
映射高级
地理坐标点是指地球表面可以用经纬度描述的一个点。地理坐标点可以用来计算两个坐标间的距离,还可以判断一个坐标是否在一个区域中。地理坐标点需要显式声明对应字段类型为 geo_point
使用dynamic mapping 来确定字段的数据类型并自动把新的字段添加到类型映射
DSL高级
查询所有(match_all query)
全文搜索(full-text query)
匹配搜索(match query)
短语搜索(match phrase query)
默认查询(query string)
多字段匹配搜索(multi match query)
词条级搜索(term-level query)
精确搜索term
集合搜索idx
范围搜索range
前缀搜索prefix
通配符搜索wildcard
正则搜索regexp
模糊搜索fuzzy
复合搜索
排序sort&分页size&高亮highLight&批量bluk
聚合分析
聚合分析是数据库中重要的功能特性,完成对一个查询的数据集中数据的聚合计算,如:找出某字段(或计算表达式的结果)的最大值、最小值,计算和、平均值等。
智能搜索
如果Completion Suggester已经到了零匹配,可以猜测用户有输入错误,这时候可以尝试一下Phrase Suggester。如果还是未匹配则尝试Term Suggester。精准程度上(Precision)看:Completion > Phrase > Term, 而召回率上(Recall)则反之。从性能上看,Completion Suggester是最快的,如果能满足业务需求,只用Completion Suggester做前缀匹配是最理想的。Phrase和Term由于是做倒排索引的搜索,相比较而言性能应该要低不少,应尽量控制Suggester用到的索引的数据量,最理想的状况是经过一定时间预热后,索引可以全量map到内存。
写优化
副本数量0
首次 初始化数据时,将副本设置为0,写入完毕再改回,避免了副本建立索引的过程;
自动生成id
可以避免写前判断是否存在的过程;
合理使用分词器
binary类型不适用,title和text使用不同的分词器加快速度;
禁用评分,延长索引刷新间隔
将多个索引操作放入到batch进行处理
读优化
零停机索引重建方案
外部数据导入
通过MQ的web控制台或cli命令行,发送指定的MQ消息;
MQ消息被微服务模块的消费者消费,触发ES数据重新导入功能;
微服务模块从数据库里查询数据的总数及分页信息,并发送至MQ;
微服务从MQ中根据分页信息从数据库获取到数据后,根据索引结构的定义,将数据组装成ES支持的JSON格式,并通过bulk命令将数据发送给Elasticsearch集群进行索引的重建工作。
基于Scroll+bulk+索引别名的方案
新建索引book_new,将mapping信息,settings信息等按新的要求全部定义好;
使用scroll api将数据批量查询出来,指定scroll查询持续时间;
采用bulk api将scoll查出来的一批数据,批量写入新索引;
查询一批导入一批,注意每次都使用上次结束时的scoll_id;
切换别名book_alias到新的索引book_new上面,此时Java客户端仍然使用别名访问,也不需要修;
改任何代码,不需要停机。验证别名查询的是否为新索引的数据。
Reindex API方案
Elasticsearch v6.3.1已经支持Reindex API,它对scroll、bulk做了一层封装,能够 对文档重建索引而不需要任何插件或外部工具。
参与度 & 灵活性:自研 > scroll+bulk > reindex
稳定性 & 可靠性:自研 < scroll+bulk < reindexDeepPaging性能解决方案
比如超级管理员,要给某个省份用户发送公告或者广告,最容易想到的就是利用 from + size 来实现,但这是不现实的。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8