1. 什么是MultiValues，如何建立索引: solr的schema.xml配置文件在配置Filed的时候，有个属性： MutiValued：true if this field may containmutiple values per documents，这个说明有点模糊，下面结合实际应用，列举两个不同的例子。 例子一：一个field有多个值MultiValue，值来自同一filed, 如： <field name=”executor” type=”int” indexed=”true” stored=”true” multiValued=”true” / executor这个field可以多个值，任何executor:29 OR executor:40，类似查询都能查出id为3的记录。 附注：使用solrj建此索引时，定义成集合类型即可，如： @Field private Set<Integer> executor; public Set<Integer> getExecutor() { return executor; } public void setExecutor(Set<Integer> executor) … 继续阅读 →

之前我们利用 Solr现成的LRU对Core进行动态加载 http://jacoxu.com/?p=595，但是有个问题是先注册的core都没有进入加载的LRU队列中，可以通过界面显示：http://localhost:8983/solr/admin/cores?action=STATUS 返回所有的状态，未加载的core的 isLoaded属性是false。不过4.6版本修复了个这个bug，可以进行尝试。对于大数据来说，这个bug的修复无疑是值得庆祝的！ 下面我们来做一个测试，尝试在单个solr实例中创建万级规模的core， 1、测试单实例最大Core数和实例数，测试环境：Linux-Suse11.1 24processors, 2.0GHz, 64G RAM. ，申请内存16G 【试验】：每个core有545条短文本，测试在单实例中创建25000个core，从创建第一个core只用了0.3秒，到第3500个core用了1.1秒，创建新core速度都很快，并没有太大影响。目前所有的core都处于加载状态，打开文件数已经达到25469，使用内存达9G，下面重启tomcat使得目前加载的core进入LRU队列中。重启之后，只打开了1个core，其他所有的core进入未索引数据未加载状态。 然后重启入库程序，继续创建新core，此时创建速度很慢，Solr基本处于卡死状态。创建一个新core用了7分钟，最重要的是，这段时间内，基本无法完成其他基本查询功能。 停掉入库程序之后，Tomcat仍然处于卡死状态，重启tomcat 尝试更新Solr最新版本4.6，创建一个core只使用了0.2秒，创建到3500个core时也只使用0.3秒。而且，所有的core都在LRU-100队列中进行动态加载。文件打开数维持在800左右，内存使用峰值为7G。 接下来把LRU设为50，重启tomcat后继续插数据，测试单实例的CoreList上限 注意由于文件夹同级目录有上限32000，所以最好同时写入到多个目录中去。 持续创建新core，LRU-50，创建到6K左右时，内存占用率达8G左右，创建新core在0.5秒左右，commit 5000条数据在0.5秒左右，文件打开数维持在300左右。创建到1W7左右的时候，Tomcat内存使用到15G，文件打开数维持在300左右，创建一个新core 1秒左右，插入5000条数据使用0.6秒或26秒，重启tomcat，界面初始化时反应有些迟钝 有10分钟之久，入库程序可正常插入，创建到25000个core时，创建Core的速度仍然很快，不超过2秒，不过持续写入数据出现JVM GC问题，有时会稍慢一些到1分钟左右。值得注意的是重启tomcat居然用了45分钟之久，想必是刷了一遍每个core的STATUS，这个操作很会很慢，此时Tomcat只占用了一个processor的100%CPU进行处理。 我们尝试下一个试验，把25000个core分布到10个实例中去，减少每个实例所维护的CoreList，或许刷新Core STATUS的时候多个实例能够并发。在入库时，查看CPU的状态能够发现，单线程写入Solr多实例时，虽然Tomcat基本也占用100%左右的CPU，但是会分布到多个CPU上。由于时间问题这个试验没有做完，只索引了14000个core，此时重启tomcat用了不到3分钟，时间尚可接受，待进一步后续验证。 另一点值得注意的是，tomcat下的实例数并非可以无限制增加，在SuSE-11.1 64G环境下曾部署过10个实例没有问题，但是在SuSE-11.2 256G环境下部署6个实例就无法启动，报出如下错误： OutOfMemoryError thrown from the uncaughtExceptionHandler in thread “main” OutOfMemoryError thrown from the … 继续阅读 →

下面是转来的一篇文章，经过测试使用，OK。不过要注意的问题是，既然id是自动生成的，那么如果有两份一模一样的数据建立索引的时候会有各自不同的id而保存多份数据，如果id由自己来指定的话就比较方便以后数据更新。 原地址：http://blog.csdn.net/keepthinking_/article/details/8501058 最近学习了Lucene，随便也学习了Solr，Solr规定每一条记录必须有一个主键值，用来唯一标识一条索引的记录，默认是使用id字段来作主键的（可以通过修改schema.xml文件更改），最烦的是这个主键不能设置自动增长，所以每添加一条记录，不得不手动为id字段赋值，如果不小心重复了，还很恶心的直接覆盖了原来的记录，所以在编程的时候不得不通过一些途径来维护这个id值，通过google发现了一个可以自动生成id值的方法，即让solr自动生成UUID值（Universal Unique Identifiers通用唯一标识符），这样编程的时候就不用维护这个id值了，使用这种做法的缺点就是：id值不是数值连续的，它是一串字符，如：5bb977a7-8a4c-46d6-ae49-b4eefade080c 具体配置如下：（这是Solr 4.0的配置） 一、配置schema.xml文件 1、添加fieldType <types>       <!– other field types –>       <fieldType name=“uuid” class=“solr.UUIDField” indexed=“true” />   </types>   2、添加主键id字段配置（注释或者删除原来的id字段配置，切记） <field name=“id” type=“uuid” indexed=“true” stored=“true” required=“true” multiValued=“false” />   二、配置solrconfig.xml文件 1、注释掉以下的配置，原因及可能产出的异常参考：https://issues.apache.org/jira/browse/SOLR-3398 <searchComponent name=“elevator” class=“solr.QueryElevationComponent” >     <str name=“queryFieldType”>string</str>     <str name=“config-file”>elevate.xml</str>   </searchComponent>   2、添加一个updateRequestProcessorChain配置 <updateRequestProcessorChain name=“uuid”>       <processor class=“solr.UUIDUpdateProcessorFactory”>           <str name=“fieldName”>id</str>       </processor>       <processor class=“solr.RunUpdateProcessorFactory” />   </updateRequestProcessorChain>   3、修改其中一个requestHandler配置，注意：上一步是添加，而这里是修改，如果直接添加的话，那么就会重复配置，这样后面的配置会覆盖前面的配置，本人就是很不幸的被默认的配置覆盖了我添加的配置，当时够郁闷的！ <requestHandler name=“/update” class=“solr.UpdateRequestHandler”>       <!– See below for information on defining              updateRequestProcessorChains that can be used by name              on each Update Request          –>       <!–           <lst name=“defaults”>   … 继续阅读 →