Solr采用Lucene搜索库为核心，提供全文索引和搜索开源企业平台，提供REST的HTTP/XML和JSON的API，如果你是Solr新手，那么就和我一起来入门吧！本教程以solr4.8作为测试环境，jdk版本需要1.7及以上版本。
准备
本文假设你对Java有初中级以上水平，因此不再介绍Java相关环境的配置。下载解压缩solr，在example目录有start.jar文件，启动：
|
1
|
java -jar start.jar
|
浏览器访问：http://localhost:8983/solr/，你看到的就是solr的管理界面
索引数据
服务启动后，目前你看到的界面没有任何数据，你可以通过POSTing命令向Solr中添加（更新）文档，删除文档，在exampledocs目录包含一些示例文件，运行命令：
|
1
|
java -jar post.jar solr.xml monitor.xml
|
上面的命令是向solr添加了两份文档，打开这两个文件看看里面是什么内容，solr.xml里面的内容是：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
<add>
<doc>
<field name=
"id"
>SOLR1000</field>
<field name=
"name"
>Solr, the Enterprise Search Server</field>
<field name=
"manu"
>Apache Software Foundation</field>
<field name=
"cat"
>software</field>
<field name=
"cat"
>search</field>
<field name=
"features"
>Advanced Full-Text Search Capabilities using Lucene</field>
<field name=
"features"
>Optimized
for
High Volume Web Traffic</field>
<field name=
"features"
>Standards Based Open Interfaces - XML and HTTP</field>
<field name=
"features"
>Comprehensive HTML Administration Interfaces</field>
<field name=
"features"
>Scalability - Efficient Replication to other Solr Search Servers</field>
<field name=
"features"
>Flexible and Adaptable with XML configuration and Schema</field>
<field name=
"features"
>Good unicode support: héllo (hello with an accent over the e)</field>
<field name=
"price"
>
0
</field>
<field name=
"popularity"
>
10
</field>
<field name=
"inStock"
>
true
</field>
<field name=
"incubationdate_dt"
>
2006
-
01
-17T00:
00
:
00
.000Z</field>
</doc>
</add>
|
表示向索引中添加一个文档，文档就是用来搜索的数据源，现在就可以通过管理界面搜索关键字”solr”，具体步骤是：
点击页面下的Execute Query按钮后右侧就会显示查询结果，这个结果就是刚才导入进去的solr.xml的json格式的展示结果。solr支持丰富的查询语法，比如：现在想搜索字段name里面的关键字”Search”就可以用语法name:search，当然如果你搜索name:xxx就没有返回结果了，因为文档中没有这样的内容。
数据导入
导入数据到Solr的方式也是多种多样的：
- 可以使用DIH(DataImportHandler)从数据库导入数据
- 支持CSV文件导入，因此Excel数据也能轻松导入
- 支持JSON格式文档
- 二进制文档比如：Word、PDF
- 还能以编程的方式来自定义导入
更新数据
如果同一份文档solr.xml重复导入会出现什么情况呢？实际上solr会根据文档的字段id来唯一标识文档，如果导入的文档的id已经存在solr中，那么这份文档就被最新导入的同id的文档自动替换。你可以自己尝试试验一下，观察替换前后管理界面的几个参数：Num Docs，Max Doc，Deleted Docs的变化。
- numDocs：当前系统中的文档数量，它有可能大于xml文件个数，因为一个xml文件可能有多个
<doc>标签。 - maxDoc：maxDoc有可能比numDocs的值要大，比如重复post同一份文件后，maxDoc值就增大了。
- deletedDocs：重复post的文件会替换掉老的文档，同时deltedDocs的值也会加1，不过这只是逻辑上的删除，并没有真正从索引中移除掉
删除数据
通过id删除指定的文档，或者通过一个查询来删除匹配的文档
|
1
2
|
java -Ddata=args -jar post.jar
"<delete><id>SOLR1000</id></delete>"
java -Ddata=args -jar post.jar
"<delete><query>name:DDR</query></delete>"
|
此时solr.xml文档从索引中删除了，再次搜”solr”时不再返回结果。当然solr也有数据库中的事务，执行删除命令的时候事务自动提交了，文档就会立即从索引中删除。你也可以把commit设置为false，手动提交事务。
|
1
|
java -Ddata=args -Dcommit=
false
-jar post.jar
"<delete><id>3007WFP</id></delete>"
|
执行完上面的命令时文档并没有真正删除，还是可以继续搜索相关结果，最后可以通过命令：
|
1
|
java -jar post.jar -
|
提交事务，文档就彻底删除了。现在把刚刚删除的文件重新导入Solr中来，继续我们的学习。
删除所有数据：
|
1
|
http:
//localhost:8983/solr/collection1/update?stream.body=<delete><query>*:*</query></delete>&commit=true
|
删除指定数据
|
1
|
http:
//localhost:8983/solr/collection1/update?stream.body=<delete><query>title:abc</query></delete>&commit=true
|
多条件删除
|
1
|
http:
//localhost:8983/solr/collection1/update?stream.body=<delete><query>title:abc AND name:zhang</query></delete>&commit=true
|
查询数据
查询数据都是通过HTTP的GET请求获取的，搜索关键字用参数q指定，另外还可以指定很多可选的参数来控制信息的返回，例如：用fl指定返回的字段，比如f1=name，那么返回的数据就只包括name字段的内容
|
1
|
http:
//localhost:8983/solr/collection1/select?q=solr&fl=name&wt=json&indent=true
|
- 排序
Solr提供排序的功能，通过参数
sort来指定，它支持正序、倒序，或者多个字段排序- q=video&sort=price desc
- q=video&sort=price asc
- q=video&sort=inStock asc, price desc
默认条件下，Solr根据socre倒序排列，socre是一条搜索记录根据相关度计算出来的一个分数。
- 高亮
网页搜索中，为了突出搜索结果，可能会对匹配的关键字高亮出来，Solr提供了很好的支持，只要指定参数：
- hl=true #开启高亮功能
- hl.fl=name #指定需要高亮的字段
|
1
|
http:
//localhost:8983/solr/collection1/select?q=Search&wt=json&indent=true&hl=true&hl.fl=features
|
返回的内容中包含：
|
1
2
3
4
5
|
"highlighting"
:{
"SOLR1000"
:{
"features"
:[
"Advanced Full-Text <em>Search</em> Capabilities using Lucene"
]
}
}
|
文本分析
文本字段通过把文本分割成单词以及运用各种转换方法（如：小写转换、复数移除、词干提取）后被索引，schema.xml文件中定义了字段在索引中，这些字段将作用于其中.
默认情况下搜索”power-shot”是不能匹配”powershot”的，通过修改schema.xml文件(solr/example/solr/collection1/conf目录)，把features和text字段替换成”text_en_splitting”类型，就能索引到了。
|
1
2
3
|
<field name=
"features"
type=
"text_en_splitting"
indexed=
"true"
stored=
"true"
multiValued=
"true"
/>
...
<field name=
"text"
type=
"text_en_splitting"
indexed=
"true"
stored=
"false"
multiValued=
"true"
/>
|
修改完后重启solr，然后重新导入文档
|
1
|
java -jar post.jar *.xml
|
现在就可以匹配了
- power-shot—>Powershot
- features:recharing—>Rechargeable
- 1 gigabyte –> 1G
lucene/solr的缺点
lucene/solr的缺点 solrlucenehadoop 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 在支持中文分词的时候，有很多第三方包可以引入，但需要扩展queryparse有时候，总体看有优势也有劣势。优势是引入方便，劣势是词库、算法体系和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 对千万级别应用非常擅长，亿级别应用需要慎重对待。
：http://www.chinastor.com/a/dashuju/0G3Y332014.html
http://www.importnew.com/12607.html