1、Main Slide Title,Level One,Level Two,Level Three,Level Four,Level Five,Solr Community of China,WebSite :,www.solr.cc,QQGroup:,87670960,行业,信息采集，加工，检索,案例,使用,Lucene,完成加工数据的部分查询业务,问题,Lucene,里前置*模糊带来的查询速度慢的问题,解决方案,反转字段，避免前置*模糊检索,本案例是对已有的千万级英文文献数据的一个加工处理的业务，对处理完的文献数据提供给其他兄弟组使用,solr,部署检索方案。在加工处理的流程中，因业务需要
2、根据,MetaMap,相似度匹配算法，提取最有效的短语片段，故需要频繁使用,Lucene,中的通配符匹配来与词典库，语料库进行交互。,案例背景,系统拓扑,对于任意从文献中提取出来,长度大于等于,2,的短语片段，使用模糊匹配规则,例子：,对于短语片段,a b c,都要处理成如下,10,种形式进行匹配,*a b c,，,a*b c,，,a b*c,，,a b c*,，,*,b c,，,a,*,c,，,a b,*，,b c,，,a c,，,a b,对于短语片段,a b,都要处理成如下,6,种形式进行匹配,*a b,，,a*b,，,a b*,，,*,b,，,a,*，,a,b,不同短语长度的片段个数不一
3、样，但每条短语都有,2,个前置*模糊查询,模糊匹配使用的词典库数据量很小只有,320,多万。,每篇文献抽取出来的需要进行模糊匹配短语片段平均约,15,个，每个短语片段按如上的规则形式进行匹配前加工处理，这样每篇文献能得到约,30,个最耗时前置*的模糊匹配，相当于在很短时间内要进行大量的模糊匹配,流程简析,(1),最早使用的方式，是采用关系型数据库,SQL Server 2005,的版本进行模糊匹配方式的处理，平均耗时,21,秒左右。,(2),使用,K-V,数据库,cassandra,，后发现其不支持模糊检索，故弃用,(3),使用全文检索框架,Lucene,作为最终方案，经优化后,效果良好。,方
4、案探索,解决思路,采取空间换时间的策略，在索引文件多加一个匹配字段的的反转字段，然后在程序加入判断，当匹配语句中遇到一*开头的查询字符串，就反转此字符串与索引库中对应的对应的反转字段进行匹配，这样一来，条件就转变为后置*查询，所以可以提升检索速度，效果明显。由原来的,10,秒左右，变为,4,秒左右。,例子：,查询字符串,*,a b c =c b a*,与索引库的反转列进行匹配,查询字符串 *,b c =,=c b*,与索引库的反转列进行匹配,问题本质,为什么使用前置*模糊比*号出现在中间或后面对性能影响大？,当使用中间或后置模糊时，可以根据首字符大大减少匹配时搜索枚举结果的个数，当*号前置时，
5、lucene,会强制其扫描所有的文件索引，并枚举检索每一个,doc,文档的对应域，从而在数据量越大的情况下，与模糊耗时成正比，所以使用前置*模糊在大数量的情况下，需要慎重考虑。,在,Lucene,可以直接使用,WildCardQuery,进行模糊匹配，可以在查询条件上任意加*，但是当你使用,QueryParse,时，就必须手动开启前置*模糊查询的条件，否则在使用前置*检索时，会抛出一个异常，在,4.x,中我们可以调用,setAllowLeadingWildcard(true),来开启模糊检索，当然如果你使用的是,solr,，则默认是可以用的。,小结,1,尽量使用默认切词方式提供的模糊检索，它可以把一些复杂的模糊查询，转成一些精确匹配的合并结果。,2,当必须使用模糊匹配解决一些特殊业务时，数据量最好控制百万级别，可以根据业务情况做一些优化或改进。,3,，数据量在千万级别及以上的，不建议直接使用模糊匹配，尤其是是*开头的模糊检索。,Solr Community of China,Copyright www.solr.cc,Thanks,官方网址：,www.solr.cc,联系我们：,supportsolr.cc,答疑,QQ,群：,187670960,微信频道：,solrcn,关注微信获知最新活动,
浙ICP备2021020529号-1 | 浙B2-20240490 
