博客分类：
博客分类：
原文：/news/solr-and-autocomplete-part-1 大部分人已经见过自动完成(autocomplete)的功能了(见下图)，solr提供了构建这个功能的机制。今天，我将给你展示如何使用facet的方式来添加自动完成机制。
索引 设想你想在你的在线商店中，给用户一些提示，比如商品的名称。假设我们的索引构建如下：
name="id" type="string" indexed="true" stored="true" multiValued="false" required="true"
name="name" type="text" indexed="true" stored="true" multiValued="false"
name="description" type="text" indexed="true" stored="true" multiValued="false"
text类型的定义为：
name="text" class="solr.TextField" positionIncrementGap="100"
class="solr.WhitespaceTokenizerFactory"
class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"
class="solr.LowerCaseFilterFactory"
配置 开始前，首先考虑你要实现的功能：是要实现一个名字的提示，还是全名的提示。这都依赖于我们的选择，我们必须为需要引导的地方设置适当的域。 单词提示 在单词的情况下，我们使用的域也即一个token。在这种情况下，域名为name就足够了。但是，这属于一个词干，analysis的操作都在词干上，因此，我们最好换一个其他的类型。 全名提示 我们使用一个不同的域配置来定义全名提示--最好一个未被定义的域。但是我们不能使用基于类似string这种类型的域，基于这个原因，我们定义为一下的域： 引用
&field name="name_auto" type="text_auto" indexed="true" stored="true" multiValued="false" /&
text_auto类型的定义为：
name="text_auto" class="solr.TextField"
class="solr.KeywordTokenizerFactory"
class="solr.LowerCaseFilterFactory"
为了不影响原有数据的格式，将原数据进行拷贝： 引用
&copyField source="name" dest="name_auto" /&
如何使用 为了使用这个数据，我们准备了一个简单的查询语句： 引用
q=*:*&facet=true&facet.field=FIELD&facet.mincount=1&facet.prefix=USER_QUERY
需要替换的地方：
FIELD：我们打算提供建议的域，在本例中域名为name 或name_auto
USER_QUERY：用户输入的字符 这里可以设置rows=0，这样可以只返回facet的结果，而没有查询结果。当然这不是必须的。 查询的一个例子可以这样写： 引用
fl=id,name&rows=0&q=*:*&facet=true&facet.field=name_auto&facet.mincount=1&facet.prefix=har
查询结果会返回这样的结果：
name="responseHeader"
name="status"0
name="QTime"0
name="response" numFound="4" start="0"
name="facet_counts"
name="facet_queries"
name="facet_fields"
name="name_auto"
name="hard disk"1
name="hard disk samsung"1
name="hard disk seagate"1
name="hard disk toshiba"1
name="facet_dates"
扩展功能 这里说一下他的一些常用的功能。 第一个是显示用户的一些额外的信息，比如当你选择某个提示词时，显示的结果的数量。这是一个很有意思的特性。 另一个是使用facet.sort参数进行排序。这依赖于你的需求，我们可以按文档的数量排序（默认方式，设参数为true即可），或者按字母序排序（设为false）。 我们也可以通过设置facet.mincount来显示比指定的数量更多的提示词。 另外一个很好的特性是提示词不仅可以通过用户的类型获取，还可以通过其他的属性获取，这类似于类别。举个例子，我们想给用户展示家庭用品相关的商品，我们假设现在用户对DVD类型的商品并不感兴趣，这样我们添加一个参数： fq=department:homeApplications（假设有这个department）。通过这样的一个查询，你就不需要在所有的索引中匹配了，而是在我们选择的department里选择。 结尾 跟其他方法一样，它有优点，也有缺点。优点就是易于使用、没有额外的组件依赖，并且能将结果约束在一个很小的范围内来更好的匹配用户的需求；另外一个很大的优点是它对每个提示词都附带了结果的统计。缺点就是需要添加额外的类型和字段；另外由于其facet的机制，对机器性能和load都非常消耗。 PS：我自己测试了一下，由于这个功能是实时请求的（每个字母的输入都是一次请求），如果量很大的时候，统计数量会占用很大的内存，内存过小（我的2G）很容易OOM。所以，这个功能慎用。 网上有个哥们建议使用facet.prefix，由于目前没有这方面的强烈需求，故在此搁下，需要时再从这里起步。
博客分类：
原文链接： 在中我介绍了怎么用faceting的机制来实现自动完成(autocomplete)的功能，今天我们来看一下如何用Suggester的组件来实现自动完成功能. 开始
这里有一点需要提醒：Suggest组件在1.4.1或以下版本不可用。要使用这个组件，你需要下载3_x或lucene/solr的主干版本。 配置 在索引配置之前，我们定义一个searchComponent：
name="suggest" class="solr.SpellCheckComponent"
name="spellchecker"
name="name"suggest
name="classname"org.apache.solr.spelling.suggest.Suggester
name="lookupImpl"org.apache.solr.spelling.suggest.tst.TSTLookup
name="field"name_autocomplete
这个组件是基于solr.SpellCheckComponent的，这样我们就可以使用它的一些配置。配置中有3个非常重要的属性： name:组件名 lookupImpl：绑定这个搜索的对象，目前有两个类可以使用-JasperLookup、TSTLookup，第二个效率更高 field：针对的字段 现在让我们添加合适的handler：
name="/suggest" class="org.apache.ponent.SearchHandler"
name="defaults"
name="spellcheck"true
name="spellcheck.dictionary"suggest
name="spellcheck.count"10
name="components"
非常简单的配置，它定义了Search的组件，告诉solr每次建议的最大个数为10，使用上面定义的suggest组件。 索引 假设我们的文档有三个字段：id、name、description。我们想给name字段做自动完成功能，索引配置则为：
name="id" type="string" indexed="true" stored="true" multiValued="false" required="true"
name="name" type="text" indexed="true" stored="true" multiValued="false"
name="name_autocomplete" type="text_auto" indexed="true" stored="true" multiValued="false"
name="description" type="text" indexed="true" stored="true" multiValued="false"
另外，需要定义一个copyFiled：
source="name" dest="name_autocomplete"
单词建议 为了完成单独词的建议，我们需要定义一个 text_autocomplete的类型:
class="solr.TextField" name="text_auto" positionIncrementGap="100"
class="solr.WhitespaceTokenizerFactory"
class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"
class="solr.LowerCaseFilterFactory"
词组建议 如果实现完整的词组建议，我们的text_autocomplete类型应该定义为：
class="solr.TextField" name="text_auto"
class="solr.KeywordTokenizerFactory"
class="solr.LowerCaseFilterFactory"
如果使用词组，你需要定义自己的转换类(对于中文如庖丁、iK等) 建立词典 在我们开始使用该组件前，我们需要对它建立索引，可以使用solr命令：
/suggest?spellcheck.build=true
查询 现在终于可以使用这个组件了。使用词组的建议方式，假设查询语句为：
/suggest?q=har
执行该语句后，得到下面的建议：
version="1.0" encoding="UTF-8"
name="responseHeader"
name="status"0
name="QTime"0
name="spellcheck"
name="suggestions"
name="dys"
name="numFound"4
name="startOffset"0
name="endOffset"3
name="suggestion"
hard drive
hard drive samsung
hard drive seagate
hard drive toshiba
结尾 下一部分我将介绍如何修改配置来使用静态的词典信息以及怎么获得更好的建议。该系列的最后一部分将对会这些方法做一个性能的比较，并选出在不同场景下最快的一个。
博客分类：
原文URL：/news/solr-and-autocomplete-part-3?mz=33057-solr_lucene 在之前的两个部分(、)中,我们学会了如何配置和查询solr来获取自动完成的功能。今天，我们来看一下如果为suggester添加字段，以这种方式来提供自动完成的功能。
组件配置 在上一期的配置组件中添加如下的参数：
name="sourceLocation"dict.txt
这样我们的配置就变成了：
&searchComponent name="suggest" class="solr.SpellCheckComponent"&
&lst name="spellchecker"&
&str name="name"&suggest&/str&
&str name="classname"&org.apache.solr.spelling.suggest.Suggester&/str&
&str name="lookupImpl"&org.apache.solr.spelling.suggest.tst.TSTLookup&/str&
&str name="field"&name_autocomplete&/str&
&str name="sourceLocation"&dict.txt&/str&
&/searchComponent&
使用这个参数，我们让suggest组件使用名叫dict.txt的文件作为solr的配置字典。 handler配置 handler的配置也需要添加额外的一个参数：
name="spellcheck.onlyMorePopular"true
完整的配置为：
name="/suggest" class="org.apache.ponent.SearchComponent"
name="defaults"
name="spellcheck"true
name="spellcheck.dictionary"suggest
name="spellcheck.count"10
name="spellcheck.onlyMorePopular"true
name="components"
这个参数告诉solr，当查询的结果数多于设定的count数时，返回点击数更多的那些。 Dictionary 我们告诉solr来使用这个字段，那么这个字段长的什么样呢？下面来看一个例子： 引用
# sample dict Hard disk hitachi Hard disk wd
2.0 Hard disk jjdd
这个字典的结果是什么样的呢？每个词组放在单独的一行中，每行以改词组的权重为结束(权重与词组之间以TAB字符分隔)，这个权重就是跟spellcheck.onlyMorePopular=true 香港的参数，默认值为1.0。该字段必须以UTF-8的编码格式存储。每行前有#字符的将被忽略(注释行)。 数据 以这种方式，我们不需要数据，字段就是数据。 运行 在重新构建suggester之后，我们来看一下它的运行情况，输入命令： 引用
/suggest?q=Har
得到的结果为：
version="1.0" encoding="UTF-8"
name="responseHeader"
name="status"0
name="QTime"0
name="spellcheck"
name="suggestions"
name="Dys"
name="numFound"3
name="startOffset"0
name="endOffset"3
name="suggestion"
Hard disk jjdd
Hard disk wd
Hard disk hitachi
结束语 跟预期一样，suggest的结果是按权重排序的。这里的大小写敏感(注意首字母).
Solr本身的性能不错，但是在使用过程中，还是会遇到一些使用错误，或是没考虑到的地方；在出现瓶颈时，可以首先考虑哪些点呢？下面就来看一下Solr官方的总结，个人觉得总结的很好。SOLR+LUCENE的官网还是挺给力的
对Schema设计的考虑 索引域的数量增长会很大程度的影响以下的内容：
索引期间的内存使用 段的合并时间 优化(optimization)时间
如果设置omitNorms="true" ，则可以减小对这些影响 批注：如果设置Norms，则会影响评分的标准，但会大大的增大索引文件的大小，如果对该字段没有需求，建议关掉 存储域 通过查询结果获取存储域的值是一个相当大的开销。如果文档的数据特别大，或者一些数据存储到了分布式的磁盘中（需要更多的IO来查询域）时，那么花费将会很大。这在存储大数据时很容易被考虑到，尤其是整个文档内容的存储。 考虑将大数据的存储放到solr之外。如果非要这么做，那么可以考虑使用压缩域，这将会用CPU的开销来换取IO的开销。 如果你并不需要使用所有的存储域，允许延迟加载(enableLazyFieldLoading)将会是很好的方式，由于是对那些压缩的字段。 批注：延迟加载在查询期间很有用，尤其是需要对某些字段作额外的处理时，它既能减少内存使用，又加速了程序的处理。另外，尽量减小索引的大小绝对不是坏事。 SOLR配置考虑 mergeFactor mergeFactor大致决定了段的数量。mergeFactor的值告诉lucene有多少个段需要进行合并。它可以被认为是一个基本的数量系统。 举个例子，如果你设置mergeFactor为10，每1000个文档时会创建一个新的段到硬盘中。当第10个段被添加时，所有的10个段将被合并为1个段 (包含10000个文档)；当这样的10个文档被创建时，它们又会被合并为个包含100,000个文档的段，依次类推（当然也有上限）。这样，在任何时候，都不会有多余9个的段(相同索引大小情况下)存在。 该值在solrconfig.xml中的mainIndex设置(它会忽略indexDefaults)。 批注：关于合并的策略，请看我之前的博客： mergeFactor Tradeoffs 高值的merge factor(比如25)： 引用
Pro：一般会加快索引的速度 Con：低合并延迟，在查询时需要搜索更多的文件，所以会使查询变慢
低值的merge factor(比如2)： 引用
Pro：更少的索引文件，加快查询的速度 Con：更多的文件合并，将使索引变慢
批注：一般来说不需要这么极端，设10即可。保证读速度的同时，也保证合并的速度。 HashDocSet最大值的考虑 SOLR1.4之后不支持了，不再描述。 cache中autoWarm数量的考虑 当一个新的searcher被打开时，它的cache可以从旧的searcher中重新加载或者自动预热(autowarmd)缓存的对象。autowarmCount是将被拷贝到新searcher中的对象的数量，你需要根据autowarm的时间来设置autowarmCount。如何使用autowarmCount，需要你根据时间和数量来设定。 批注：autoWarm即新的searcher会有多少数据被缓存，如果没有缓存，一些热点数据无疑会变得很慢。所以，合理的这是这个值，能大大加快查询的效率。 缓存命中率 在Solr的admin中监控缓存的统计。增加缓存的大小通常是提高性能的最好方法，尤其是你对一个指定的缓存类型作逐出操作时。请关注filterCache，它也被用来作solr的facetting。 批注：一个典型的场景是范围查询，类似fl=price:[100 TO 200]这样的情况，将数据该范围存储起来时，对其他的一些查询都可以复用这个缓存的数据，很高效。 对排序的域作明确的预热 如果你的工作大多基于排序的方式，那么你最好在“newSearcher”和“firstSearcher”时间监听器中添加明确的预热查询规则，这样FiledCache可以在用户的查询被执行前就将数据加载。 优化的考虑 你可能想在任何时候都可以优化你的索引。比如你创建索引后，就没有修改过它。 如果你的索引收到了一串需要更新的流，那么请考虑以下的因素： 引用
1. 如果过多的段被添加到索引中，那么查询的性能将会下降；lucene的段自动合并能将段的数量控制在一定范围 2. auto-warming的时间也会延长，它通常依赖于所做的查询 3. 优化后的第一次分布耗时比之后的分布耗时要长。具体请看 4. 在优化期间索引的问题大小会加倍，优化后会回到原始大小或更小 5. 如果可以，请确保没有并发的commit请求，否则会有很大的性能损失
在优化时所有的索引会放到唯一的段中；优化索引会避免“文件打开数过多”的问题。 这里有一篇关于该问题的文章： 更新和提交的频率 如果slaves收到的数据过频，那么性能必然受损。为了避免这个问题，你必须了解slaver的更新机制，这样你才能更好的调整相关的参数（commit的数量/频率、snappullers、autowarming/autocount）以使新数据的写入不会那么频繁。 引用
1. 集合的快照会在客户端运行commit时建立，或者在optimization时；这依赖于在master上的postCommit或postOptimize的钩子方法 2. slaver上的Snappuller会运行corn去检查master上是否有新的快照，如果它找到新的版本，就会把它拿过来并install这些新的数据。 3. 当一个新的searcher被打开时，autowarming会先于Solr的查询请求之前完成。有了预热的缓存，查询的延迟将会小很多。
这里有三个相关的参数： 引用
快照的数量/频率：这取决于客户端的索引。因此，集合的版本号依赖于客户端的活跃度 snappluller：基于cron，他可以精确到秒级别。它们运行时，会获取最近它们没有的集合 缓存预热：在solrconfig.xml中配置
查询响应的压缩 在Solr返回xml应答给客户端之前对其进行压缩有时是值得做的。如果应答结果非常大，或者网络IO有限制，或者没有千兆网卡，请考虑使用压缩机制。 压缩会增加CPU的使用，并且Solr本身也是CPU密集型的应用，所以压缩会降低查询的性能。压缩会使文件减小到1/6的大小，使网络包减小到1/3的大小；相对的，查询的性能会降低15%左右。 请查看你的应用服务器的相关文档（tomcat、resion、jetty...）来获取关于压缩的信息。 索引的性能 一般情况下，一次更新多个文档比一个一个更新要快。 对于这种块级的更新方式，考虑使用StreamingUpdateSolrServer.java，它提供多线程多连接的方式来更新流数据。 批注：StreamingUpdateSolrServer类相对CommonsHttpSolrServer要快很多，主要在于它将原本单个的文档写入变为了批量写入，加上多线程多连接的方式，性能上快了超多。我们的测试数据表明，至少要快4-6倍以上。 内存使用的考虑 OutOfMemoryErrors 如果你的solr实例没有足够的内存，那么JVM有时会抛出OutOfMemoryErrors。这并不会对数据有影响，并且solr也会试图优美的恢复它。任何 添加/删除/提交 的命令在异常抛出时都可能不成功；其他不利的影响也可能会产生。对应用而言，如果SimpleFSLock 的锁机制在使用的话，OutOfMemoryError 会导致solr丢失这个锁。如果这发生了，更新索引的结果将会是这样的异常：
SEVERE: Exception during commit/optimize:java.io.IOException: Lock obtain timed out: SimpleFSLock@/tmp/lucene-5d12ddbeb001c4877b36-write.lock
如果你想在OOM时看堆的情况，请设置"-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/the/dump" JVM内存的分配 针对这个错误的最简单方法，在JVM并没有完全使用你的物理内存时，考虑加大JVM的内存容量：
java -Xms512M -Xmx1024M -jar start.jar
影响内存使用的因素 你可能想去减小solr的内存使用。 一个方式就是减小文档的大小。 当运行add命令时，标准的xml更新请求会有两个限制： 引用
1. 所有的文档必须同时放入到内存中。通常，它的取值为sum(域的实际长度，maxFieldLength)。所以，调整maxFieldLength的大小可能会有帮助 2. 每个&field&...&/field&标签都必须放入到内存中，而不管maxFieldLength
注意一些不同的add请求会在不同的线程中并发运行。越多的线程，就会导致越多的内存使用。 我的一些其他使用经验： 1.schema中的类型定义很重要，它直接影响了索引的性能 2.尽量少用filter，虽然它很好用，但是其hashSet的数量如果过多，很容易oom 3. cache的类，都用FastLRUCache吧，LRUCache还有锁，太慢了 4. 通过docId取doc的过程看似平常，但是量大了就是一个灾难，在这点需要根据实际场景考虑 5. 能用缓存的用缓存，不能用缓存的，尝试使用MMapDirectoryFactory，最好是SSD硬盘 6.其他，待想到了再补充你有什么建议呢？如果我们有一个很好的字典，这个字典的权重是基于用户的查询行为产生的，那么用户肯定会喜欢它！如果没有好的字典，还是不要用这种方式的好。 下一步 下一期，我们看一下不同方式的suggest产生的索引结构和大小。
浏览: 263067 次
来自: 上海
很实用，一直关注
你好,最近在解决redis数据同步的问题,找到了tedis,但 ...
楼主接下来要考虑页面静态化与细节上面的东西了
jovinlee 写道
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'sponsored links
solr的schema.xml配置属性解释
schema.xml做什么？
SOLR加载数据，创建索引和数据时，核心数据结构的配置文件是schema.xml，该配置文件主要用于配置数据源，字段类型定义，搜索类型定义等。schema.xml的配置直接影响搜索结果的准确性与效率。
&types&&/types&节点
types节点主要用于搜索类型的定义，这里给出常用类型的定义。
1 &fieldType name="string" class="solr.StrField" sortMissingLast="true" /& 2 &fieldType name="boolean" class="solr.BoolField" sortMissingLast="true"/& 3 &fieldtype name="binary" class="solr.BinaryField"/& 4 &fieldType name="int" class="solr.TrieIntField" precisionStep="0" positionIncrementGap="0"/& 5 &fieldType name="float" class="solr.TrieFloatField" precisionStep="0" positionIncrementGap="0"/& 6 &fieldType name="long" class="solr.TrieLongField" precisionStep="0" positionIncrementGap="0"/& 7 &fieldType name="double" class="solr.TrieDoubleField" precisionStep="0" positionIncrementGap="0"/& 8 &fieldType name="tint" class="solr.TrieIntField" precisionStep="8" positionIncrementGap="0"/& 9 &fieldType name="tfloat" class="solr.TrieFloatField" precisionStep="8" positionIncrementGap="0"/&10 &fieldType name="tlong" class="solr.TrieLongField" precisionStep="8" positionIncrementGap="0"/&11 &fieldType name="tdouble" class="solr.TrieDoubleField" precisionStep="8" positionIncrementGap="0"/&12 &fieldType name="date" class="solr.TrieDateField" precisionStep="0" positionIncrementGap="0"/&13 &fieldType name="tdate" class="solr.TrieDateField" precisionStep="6" positionIncrementGap="0"/&14 &fieldType name="pint" class="solr.IntField"/&15 &fieldType name="plong" class="solr.LongField"/&16 &fieldType name="pfloat" class="solr.FloatField"/&17 &fieldType name="pdouble" class="solr.DoubleField"/&18 &fieldType name="pdate" class="solr.DateField" sortMissingLast="true"/&19 &fieldType name="sint" class="solr.SortableIntField" sortMissingLast="true" omitNorms="true"/&20 &fieldType name="slong" class="solr.SortableLongField" sortMissingLast="true" omitNorms="true"/&21 &fieldType name="sfloat" class="solr.SortableFloatField" sortMissingLast="true" omitNorms="true"/&22 &fieldType name="sdouble" class="solr.SortableDoubleField" sortMissingLast="true" omitNorms="true"/&23 &fieldType name="random" class="solr.RandomSortField" indexed="true" /&
这里给出的类型有，字符串，bool，int，date等等，基本java常用的都有。下面解释一下各个参数的意思。
name：定义搜索字段名
class：这个搜索字段实际使用的类与方法。在org.appache.solr.analysis包下，包括了常用的类型。
其他可选的属性：&
sortMissingLast，sortMissingFirst两个属性是用在可以内在使用String排序的类型上，默认false，适用于字段类型：string,boolean,sint,slong,sfloat,sdouble,pdate。
sortMissingLast="true"，没有该field的数据排在有该field的数据之后，而不管请求时的排序规则，在Java中对应的意思就是，该字段为NULL，排在后面。
sortMissingFirst="true"，排序规则与sortMissingLast相反。
positionIncrementGap：可选属性，定义在同一个文档中此类型数据的空白间隔，避免短语匹配错误。&
在配置中，string类型的class是solr.StrField，而这个字段是不会被分析存储的，也就是说不会被分词。
而对于文章或者长文本来说，我们必须对其进行分词才能保证搜索某些字段时能够给出正确的结果。这时我们就可以用到另外一个class，solr.TextField。它允许用户通过分析器来定制索引和查询，分析器包括一个分词器（tokenizer）和多个过滤器（filter） 。
下面就来看一下中文分词吧，这里用的分词是IK Analyzer 2012。
1 &!-- IKAnalyzer2012 --& 2 &fieldType name="text_ika" class="solr.TextField"& 3
&analyzer type="index" positionIncrementGap="100" autoGeneratePhraseQueries="true"& 4
&tokenizer class="org.wltea.analyzer.solr.IKTokenizerFactory" isMaxWordLength="false"/& 5
&!-- &filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" /& --& 6
&!-- &filter class="solr.LowerCaseFilterFactory"/& --& 7
&/analyzer& 8
&analyzer type="query"& 9
&tokenizer class="org.wltea.analyzer.solr.IKTokenizerFactory" isMaxWordLength="true" /&10
&!-- &filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" /& --&11
&!-- &filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/& --&12
&!-- &filter class="solr.LowerCaseFilterFactory"/& --&13
&/analyzer&14 &/fieldType&
分词用的依旧是fieldType，为的是在下面的field中能够用到。
有两个analyzer，一个是index，一个是query，index是针对于所有，query是针对于搜索。
可以看到我注掉了两个filter，为什么呢。
先说简单的吧，一个是query中的同义词Filter，solr.SynonymFilterFactory，注掉他是因为当前没有一个庞大的词库能够支撑中文如此复杂的同义词量。
另外一个是忽略大小写的Filter，这个Filter可以根据自己的需要进行添加或删除，在我们的系统中，主要处理中文，这个用处也不大。
还有一个注掉的Filter是停词Filter，这个用处挺大的，为什么注掉呢？因为我感觉他在这里不太合适。
解释一下：停词组件在中文分词中很重要，IK也提供了相对应的配置方法，不仅仅可以处理停词，而且还可以自定义词库。所以，我建议将停词在IK中配置而不是在schema.xml中。
两种方法都说一下：
第一种：在schema.xml中配置，不要注释stopword组件，并将停词文件拷贝至solrHome/core/conf目录下（注意文件的编码方式，至少保证文本文件是UTF-8格式，更加严格的，保证文本文件是无BOM格式的UTF-8编码）。
第二种：在IK配置文件中配置，请下载一个IK分词组件，里面会有一个IKAnalyzer.cfg.xml的配置文件，拷贝到solr项目的源代码根目录下，并将stopword.dic也拷贝到根目录下，如下图所示：
记得要导入IK的Jar包，这样，在你的文件中就可以使用IK提供的中文分词了。
&给一个我用的stopword.dic，去下载。
IK也可以自定义词库，这个可以看一下IK的文档，很简单，将你的自定义词库的文件拷贝至根目录，并在IK配置文件中配置即可。
&fields&&/fields&节点
filed字段用于定义数据源字段所使用的搜索类型与相关设置。
1 &field name="id" type="long" indexed="true" stored="true" multiValued="false" required="true" /& 2 &field name="name" type="text_ika" indexed="true" stored="true" multiValued="false" /& 3 &field name="address" type="text_ika" indexed="true" stored="true" multiValued="false" /& 4 &field name="description" type="text_ika" indexed="true" stored="true" multiValued="false" /& 5 &field name="saturdayMerchant" type="boolean" indexed="true" stored="true" multiValued="false" /& 6 &field name="huiMerchant" type="boolean" indexed="true" stored="true" multiValued="false" /& 7 &field name="bankMerchant" type="boolean" indexed="true" stored="true" multiValued="false" /& 8 &field name="rebate" type="int" indexed="true" stored="true" multiValued="false" /& 9 &field name="valid" type="boolean" indexed="true" stored="true" multiValued="false" /&10 &field name="createTime" type="date" indexed="true" stored="true" multiValued="false" /&11 &field name="priority" type="int" indexed="true" stored="true" multiValued="false" /&12 &field name="telephone" type="string" indexed="true" stored="true" multiValued="false" /&13 &field name="city" type="text_ika" indexed="true" stored="true" multiValued="false" /&14 &field name="district_id" type="long" indexed="true" stored="true" multiValued="false" /&15 &field name="district_name" type="text_ika" indexed="true" stored="true" multiValued="false" /&16 &field name="merchantCategory_id" type="long" indexed="true" stored="true" multiValued="false" /&17 &field name="merchantCategory_name" type="text_ika" indexed="true" stored="true" multiValued="false" /&18 &field name="bank_id" type="long" indexed="true" stored="true" multiValued="true" /&19 &field name="bank_name" type="text_ika" indexed="true" stored="true" multiValued="true" /&20 21 &field name="all" type="text_ika" indexed="true" stored="false" multiValued="true" /&
name：数据源字段名，搜索使用到。
type：搜索类型名例如中文ika搜索名text_ika，对应于fieldType中的name。不需要分词的字符串类型，string即可，如果需要分词，用上面配置好的分词type。
indexed：是否被索引，只有设置为true的字段才能进行搜索排序分片(earchable, sortable, facetable)。
stored：是否存储内容，如果不需要存储字段值，尽量设置为false以提高效率。
multiValued：是否为多值类型，SOLR允许配置多个数据源字段存储到一个搜索字段中。多个值必须为true，否则有可能抛出异常。
copyField节点
如果我们的搜索需要搜索多个字段该怎么办呢？这时候，我们就可以使用copyField。代码如下：
1 &copyField source="name" dest="all" /&2 &copyField source="address" dest="all" /&3 &copyField source="description" dest="all" /&4 &copyField source="city" dest="all" /&5 &copyField source="district_name" dest="all" /&6 &copyField source="merchantCategory_name" dest="all" /&7 &copyField source="bank_name" dest="all" /&
我们将所有的中文分词字段全部拷贝至all中，当我们进行全文检索是，只用搜索all字段就OK了。
注意，这里的目标字段必须支持多值，最好不要存储，因为他只是做搜索。indexed为true，stored为false。
copyField节点和field节点都在fields节点之内。
问题又来了，如果需要根据不同的重要性进行区分，例如name的重要性比address大，该怎么办呢，后面再说这个问题。
uniqueKey节点
solr必须设置一个唯一字段，常设置为id，此唯一一段有uniqueKey节点指定。
1 &uniqueKey&id&/uniqueKey&
defaultSearchField节点
默认搜索的字段，我们已经将需要搜索的字段拷贝至all字段了，在这里设为all即可。
1 &defaultSearchField&all&/defaultSearchField&
solrQueryParser节点
默认搜索操作符参数，及搜索短语间的逻辑，用AND增加准确率，用OR增加覆盖面，建议用AND，也可在搜索语句中定义。例如搜索&河西 万达&，使用AND默认搜索为&河西AND万达&。
1 &solrQueryParser defaultOperator="OR"/&&
schema.xml配置和solrj的使用 前面讲到如何搭建solr运行环境以及对中文查询语句进行分词处理,这篇文章主要讲解对schema.xml的相关配置和如何使用solrj
对于搜索程序来说,最重要的是理解他的总体架构.solr也是基于Lucene的全文搜索服务器.同时对其进行了扩展,提供了比Lucene更为丰富的查询语言,同时实现了可配置.可扩展并对 ...
为Android自定义部件实现自定义的XML配置属性 Custom XML Attributes For Your Custom Android Widgets 原文作者 Kevin Dion
翻译:佣工7001
原文在这儿
是否有一种方便的方法能够在XML layout文件中声明自定义部件的回调函数呢?(就像声明SDK ...
标签:solrj 原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://
前面讲到如何搭建solr运行环境以及对中文查询语句进行分词处理,这篇文章主要讲解对schema.xml的相关配置和如何使用solrj
对于搜索程 ...
schema.xml用于定义文档的字段.字段类型以及其他相关信息.以下是一个schema.xml的示例,转自http://blog.csdn.net/jediael_lu/article/details/ &?xml version=&1.0& encoding=&UTF-8& ?& &lt ...
常见的元素 &field name=&weight& type=&float& indexed=&true& stored=&true&/&&dynamicField name=&*_is& type=&int& inde ...}