优化solr中那难缠的facet

solr中facet功能对于特定字段的统计任务非常实用,可以对特定字段的term进行统计排序,对于单核的小数据来说还好,但是当数据变得很大时,需要进行multicore进行shards查询时,facet功能消耗的内存会异常的高。 对于solr4.2版本来说,通过facet.offset和facet.limit可以实现翻页查询,通过小翻页能够降低内存的使用。但是并不是可行之计,测试进行每页1个结果的翻页,在亿级规模多核上的facet查询还是会很快把64G服务器的JVM爆掉。如果只是去找很少的一些结果,另一种可以人工简化的操作是进行逐一单核查询,取topN,然后扔给前端归并,效果会好很多。 大规模的全局facet功能本是件很头疼的事,solr4.4版本在schema.xml中增加了一个字段属性 docValues, (其实是从4.2版本开始就有了,不过schema中没有介绍,而且并没有完善其功能,所以被忽视了) 在solr4.4中能对solr的facet功能进行优化的有两点: 1. docValues,配置方法:在schema.xml中的字段配置添加docValues属性,例: <field name=“test” type=“string” indexed=“true” stored=“false” docValues=“true” omitNorms=“true” default=“”/>   2. 在schema.xml中为facet配置一特殊的fieldType, String_disk. 这样能够大量节省很多的内存,因为默认的配置方法是docValuesFormat=”Lucene42″,相关更多介绍可以参见docValues: <fieldType name=“string_disk” class=“solr.StrField” docValuesFormat=“Disk” />   配置特殊订制的字段需要在solrconfig.xml中进行相应的配置: <codecFactory class=“solr.SchemaCodecFactory”/>   通过上面的两种配置方法能够大手笔的优化solr中比较难缠的facet爆JVM问题。

获取当前solr.xml中register的所有coreName

