设为首页 收藏本站
查看: 1370|回复: 0

[经验分享] Solr\Lucene优劣势分析

[复制链接]

尚未签到

发表于 2015-7-16 13:54:01 | 显示全部楼层 |阅读模式
  最早lucene2.4以及以前,追溯到2008年前后,lucene刚刚引起大家的关注,到后来Nutch
、solr的出现,lucene变得更加热。Nutch、Solr的发展,极大推动了lucene的升级。
对于一些接触过搜索,使用过lucene、solr的人来说,一般都会感觉lucene、solr很牛逼。我个人也认为solr、lucene确实非常NB,他涵盖了信息检索的几乎全部基础知识和非常高性能的实现方式。从solr的结构,扩展、维护整体看,发现有非常多的“工程亮点”,熟读solr定会增加对java的理解、运用技能。
  
  但是,其实lucene solr有其自身的一些局限性,而这些局限性在大数据量的时候显得更为明显。
  早些时候 Cedric Champeau 的评论
http://www.jroller.com/melix/entry/why_lucene_isn_t_that 和对应的中文版
  http://www.jroller.com/melix/entry/why_lucene_isn_t_that
  这个评论是在当时情况下给出的,截止2012.6.13日,有些问题已经在solr、nutch或者其他基于solr、hadoop、hbase、cassandra等系统上得到完善和运用。
  下面结合实践经验,汇总一些solr\lucene
在使用过程中的一些“短板”,之所以说是短板,因为只在有些情况下,才成为问题,有些情况下并不是问题。最后列举一些lucene、solr中对信息检索基础知识的支持和实现。
  solr\lucene 最大优势:
   
低成本、快速上手、开源社区发达,有问题基本上有现成的解决方法。
   
但是,也正因为如此,熟悉了solr、lucene并不能说一定可以应对任何搜索需求。因为实际场景中,有许多千奇百怪的需求、问题,往往需要面对的是用最小的改动、最方便的形式满足需求,而不是,是否满足以及多久满足的问题,要的是简单、可靠、可控、快速接入、快速处理故障。
最后汇聚成为“检索质量”,而这个标准是很难形成和取得相应口碑的。经验成为了搜索中的重要财富,而solr、lucene原理、源码只是一种最为基础和最为不可缺失的工具。理解了这些,是可以复制一个solr、lucene的,但是无法复制solr、lucene已经形成的开源经验、应用经验、讨论氛围等。
  solr\lucene 短板
短板越多,反应solr、lucene已经支持的场景非常多,提供服务的功能非常强大。所谓的短板,完全可以成为solr、lucene在生成环境中的应用特殊性所在、亮点所在。
  (1) http 请求做了cache,有时候会出现新数据不可见,cache滞后的问题。—cache优化下也不是问题
  (2) admin 后台页面,支持中文、复杂查询语法上,欠友好。—自己稍加扩展也不是问题
  (3) swap core
的时候,单结点多core,并且core对应的索引比较大的时候,切换过程出现内存2倍化现象,甚至超时现象。—如果分前后排切换这些都不是问题了。
  (4) index build和index search
往往在一起,导致全量过程,磁盘峰值3倍化。一份原来的、一份新建的、一份优化的时候。—-当然,build和search分离是可以解决这个问题的,也是常规做法。
  (5) build 和search和在一起,也使得build
和search的一些参数设置不能区别对待,尤其是build和search合体的时候,预留磁盘、内存等加速build,反而影响search。—-当然可以
build search分离搞定
  (6) 分布式查询,如果有merge,性能有些问题。—-当然可以将数据分区,避免merge
  (7)
得分因子是可以调整的,但是得分因子的增加、得分公式的扩展,无法直接从solr配置插入。—-但是,可以扩展lucene的代码或者参数spanquery,重新一个query,插入solr,这样工作量稍大.另外,社区提供了bm25、pagerank等排序batch,对lucene有所以了解后,就可以直接引用了。
  (8) solr
分布式索引全量、增量控制粒度,尚不够友好。指定结点、任何时刻全量,指定条件下增量都不够顺利。尽管solr提供了自定义扩展实现方法。这些也不是很大问题。
  (9) solr
build和search和在一起,数据和业务其实绑定在一起了,没有彻底隔离。使得在上100个core的时候,数据源管理维护变得非常消耗资源。直接引入hadoop或者其他nosql存储时目前最流行的用来隔离数据和业务耦合性了。开源的分布式lucene方案非常多.
  (10) ABTest 共享相同索引目录,而不同排序或者不同分词 solr不能直接支持
  (11) ABTest 独立索引目录,不同排序或者不同分词,solr也不能直接支持
  (12) 一个core
对应多个子目录,查询既可以查指定子目录也可以全部子目录查,以及更新某个子目录索引或者全部子目录索引,solr也不能直接支持,而这些在大数据量的时候是需要支持这些功能的。
  (13)solr或者lucene
