solr架构

solr-架构

优点
主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成&＃xff0c;以及富文本&＃xff08;如Word、PDF&＃xff09;的处理。Solr是高度可扩展的&＃xff0c;并提供了分布式搜索和索引复制。Solr是最流行的企业级搜索引擎&＃xff0c;Solr4 还增加了NoSQL支持。
Solr是用Java编写、运行在Servlet容器&＃xff08;如 Apache Tomcat 或Jetty&＃xff09;的一个独立的全文搜索服务器。 Solr采用了 Lucene Java 搜索库为核心的全文索引和搜索&＃xff0c;并具有类似REST的HTTP/XML和JSON的API。Solr强大的外部配置功能使得无需进行Java编码&＃xff0c;便可对 其进行调整以适应多种类型的应用程序。Solr有一个插件架构&＃xff0c;以支持更多的高级定制。
Solr有一个更大、更成熟的用户、开发和贡献者社区。
支持添加多种格式的索引&＃xff0c;如&＃xff1a;HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。
Solr比较成熟、稳定。
不考虑建索引的同时进行搜索&＃xff0c;速度更快。

不足
建立索引时&＃xff0c;搜索效率下降&＃xff0c;实时索引搜索效率不高。
(1) http 请求做了cache&＃xff0c;有时候会出现新数据不可见&＃xff0c;cache滞后的问题。—cache优化下也不是问题

(2) admin 后台页面&＃xff0c;支持中文、复杂查询语法上&＃xff0c;欠友好。—自己稍加扩展也不是问题

(3) swap core
的时候&＃xff0c;单结点多core&＃xff0c;并且core对应的索引比较大的时候&＃xff0c;切换过程出现内存2倍化现象&＃xff0c;甚至超时现象。—如果分前后排切换这些都不是问题了。

(4) index build和index search
往往在一起&＃xff0c;导致全量过程&＃xff0c;磁盘峰值3倍化。一份原来的、一份新建的、一份优化的时候。—-当然&＃xff0c;build和search分离是可以解决这个问题的&＃xff0c;也是常规做法。

(5) build 和search和在一起&＃xff0c;也使得build
和search的一些参数设置不能区别对待&＃xff0c;尤其是build和search合体的时候&＃xff0c;预留磁盘、内存等加速build&＃xff0c;反而影响search。—-当然可以
build search分离搞定

(6) 分布式查询&＃xff0c;如果有merge&＃xff0c;性能有些问题。—-当然可以将数据分区&＃xff0c;避免merge

(7)
得分因子是可以调整的&＃xff0c;但是得分因子的增加、得分公式的扩展&＃xff0c;无法直接从solr配置插入。—-但是&＃xff0c;可以扩展lucene的代码或者参数spanquery&＃xff0c;重新一个query&＃xff0c;插入solr&＃xff0c;这样工作量稍大.另外&＃xff0c;社区提供了bm25、pagerank等排序batch&＃xff0c;对lucene有所以了解后&＃xff0c;就可以直接引用了。

(8) solr
分布式索引全量、增量控制粒度&＃xff0c;尚不够友好。指定结点、任何时刻全量&＃xff0c;指定条件下增量都不够顺利。尽管solr提供了自定义扩展实现方法。这些也不是很大问题。

(9) solr
build和search和在一起&＃xff0c;数据和业务其实绑定在一起了&＃xff0c;没有彻底隔离。使得在上100个core的时候&＃xff0c;数据源管理维护变得非常消耗资源。直接引入hadoop或者其他nosql存储时目前最流行的用来隔离数据和业务耦合性了。开源的分布式lucene方案非常多.

(10) ABTest 共享相同索引目录&＃xff0c;而不同排序或者不同分词 solr不能直接支持

(11) ABTest 独立索引目录&＃xff0c;不同排序或者不同分词&＃xff0c;solr也不能直接支持

(12) 一个core
对应多个子目录&＃xff0c;查询既可以查指定子目录也可以全部子目录查&＃xff0c;以及更新某个子目录索引或者全部子目录索引&＃xff0c;solr也不能直接支持&＃xff0c;而这些在大数据量的时候是需要支持这些功能的。

(13)solr或者lucene
目前不支持快速的“局部”更新。这里是指对document的某个字段的快速更新&＃xff0c;目前是需要传入完整的document&＃xff0c;然后add进去。如果document
的不变字段来源多个源的话&＃xff0c;IO、计算资源有些浪费&＃xff0c;如果更新量不大还好。—当然可以对更新的单独开辟内存来处理&＃xff0c;而更大的那个基本索引不去动他。

