Shell-vi替换指定文件中的内容-自动修改SolrLRU

【需求】:利用Shell脚本替换指定文件中的一段数字内容,需要进行模糊匹配。 【具体场景】:自动修改Solr下的LRU参数,并自动重启检索服务 #!/bin/bash    #auther:Jacob Xu 20141102, create for up LRU parameter of Solr    echo “====================== set the configure for solr! ====================”   solrPath=/var/solr/apache-tomcat-7.0.39_ubuntu_29.2_analysis_7080/    echo “solrPath=”$solrPath   newLRU_Num=250    echo “newLRU_Num=”$newLRU_Num      ################## configure solr.xml for solr!###################    rawSolrHome_norm=$solrPath“webapps/analysisNorm001/solrHome/”   rawSolrHome_spam=$solrPath“webapps/analysisSpam001/solrHome/”      ##################################################################    if [ -d "/var/solr/apache-tomcat-7.0.39_ubuntu_29.2_analysis_7080" ]     then            echo “begin to shutdown solr …”           echo $solrPath“bin/shutdown.sh”           bash $solrPath“bin/shutdown.sh”           sleepTime=20            for((;sleepTime>0;sleepTime–))            do                   printf “\rplease waiting ${sleepTime} seconds…”                   sleep 1s            done            kill -9 $(pgrep ${solrPath} -f)    … 继续阅读

修改Solr源码自定义远程核创建和删除操作

【版本】:Solr 4.6(服务端),Solr 4.4(客户端) 注:唉,由于当初项目的原因,导致服务端和客户端 版本不一致,不过还好 接口是兼容的,而且主要功能由服务端完成,因而 各个版本的Solr下载地址:http://archive.apache.org/dist/lucene/solr/ 【需求】: 1. 注册核:可以通过HTTP请求动态着创建对应文件夹,并注册一个Solr新Core; 2. 删除核:可以通过HTTP请求动态删除指定Core,不止要删除索引数据,还要把整个实例文件夹全部删除,要删除干净! 修改:solr-4.6.0-src\solr\core\src\java\org\apache\solr\core\CoreContainer.java 文件

SOLR-3955: Return only matched multiValued field

一个让人纠结的问题,放到前面:Return only matched multiValued field: https://issues.apache.org/jira/browse/SOLR-3955 org.apache.solr.handler.RequestHandlerBase 下有一个函数 public void handleRequest(SolrQueryRequest req, SolrQueryResponse rsp) 官方接口文档:solr-4.6.0/docs/solr-core/index.html – org.apache.solr.handler 【参考】: 1. Solr查询过程源码分析 2.

Solr MultiValues

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那点事儿

1. 无论读和写io都是本质瓶颈,固态盘用起来是很爽的,linux下大内存通过缓存也能大大减少io的使用率; 2. solr4.7之后提供了游标方式以解决深页查询问题,但是应避免使用它,因为它是基于sort排序和范围检索实现的,排序会消耗很大的io,应尽可能避免它!!!血的教训!可利用时间切片加浅深翻方式进行查询; 3. solr4.4的问题,solr core不能太多3K左右就会很慢,solr core的lru队列中加载不了新core。solr4.9的问题,同一个tomcat下部署了多实例,通过lru加载或者创建一个1KW的新core速度很慢! 4. 并发写同一个core基本提速很少而且会出现重复写数据问题,而多线程同时写不同的core则基本程线性倍数提高! 5. Solr入库的瓶颈在CPU主频,Solr检索的瓶颈在IO,并发检索排序查询的瓶颈在内存。 6. LRU加载多少个核合适的问题: 对于微博文本这样的内容,原始文本平均4M/W的存储空间,建立索引后,平均为5G/2KW存储,SOLR加载2KW的一个CORE主要为加载词典文件和打开文件操作符,大致消耗60M空间。平均加载一个这样的CORE在2秒左右 7. 今天加大内存到148G,并提高LRU到2000,共用了三台服务器,数据量到达420亿,共3600个核进行5个线程的并发检索,首次检索达12分钟,而再次相同条件检索仅6秒!