目前不支持快速的“局部”更新。这里是指对document的某个字段的快速更新,目前是需要传入完整的document,然后add进去。如果document
的不变字段来源多个源的话,IO、计算资源有些浪费,如果更新量不大还好。—当然可以对更新的单独开辟内存来处理,而更大的那个基本索引不去动他。
  (14)solr不支持第三方条件过滤。例如从倒排中过滤处理一批doc,而这些doc需要与外部源进行doc
域值过滤。问题主要是第三方信息动态性太强,不利于直接写索引中去。
  (15)solr 在支持中文分词的时候,有很多第三方包可以引入,但需要扩展query
parse有时候,总体看有优势也有劣势。优势是引入方便,劣势是词库、算法体系和lucene的不完全兼容,扩展、完善不是那么容易。
  (16)
在排序上,对与去重或者对应基于时间动态性上,还没有现成的支持。去重是指排序的前几条结果,可能某个域值完全相同了,或者某几个域值完全相同,导致看起来,靠前的结果带有一些关联字段的“聚集性”,对有些应用来说,并不是最好的。
在时间因素上动态性,也没有直接支持,也只能靠间接的按时间排序来实现。
这个问题其实不是lucene、solr要关注的吧,应该是应用的特殊性导致的吧。
  (17) solr
、lucene输出的日志,尚没有一个通用的分析工具,包括高频词、查询query聚合性等。只能自行去解析。
  (18) 在支持推荐上,还不能将log信息直接关联起来,推荐也基本上靠离线计算好,导入倒排索引,查询再关联起来。
  (19) 当内存30个G 以上,单节点索引数据量比较大的时候,jvm
环境下FGC和内存管理显得非常辣手。调优需要仔细的测试
  (20) lucene很少面向接口,solr很多面向接口,插件化、可扩展使得solr很灵活
  (21)
对于垂直型的平台化搜索,支持N个不同应用、不同schema、不同数据源、不同更新频率、不同查询逻辑、不同访问请求量、不同性能指标要求、不同机器配置、垂直扩容、水平扩容,solr显得不够胜任,尽管
  solrcloud中已经有非常多的宝贵设计经验。
  (22)
流控和数控,solr也不能直接支持。访问请求不支持定时和定量控制,索引垂直扩容(增加索引副本,支撑更多访问请求)、索引水平扩容(增加索引分区数,支撑更多数据量,平衡性能和空间压力)
  (23) solr自容错还不够强大。例如schema
变更导致的不合理检测以及配置错误的回滚、solrconfig的一些参数不能动态获取,必须事先配置好。oom之后不能自动reload!请求量大的时候也不能抛弃一些请求。
  (24) 基于位操作的高级应用还不够灵活,例如boolean 存储和facet、byte[]
存储和facet、group等,支撑仍然不够友好。
  (25) query parse
基本没有预测功能,不能调整query顺序和自动收缩条件。当然一般情况下是不需要这么复杂的优化。
  (26)一些比较变态的查询需求不是特别高效。例如查询某个域不空。当然可以将空域采取默认值代替,查询默认值再过滤。
  (27)对于唯一值域,没有优化,导致唯一值域的term数据膨胀。最常见的就是更新时间、上传时间等,占了非常大的term比例
  (28)multivalue 字段,实质是建立多个相同域名的字段,并不是一个域。对于域值很多内容的话,只好和在一起保存。同时,long
int short float double 等数组不能直接作为一个类型保存,全部得转为字符存储。空间和效率有些低。
  (29)有些词出现的频率特别高,导致该词的倒排连非常长,solr、lucene也没有干涉。任务交给应用自己斟酌,实际上solr单节点对于命中超过100w的,并多字段排序的时候,cache失效时性能非常糟糕的。
  (30)solr\lucene 对于千万级别应用非常擅长,亿级别应用需要慎重对待。
  lucene在信息检索基础理论的阐释:
(1) dictionary 和 postling 分离
(2) dictionary 压缩:基于词典、跳跃、前缀压缩、二分查找
(3) postling 压缩:差值压缩、可变字节压缩、p4del、simle9、simple16、跳跃表
(4) tf\idf 默认实现、pagerank、 bm25等第三方实现支持
(5) 索引分段 segment、全量索引、增量索引、update-out-of-place、合并策略
(6) 查询多目录、查询分布式
(7) filter 过滤,bitmap的使用
(8) 各种cache的配置和使用以及监控
(9) 各种插件化支持、扩展灵活
(10) query 的and 与 or以及组合
(11) Top 、翻页、高亮、统计、分组的支持
(12) 模糊查询、区间查询、坡度查询统统支持
(13) 默认排序、自定义自段值排序、联合排序、动态排序、静态排序、queryboot、indexboot 一并支持
  
  http://rdc.taobao.com/team/jm/archives/1999

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-87352-1-1.html 上篇帖子: solr导入数据库数据 下篇帖子: solr搜索异常
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表