(14)solr不支持第三方条件过滤。例如从倒排中过滤处理一批doc&＃xff0c;而这些doc需要与外部源进行doc
域值过滤。问题主要是第三方信息动态性太强&＃xff0c;不利于直接写索引中去。

(15&＃xff09;solr 在支持中文分词的时候&＃xff0c;有很多第三方包可以引入&＃xff0c;但需要扩展query
parse有时候&＃xff0c;总体看有优势也有劣势。优势是引入方便&＃xff0c;劣势是词库、算法体系和lucene的不完全兼容&＃xff0c;扩展、完善不是那么容易。

(16)
在排序上&＃xff0c;对与去重或者对应基于时间动态性上&＃xff0c;还没有现成的支持。去重是指排序的前几条结果&＃xff0c;可能某个域值完全相同了&＃xff0c;或者某几个域值完全相同&＃xff0c;导致看起来&＃xff0c;靠前的结果带有一些关联字段的“聚集性”&＃xff0c;对有些应用来说&＃xff0c;并不是最好的。
在时间因素上动态性&＃xff0c;也没有直接支持&＃xff0c;也只能靠间接的按时间排序来实现。
这个问题其实不是lucene、solr要关注的吧&＃xff0c;应该是应用的特殊性导致的吧。

(17) solr
、lucene输出的日志&＃xff0c;尚没有一个通用的分析工具&＃xff0c;包括高频词、查询query聚合性等。只能自行去解析。

(18) 在支持推荐上&＃xff0c;还不能将log信息直接关联起来&＃xff0c;推荐也基本上靠离线计算好&＃xff0c;导入倒排索引&＃xff0c;查询再关联起来。

(19) 当内存30个G 以上&＃xff0c;单节点索引数据量比较大的时候&＃xff0c;jvm
环境下FGC和内存管理显得非常辣手。调优需要仔细的测试

(20) lucene很少面向接口&＃xff0c;solr很多面向接口&＃xff0c;插件化、可扩展使得solr很灵活

(21)
对于垂直型的平台化搜索&＃xff0c;支持N个不同应用、不同schema、不同数据源、不同更新频率、不同查询逻辑、不同访问请求量、不同性能指标要求、不同机器配置、垂直扩容、水平扩容&＃xff0c;solr显得不够胜任&＃xff0c;尽管

solrcloud中已经有非常多的宝贵设计经验。

(22)
流控和数控&＃xff0c;solr也不能直接支持。访问请求不支持定时和定量控制&＃xff0c;索引垂直扩容&＃xff08;增加索引副本&＃xff0c;支撑更多访问请求&＃xff09;、索引水平扩容&＃xff08;增加索引分区数&＃xff0c;支撑更多数据量&＃xff0c;平衡性能和空间压力&＃xff09;

(23) solr自容错还不够强大。例如schema
变更导致的不合理检测以及配置错误的回滚、solrconfig的一些参数不能动态获取&＃xff0c;必须事先配置好。oom之后不能自动reload&＃xff01;请求量大的时候也不能抛弃一些请求。

(24) 基于位操作的高级应用还不够灵活&＃xff0c;例如boolean 存储和facet、byte[]
存储和facet、group等&＃xff0c;支撑仍然不够友好。

(25) query parse
基本没有预测功能&＃xff0c;不能调整query顺序和自动收缩条件。当然一般情况下是不需要这么复杂的优化。

&＃xff08;26&＃xff09;一些比较变态的查询需求不是特别高效。例如查询某个域不空。当然可以将空域采取默认值代替&＃xff0c;查询默认值再过滤。

(27)对于唯一值域&＃xff0c;没有优化&＃xff0c;导致唯一值域的term数据膨胀。最常见的就是更新时间、上传时间等&＃xff0c;占了非常大的term比例

(28)multivalue 字段&＃xff0c;实质是建立多个相同域名的字段&＃xff0c;并不是一个域。对于域值很多内容的话&＃xff0c;只好和在一起保存。同时&＃xff0c;long
int short float double 等数组不能直接作为一个类型保存&＃xff0c;全部得转为字符存储。空间和效率有些低。

(29)有些词出现的频率特别高&＃xff0c;导致该词的倒排连非常长&＃xff0c;solr、lucene也没有干涉。任务交给应用自己斟酌&＃xff0c;实际上solr单节点对于命中超过100w的&＃xff0c;并多字段排序的时候&＃xff0c;cache失效时性能非常糟糕的。

(30)solr\lucene 对于千万级别应用非常擅长&＃xff0c;亿级别应用需要慎重对待。

请求处理

建立索引

参考站点&＃xff1a;
http://lxm3033.iteye.com/blog/1811286
http://www.cnblogs.com/renzherushe/p/4782396.html
http://www.cnblogs.com/chowmin/articles/4629220.html