SolrLucene优劣势分析

排第四偶家

　　最早lucene2.4以及以前，追溯到2008年前后，lucene刚刚引起大家的关注，到后来Nutch
　　、solr的出现，lucene变得更加热。Nutch、Solr的发展，极大推动了lucene的升级。
　　对于一些接触过搜索，使用过lucene、solr的人来说，一般都会感觉lucene、solr很牛逼。我个人也认为solr、lucene确实非常NB，他涵盖了信息检索的几乎全部基础知识和非常高性能的实现方式。从solr的结构，扩展、维护整体看，发现有非常多的“工程亮点”，熟读solr定会增加对java的理解、运用技能。
　　但是，其实lucenesolr有其自身的一些局限性，而这些局限性在大数据量的时候显得更为明显。
　　早些时候CedricChampeau的评论
　　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等系统上得到完善和运用。
　　下面结合实践经验，汇总一些solrlucene
　　在使用过程中的一些“短板”，之所以说是短板，因为只在有些情况下，才成为问题，有些情况下并不是问题。最后列举一些lucene、solr中对信息检索基础知识的支持和实现。
　　solrlucene最大优势：
　　低成本、快速上手、开源社区发达，有问题基本上有现成的解决方法。
　　但是，也正因为如此，熟悉了solr、lucene并不能说一定可以应对任何搜索需求。因为实际场景中，有许多千奇百怪的需求、问题，往往需要面对的是用最小的改动、最方便的形式满足需求，而不是，是否满足以及多久满足的问题，要的是简单、可靠、可控、快速接入、快速处理故障。
　　最后汇聚成为“检索质量”，而这个标准是很难形成和取得相应口碑的。经验成为了搜索中的重要财富，而solr、lucene原理、源码只是一种最为基础和最为不可缺失的工具。理解了这些，是可以复制一个solr、lucene的，但是无法复制solr、lucene已经形成的开源经验、应用经验、讨论氛围等。
　　solrlucene短板
　　短板越多，反应solr、lucene已经支持的场景非常多，提供服务的功能非常强大。所谓的短板，完全可以成为solr、lucene在生成环境中的应用特殊性所在、亮点所在。
　　(1)http请求做了cache，有时候会出现新数据不可见，cache滞后的问题。—cache优化下也不是问题
　　(2)admin后台页面，支持中文、复杂查询语法上，欠友好。—自己稍加扩展也不是问题
　　(3)swapcore
　　的时候，单结点多core，并且core对应的索引比较大的时候，切换过程出现内存2倍化现象，甚至超时现象。—如果分前后排切换这些都不是问题了。
　　(4)indexbuild和indexsearch
　　往往在一起，导致全量过程，磁盘峰值3倍化。一份原来的、一份新建的、一份优化的时候。—-当然，build和search分离是可以解决这个问题的，也是常规做法。
　　(5)build和search和在一起，也使得build
　　和search的一些参数设置不能区别对待，尤其是build和search合体的时候，预留磁盘、内存等加速build，反而影响search。—-当然可以
　　buildsearch分离搞定
　　(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)queryparse
　　基本没有预测功能，不能调整query顺序和自动收缩条件。当然一般情况下是不需要这么复杂的优化。
　　（26）一些比较变态的查询需求不是特别高效。例如查询某个域不空。当然可以将空域采取默认值代替，查询默认值再过滤。
　　(27)对于唯一值域，没有优化，导致唯一值域的term数据膨胀。最常见的就是更新时间、上传时间等，占了非常大的term比例
　　(28)multivalue字段，实质是建立多个相同域名的字段，并不是一个域。对于域值很多内容的话，只好和在一起保存。同时，long
　　intshortfloatdouble等数组不能直接作为一个类型保存，全部得转为字符存储。空间和效率有些低。
　　(29)有些词出现的频率特别高，导致该词的倒排连非常长，solr、lucene也没有干涉。任务交给应用自己斟酌，实际上solr单节点对于命中超过100w的，并多字段排序的时候，cache失效时性能非常糟糕的。
　　(30)solrlucene对于千万级别应用非常擅长，亿级别应用需要慎重对待。
　　lucene在信息检索基础理论的阐释：
　　(1)dictionary和postling分离
　　(2)dictionary压缩：基于词典、跳跃、前缀压缩、二分查找
　　(3)postling压缩：差值压缩、可变字节压缩、p4del、simle9、simple16、跳跃表
　　(4)tfidf默认实现、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一并支持