Tomcat+Solr配置安装

【版本】Java JDK: 1.8.25, Tomcat: 8.0.11, Solr: 4.9. 1. 从网上下载Tomcat最新版本,解压; 2. 定制端口号:修改./tomcat/conf/server.xml 中的所有端口 8*** 改为 7***(只要是端口都要进行改动); 3. 修改Tomcat 连接超时 和 编码格式: </Connector port=”7080″ protocol=”HTTP/1.1″ connectionTimeout=”1000000″ redirectPort=”7443″ maxPostSize=”0″ URIEncoding=”UTF-8″/> 4. Tomcat下安装Solr,Copy solr-4.9.0\example\webapps\solr.war 到apache-tomcat-8.0.11_analysis_7080\webapps 目录下,然后启动apache-tomcat-8.0.11_analysis_7080\bin\startup.bat ,则solr.war可以自动解压到tomcat里面,然后删除solr.war; 5. 修改实例名-文件夹名solr 为 analysisNorm001; 6. 订制apache-tomcat-8.0.11_analysis_7080\webapps\analysisNorm001\WEB-INF\web.xml中的solrHome路径 <env-entry> <env-entry-name>solr/home</env-entry-name> <env-entry-value>../webapps/analysisNorm001/solrHome/</env-entry-value> … 继续阅读

Solr/Lucene的排序机制

以下内容转自:http://hi.baidu.com/shirdrn/item/c5611d1556921a0cb98a1aa4 关于Lucene得分的计算。 在IndexSearcher类中有一个管理Lucene得分情况的方法,如下所示: public Explanation explain(Weight weight, int doc) throws IOException { return weight.explain(reader, doc); } 返回的这个Explanation的实例解释了Lucene中Document的得分情况。我们可以测试一下,直观地感觉一下到底这个Explanation的实例都记录了一个Document的哪些信息。 写一个测试类,如下所示: package org.shirdrn.lucene.learn; import java.io.IOException; import java.util.Date; import net.teamhot.lucene.ThesaurusAnalyzer; import org.apache.lucene.document.Document; import org.apache.lucene.document.Field; import org.apache.lucene.index.CorruptIndexException; import org.apache.lucene.index.IndexWriter; import org.apache.lucene.index.Term; import org.apache.lucene.index.TermDocs; import org.apache.lucene.search.Explanation; … 继续阅读

再谈Solr core LRU–注册3W个SolrCore索引大数据

之前我们利用 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 … 继续阅读

Solr4.0 如何配置使用UUID自动生成id值

下面是转来的一篇文章,经过测试使用,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”>   … 继续阅读

Deep paging problem of solr, start设置越大查询越慢

进行solr查询时,如果查询结果很多而且业务需求需要全部返回时,传统的搜索引擎都会遇到一个棘手的问题:deep paging problem,即当翻页查询越多时,查询响应时间越长。传统的搜索服务如Baidu,Google 一般只提供1000以内的查询结果共用户查阅,如果需要更多的查询结果,用户可以输入更多的查询语句进行筛选。 下面利用Apache Solr进行deep page查询的性能测试: 【测试数据】:规模: 499W,内容一样(饲荆泞琴哇尘自缕勇恩本灾却咀功害鳃踪羽甲沏馏铆级奉耻陷下龄周),时间不同。 【机器性能】:64G内存 Linux-Suse 【测试一,翻页查询499W所有结果】 查询条件为rows为10000,timeAllowed为86400000 (即为一天), content为 饲荆泞琴哇尘自缕,进行rows=1W的翻页查询,查询的相应时间如下: 原始结果数据 单次查询结果数 单次查询耗时/ms 查询后结果总数 10000 1585 10000 10000 1585 20000 10000 1682 30000 10000 1818 40000 10000 1934 50000 … 10000 100138 4950000 10000 … 继续阅读