有时候需要通过对solr实例URL的一次http访问,获得该实例当前register的存活core,实现方法如下: public static List<String> GetShardsList(String serverName) {        List<String> shardlist = new ArrayList<String>();        //http://localhost:8080/solr        HttpSolrServer server = new HttpSolrServer(serverName);        server.setConnectionTimeout(1000);        server.setDefaultMaxConnectionsPerHost(100);        server.setMaxTotalConnections(100);        server.setRequestWriter(new BinaryRequestWriter());        // Get Shards        SolrQuery solrQuery = new SolrQuery();        solrQuery.setParam(CommonParams.QT, “/admin/cores”);        solrQuery.setParam(CoreAdminParams.ACTION, CoreAdminParams.CoreAdminAction.STATUS.name));        QueryResponse ds = null;        try {            ds = server.query(solrQuery);        } catch (SolrServerException e1) {            // TODO Auto-generated catch block            e1.printStackTrace();        }        NamedList<NamedList<Object>> ctLst = (NamedList<NamedList<Object>>)ds.getResponse().get(“status”);// 得到响应的头信息 … 继续阅读

利用solrj加载卸载solr多核并更新solr.xml

在使用solr多核时会有这样的需求,动态的加载卸载新core,并更新solr.xml 这样的实现比较容易,实验版本为solr4.2,solr5之后可能会有比较大的改动,还没有出,目前solr4.4的solr.xml配置还是兼容的: 1.动态加载新core public  static void load_solrCore(String coreName, String insPath, String serverName){              try {               //path=”D:/jacoxu/solrHome/multicore/collection0″;            //serverName=”http://localhost:8080/solr”;            HttpSolrServer tempServer= solrServer.setServer(serverName);               CoreAdminRequest.createCore(coreName, insPath, tempServer);           } catch (Exception e) {               e.printStackTrace();           }       }     2.动态卸载旧core public static void unload_solrCore(String coreName, String serverName) {        try {            HttpSolrServer tempServer= solrServer.setServer(serverName);            CoreAdminRequest.unloadCore(coreName, tempServer);        } catch (Exception e) {            e.printStackTrace();        }    }   3.有时在执行上面两个操作的时候需要动态的更新solr.xml,因为如果突然断电或solr服务重新启动,都需要重新初始化solr.xml文件中的多核配置,为了能恢复中断前的多核状态需要能够实时根据上面的两个操作更新solr.xml 只需要配置solr.xml中 … 继续阅读

订制tomcat下的logs输出路径

tomcat输出的日志比较多,对于处理实时数据流的实例,每天可以产生上百M的log日志,位于tomcat/logs目录下,维护一个完整的大系统,希望自定义一个日志路径,但是tomcat日志过于繁多。对于一个使用solr4.4版本实例的tomcat用户来说,需要修改的地方大致有4个地方: 1,修改tomcat/conf/logging.properties 中的${catalina}/logs 路径 –> 所有的.log日志 1catalina.org.apache.juli.FileHandler.level = FINE #设置日志级别 1catalina.org.apache.juli.FileHandler.level = FINE #日志级别为FINE 1catalina.org.apache.juli.FileHandler.level = OFF #禁用日志输出 1catalina.org.apache.juli.FileHandler.level = ALL #输出所有日志 级别一般分为:SEVER > WARNING > INFO > CONFIG > FINE > FINER > FINEST 2,修改tomcat/conf/server.xml中最后的directory=”logs”路径 -> localhost.date.txt日志 不需要时,注释掉以下代码即可 <!– … 继续阅读

关于Solr的各种DirectoryFactory

看到一个关于Solr的中文Book网站,介绍的有些简易,不过专注于Solr值得关注:http://www.solrcn.com/books/ 最近快被Solr的Map Failed快弄崩溃了==b,继续调研。。。,还没好。下面从中摘一段关于SolrDirectoryFactory的配置, Apache Lucene 以及 Solr 一个重要的属性是 Lucene 目录实现。目录接口为 Lucene 提供抽象的 IO 操作层。尽管选一个目录实现看起来很简单,但是在极端情况下,它会影响性能。以下将为你讲解如何选择正确的目录实现。 为了使用期望的目录,要做的就是选择正确的目录实现的工厂类,然后告知 solr。假设你打算使用 NRTCachingDirectory 作为你的目录实现,为了实现这个,需要在 solrconfig.xml 中设置以下内容: 这就是所有要做的,很简单,但是有哪些工厂可用呢,在Solr4.2版本中,有以下工厂可用: solr.StandardDirectoryFactory solr.SimpleFSDirectoryFactory solr.NIOFSDirectoryFactory solr.MMapDirectoryFactory solr.NRTCachingDirectoryFactory solr.RAMDirectoryFactory 现在,让我们分别看看每个工厂。 在深入了解每个工厂的细节前,我们先了解一些工厂的配置参数。directoryFactory 的参数一共两个,一个是 name,name 要设置成 “DirectoryFactory”,另外一个是 class,class 设置成我们所选的工厂实现类。 打算让 solr 自行决定使用哪个工厂时,可以使用 solr. StandardDirectoryFactory。该实现是基于文件系统形式的,依赖当前操作系统和 … 继续阅读

Solr4.2-矫情的shards, facet

使用Solr的分布式多核查询时,Solr提供了shards方便大家使用,只需要设定 SolrQuery.set(“shards”,shardsStr)   即可,但是实际操作中遇到很多问题,首先是shards参数的格式问题,shards参数一定要是以下形式,否则异常报错: String shardsStr = 127.0.0.1:8080/solr/core1,127.0.0.1:8080/solr/core2,127.0.0.1:8080/solr/core3;     shards的好处是很方便的根据需求,在分布式的多服务器多核中进行查询任务,只需配置不同的ip,不同的core即可。facet是Solr另一个很方便的功能,可以根据字段进行统计并进行排序,做多核分布查询时,如果能把shards和facet并用可以免去很多人工后期分布合并并排序的麻烦,因为对于上亿的海量数据来说,进行合并统计并排序无疑是个费时费力的事,如果Solr有良好的数据结构支持这项工作的话就perfect啦。但是使用的过程中遇到了问题,单核测试OK,但是shards多核测试异常: <response>   <lst name=“responseHeader”>   <int name=“status”>500</int>   <int name=“QTime”>7320</int>   <lst name=“params”>   <str name=“facet.missing”>false</str>   <str name=“facet”>true</str>   <str name=“shards”>   127.0.0.1:8080/solr/core1,127.0.0.1:8080/solr/core2,127.0.0.1:8080/solr/core3    </str>   <str name=“facet.mincount”>1</str>   <str name=“start”>0</str>   <str name=“facet.sort”>count</str>   <str name=“q”>*:*</str>   <str name=“facet.limit”>1000</str>   <str name=“facet.field”>groupSend</str>   <str name=“rows”>100000</str>   </lst>   </lst>   <lst name=“error”>   <str name=“msg”>   java.lang.RuntimeException: Invalid version (expected 2, but 60) or the data in not in ’javabin’    format    </str>   <str name=“trace”>   org.apache.solr.common.SolrException: java.lang.RuntimeException: Invalid version (expected 2,    but 60) or the data in not in ’javabin’ format at    org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:302) at    org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at  … 继续阅读