亚洲综合在线另类色区奇米,区三区激情福利综合中文字幕在线一区亚洲视频1 ,亚洲国产精品一区二区久久

Solr 获取searcher实例分析(�?

CONAN — Wed, 13 Jun 2012 06:17:00 GMT

每一个搜索请求都�?x��)持有一个searcher的引用，而不是创��Z��个新的searcher�Q�处理完后会(x��)释放掉这个引�?/strong>�?br />
Solr在初始化化时�Q�通过SolrCore核心(j��)�c�要做很多的初始化工作，包过��d��solrconfig.xml配置文�g里的内容�Q�代码如下：(x��)

booleanQueryMaxClauseCount(); //讄��布尔查询最多个数�?br /> initListeners(); //��d��配置文�g的search实例的监听器�?br />    initDeletionPolicy();
    initIndex();
    initWriters();
    initQParsers();
    initValueSourceParsers();
    this.searchComponents = loadSearchComponents();
    // Processors initialized before the handlers
    updateProcessorChains = loadUpdateProcessorChains();
    reqHandlers = new RequestHandlers(this);
    reqHandlers.initHandlersFromConfig( solrConfig );
    highlighter = initHighLighter();
    // Handle things that should eventually go away
    initDeprecatedSupport();

loadSearchComponents�Ҏ(gu��)��是初始化indexSearch实例。详�l�说明如下：(x��)
getSearcher – (forceNew, returnSearcher, waitSearcher-Futures)
��x(ch��ng)��solr全局三个点调用getSearcher函数 : solrCore初始化时(false, false, null)�Q�QueryComponent处理查询
��h��?false, true, null)�Q�UpdateHandler在处理commit��h��?true, false, new Future[1])
---------
1.solrCore初始化时
�Ҏ(gu��)��solrconfig配置的IndexReaderFactory&DirectoryFactory获取索引的IndexReader�Q�再使用�q�个reader
��装一个SolrIndexReader�Q�再使用�q�个SolrIndexReader��装一个RefCounted(searcher的引用计数器�Q�当搜烦(ch��)
�l��g获取一个组件后引用++�Q�用完后调用close引用--�Q�当引用��Cؓ(f��)0时将�q�个引用从core��理的一个当前被使用�?br />searcher的链表移除，同时调用searcher.close回收资源)�Q�将�q�个引用��d��到core��理的一个当前被使用的searcher
的链表里如果firstSearcherListeners不�ؓ(f��)�I�则回调�q�些监听器，�q�个回调是交�l�core的一个newSingleThreadExecutor�?br />做的�Q�再往�q�个�U�程池里��d��一个�Q�?��这个RefCounted讄��为core当前最新的searcher的引用计数器
最后返回null�Q�因为returnSearcher=false
在solrCore初始化时�q�样做的主要目的是在初始化时��加载好IndexSearcher�Q�搜索请求来�?ji��n)之后能立即�q�回�Q?br />而不必等待加载IndexSearcher
---------
2.QueryComponent处理查询��h��?br />�׃��core当前最新的searcher的引用计数器不�ؓ(f��)null且这个获取IndexSearcher的请求不是强制要求获取最新的�Q�且
returnSearcher=true故直接返回core当前最新的searcher的引用计数器�Q�且�q�个引用计数器做++
�q�里面还有段当前searcher的引用计数器为null的逻辑�Q�但是没有发现有什么情况会(x��)��D��q�种情况发生故不累述�?br />---------
3.UpdateHandler在处理commit��h��?br />首先到core��理的一个当前被使用的searcher的链表里获取目前最新的searcher�Q�同时会(x��)加蝲索引目录下的
index.properties文�g(如果存在的话)�Q�拿到KEY=’index’的��|��其指明目前烦(ch��)引的存放地方�Q�如果获取的目录和当�?br />最新的searcher使用的目录一致且solrConfig.reopenReaders为true则获取通过searher.reader.reopen获取
最新的reader -> ��装成searcher�Q�否则直接IndexReader.open获取reader�?br />获取到searcher后的一�D�逻辑[RefCount��装�Q�添加到searchers链表]和core初始化时是一��L(f��ng)��Q�接下来的逻辑�?br />如果solrConfig.useColdSearcher为TRUE其当前searcher的引用�ؓ(f��)null-��D��来自QueryComponent的请求阻�?br />[现在�q�没发现什么情况会(x��)��D��searcher的引用�ؓ(f��)null]
立即��这个新的searcher的引用设�|��ؓ(f��)core当前最新的searcher的引用计数器�Q�这��h��自QueryComponent的请�?br />拿到�q�个引用后返回，当时�q�时�q�个新徏的searcher是没有经�q�其前一个searcher的cache热��n的，同时�q�样�?x��)导致这�?br />新徏的searcher不会(x��)�q�行热��n�z�d��
如果solrConfig.useColdSearcher为FALSE则会(x��)往�U�程池里��d��一个热�w�的��d��
如果newSearcherListeners不�ؓ(f��)�I�则回调�q�些监听器，也是�l�线�E�池的�Q�?br />最后如果先前没有做��新的searcher的引用设�|��ؓ(f��)core当前最新的searcher的引用计数器的行为的话，则往�U�程池添�?br />一个�Q�?– ��新的searcher的引用设�|��ؓ(f��)core当前最新的searcher的引用计数器
最后返回null�Q�因为returnSearcher=false

from:http://blog.sina.com.cn/s/blog_56fd58ab0100v3tp.html

CONAN 2012-06-13 14:17 发表评论

olr 性能调优 NO_NORMS(�?

CONAN — Wed, 13 Jun 2012 06:16:00 GMT

indexed fields

    indexed fields 的数量将�?x��)�?ji��ng)响以下的一些性能�Q?/p>
        索引时的时候的内存?sh��)��用�?/li>
        索引�D늚�合�ƈ旉��
        优化旉��
        索引的大��?/li>

     我们可以通过 ��?omitNorms=“true” 来减��indexed fields数量增加所带来的媄(ji��ng)响�?/p>
   stored fields

      Retrieving the stored fields ��实是一�U�开销。这个开销�Q�受每个文��所存储的字节媄(ji��ng)响很大。每个文档的所占用的空间越大，文��显的更�E�疏，�q�样从硬盘�(sh��)��d��数据�Q�就需要更多的i/o操作�Q�通常�Q�我们在存储比较大的域的时候，��׃��(x��)考虑�q�样的事情，比如存储一��文章的文��。）(j��)

       可以考虑��比较大的域攑ֈ�solr外面来存储。如果你觉得�q�样做会(x��)有些别扭的话�Q�可以考虑使用压羃的域�Q�但是这样会(x��)加重cpu在存储和��d��域的时候的负担。不�q�这样却是可以较?y��u)��i/0的负担�?/p>
       如果�Q�你�q�不是��L��使用 stored fields 的话�Q�可以��用stored field的�g�q�加载，�q�样可以节省很多的性能�Q�尤其是使用compressed field 的时候�?/p>
Configuration Considerations

      mergeFactor

         �q�个是合�q�因子，�q�个参数大概军_��?ji��n)segment(索引�D?的数量�?/p>
         合�ƈ因子�q�个值告诉lucene�Q�在什么时候，要将几个segment合�ƈ成�ؓ(f��)一个segment, 合�ƈ因子��像是一个数字系�l�的基数一栗��?/p>
         比如��_(d��)��如果你将合�ƈ因子设成10�Q�那么每往索引中添�?000个文档的时候，��׃��(x��)创徏一个新的烦(ch��)引段。当�W?0个大��ؓ(f��)1000的烦(ch��)引段��d��q�来的时候，�q�十个烦(ch��)引段��׃��(x��)被合�q�成一个大��ؓ(f��)10�Q?00的烦(ch��)引段。当十个大小�?0�Q?00的烦(ch��)引段生成的时候，它们��׃��(x��)被合�q�成一个大��ؓ(f��)100�Q?00 的烦(ch��)引段。如此类推下厅R�?/p>
         �q�个值可以在 solrconfig.xml 中的 *mainIndex*中设�|�。（不用��indexDefaults中设�|�）(j��)

       mergeFactor Tradeoffs

         较高的合�q�因�?/p>
        �?x��)提高�?ch��)引速度
        较低频率的合�qӞ��?x��)导�?更多的烦(ch��)引文�Ӟ��q�会(x��)降低索引的搜索效�?/li>

          较低的合�q�因�?/p>
        较少数量的烦(ch��)引文�Ӟ��能加快烦(ch��)引的搜烦(ch��)速度�?/li>
        较高频率的合�qӞ��?x��)降低�?ch��)引的速度�?/li>

Cache autoWarm Count Considerations

      当一个新�?searcher 打开的时候，它缓存可以被预热�Q�或者说使用从旧的searcher的缓存的数据�?#8220;自动加热”。autowarmCount是这��L(f��ng)��一个参敎ͼ�它表�C�Z��旧缓存�(sh��)��拯��到新�~�存?sh��)��的对象数量。autowarmCount�q�个参数��会(x��)影响“自动预热”的时间。有些时候，我们需要一些折?sh��)��的考虑�Q�seacher启动的时间和�~�存加热的程度。当然啦�Q�缓存加热的�E�度��好�Q��用的旉��׃��(x��)��长�Q�但往往�Q�我们�ƈ不希望过长的seacher启动旉��。这个autowarm 参数可以在solrconfig.xml文�g中被讄��?/p>
       详细的配�|�可以参考solr的wiki�?/p>
Cache hit rate�Q�缓存命中率�Q?/h2>
       我们可以通过solr的admin界面来查看缓存的状态信息。提高solr�~�存的大��往往是提高性能的捷径。当你��用面搜烦(ch��)的时候，你或许可以注意一下filterCache,�q�个是由solr实现的缓存�?/p>


Explicit Warming of Sort Fields

       如果你有许多域是��Z��排序的，那么你可以在"newSearcher"�?firstSearcher"event listeners中添加一些明��N��要预热的查询�Q�这样FieldCache ��׃��(x��)�~�存�q�部分内宏V�?/p>
Optimization Considerations

        优化索引�Q�是我们�l�常�?x��)做的事情，比如�Q�当我们建立好烦(ch��)引，然后�q�个索引不会(x��)再变更的情况�Q�我们就�?x��)做一�ơ优化了(ji��n)�?/p>
        但，如果你的索引�l�常�?x��)改变，那么你就需要好好的考虑下面的因素的�?/p>
       当越来越多的索引�D�被加进索引�Q�查询的性能��׃��(x��)降低�Q?lucene对烦(ch��)引段的数量有一个上限的限制�Q�当��过�q�个限制的时候，索引�D�可以自动合�q�成��Z��个�?/li>
在同��h��有缓存的情况下，一个没有经�q�优化的索引的性能�?x��)比�l�过优化的烦(ch��)引的性能��?0%……
自动加热的时间将�?x��)变长，因��?f��)它依赖于搜烦(ch��)�?/li>
优化��会(x��)对烦(ch��)引的分发产生影响�?/li>
在优化期��_(d��)��文�g的大��将�?x��)是索引的两倍，不过最�l�将�?x��)回到它原来的大��，或者会(x��)更小一炏V�?/li>

      优化�Q�会(x��)��所有的索引�D�合�q�成��Z��个烦(ch��)引段�Q�所以，优化�q�个操作其实可以帮助避免“too many files”�q�个问题�Q�这个错误是由文件系�l�抛出的�?/p>
Updates and Commit Frequency Tradeoffs

         如果从机太经�总��L��更新的话�Q�从机的性能是会(x��)受到影响的。�ؓ(f��)�?ji��n)避免，�׃��q�个问题而引��L(f��ng)��性能下降�Q�我们还必须�?ji��n)解从机是怎样执行更新的，�q�样我们才能更准��去调节一些相关的参数�Q�commit的频率，spappullers,autowarming/autocount�Q?�q�样�Q�从机的更新才不�?x��)太频繁�?/p>
     执行commit操作�?x��)让solr新生成一个snapshot。如果将postCommit参数设成true的话�Q�optimization也会(x��)执行snapShot.
     slave上的Snappuller�E�序一般是在crontab上面执行的，它会(x��)去master询问�Q�有没有新版的snapshot。一旦发现新的版本，slave��׃��(x��)把它下蝲下来�Q�然后snapinstall.
     每次当一个新的searcher被open的时候，�?x��)有一个缓存预热的�q�程�Q�预热之后，新的索引才会(x��)交付?sh��)��用�?/li>

      �q�里讨论三个有关的参敎ͼ�(x��)

     number/frequency of snapshots ----snapshot的频率�?/li>
     snappullers �?/strong> 在crontab中的�Q�它当然可以每秒一�ơ、每天一�ơ、或者其他的旉��间隔一�ơ运行。它�q�行的时候，只会(x��)下蝲slave上没有的�Q��ƈ且最新的版本�?/li>
     Cache autowarming 可以在solrconfig.xml文�g中配�|��?/li>

           如果�Q�你惌��的效果是频繁的更新slave上的索引�Q�以便这��L(f��ng)��h��比较�?#8220;实时索引”。那么，你就需要让snapshot��可能频�J�的�q�行�Q�然后也�?snappuller频繁的运行。这��P��我们或许可以�?分钟更新一�ơ，�q�且�q�能取得不错的性能�Q�当然啦�Q�cach的命中率是很重要的，恩，�~�存的加热时间也��会(x��)影响到更新的频繁度�?/p>
       cache�Ҏ(gu��)��能是很重要的。一斚w��Q�新的缓存必��L��有��够的�~�存量，�q�样接下来的的查询才能够从缓存�(sh��)��受益。另一斚w��Q�缓存的预热��可能占用很长一�D�|��_(d��)��其是，它其实是只��用一个线�E�，和一个cpu在工作。snapinstaller太频�J�的话，solr slave��会(x��)处于一个不太理想的状态，可能它还在预热一个新的缓存，然而一个更新的searcher被opern�?ji��n)�?/p>
         怎么解决�q�样的一个问题呢�Q�我们可能会(x��)取消�W�一个seacher�Q�然后去处理一个更新seacher�Q�也��x(ch��ng)��W�二个。然而有可能�W�二个seacher �q�没有被使用上的时候，�W�三个又�q�来�?ji��n)。看吧，一个恶性的循环�Q�不是。当然也有可能，我们刚刚预热好的时候就开始新一轮的�~�存预热�Q�其实，�q�样�~�存的作用压根就没有能体现出来。出现这�U�情�늚�时候，降低snapshot的频率才是硬道理�?/p>
    Query Response Compression

        在有些情况下�Q�我们可以考虑��solr xml response 压羃后才输出。如果response非常大，��׃��(x��)触及(qi��ng)NIc i/o限制�?/p>
        当然压羃�q�个操作��会(x��)增加cpu的负担，其实�Q�solr一个典型的依赖于cpu处理速度的服务，增加�q�个压羃的操作，��无疑会(x��)降低查询性能。但是，压羃后的数据��会(x��)是压�~�前的数据的6分之一的大��。然而solr的查询性能也会(x��)�?5%左右的消耗�?/p>
       至于怎样配置�q�个功能�Q�要看你使用的什么服务器而定�Q�可以查阅相关的文��?/p>
     Embedded vs HTTP Post

         使用embeded 来徏立烦(ch��)引，��会(x��)比��用xml格式来徏立烦(ch��)引快50%�?/p>
     RAM Usage Considerations�Q�内存方面的考虑�Q?/h2>
        OutOfMemoryErrors

           如果你的solr实例没有被指定��够多的内存的话，java virtual machine也许�?x��)抛outof memoryError�Q�这个�ƈ不对索引数据产生影响。但是这个时候，��M��?adds/deletes/commits操作都是不能够成功的�?/p>
         Memory allocated to the Java VM

            最��单的解决�q�个�Ҏ(gu��)��是�Q�当然前提是java virtual machine �q�没有��用掉你全部的内存�Q�增加运行solr的java虚拟机的内存�?/p>
           Factors affecting memory usage�Q�媄(ji��ng)响内存�(sh��)��用量的因素）(j��)

             我想�Q�你或许也会(x��)考虑怎样��d��solr的内存�(sh��)��用量�?/p>
              其中的一个因素就是input document的大��?/p>
              当我们��用xml执行add操作的时候，��׃��(x��)有两个限制�?/p>
     document中的field都是�?x��)被存进内存的，field有个属性叫maxFieldLength�Q�它或许能帮上忙�?/li>
     每增加一个域�Q�也是会(x��)增加内存的��用的�?/li>

CONAN 2012-06-13 14:16 发表评论

Solr Cache使用介绍�?qi��ng)分�?�?

CONAN — Wed, 13 Jun 2012 06:12:00 GMT
本文��介�l�Solr查询中涉�?qi��ng)到的Cache使用�?qi��ng)相关的实现。Solr查询的核�?j��)类��是SolrIndexSearcher�Q?
每个core通常�?同一时刻只由当前的SolrIndexSearcher供上层的handler使用

�Q�当切换SolrIndexSearcher时可能会(x��)有两个同时提供服务）(j��)�Q�而Solr的各�U�Cache是依附于SolrIndexSearcher的，SolrIndexSearcher在则C(j��)ache 生，SolrIndexSearcher亡则C(j��)ache被清�I�close掉�?/p>
Solr中的应用Cache有filterCache�?queryResultCache、documentCache�{�，�q�些Cache都是SolrCache的实现类�Q?/p>
�q�且�?SolrIndexSearcher的成员变量，各自有着不同的逻辑和��命，下面分别予以介绍和分析�?/p>
1、SolrCache接口实现�c?/h2>
Solr提供�?ji��n)两�U�SolrCache接口实现�c�：(x��)solr.search.LRUCache和solr.search.FastLRUCache�?/p>
FastLRUCache�?.4版本中引入的�Q�其速度在普遍意义上要比LRUCache更fast些�?br />下面是对SolrCache接口主要�Ҏ(gu��)��的注释：(x��)

public interface SolrCache{publicObjectinit(Mapargs,Objectpersistence, CacheRegenerator regenerator);
publicintsize();
publicObjectput(Objectkey,Objectvalue);
publicObjectget(Objectkey);publicvoidclear();voidwarm(SolrIndexSearcher searcher, SolrCache old)throwsIOException;
publicvoidclose();}

1.1、solr.search.LRUCache
LRUCache可配�|�参数如下：(x��)

1�Q�size�Q�cache中可保存的最大的��Ҏ(gu��)��Q�默认是1024
2�Q�initialSize�Q�cache初始化时的大��，默认�?024�?br />3�Q�autowarmCount�Q?br />当切换SolrIndexSearcher�Ӟ��可以�Ҏ(gu��)��生成的SolrIndexSearcher做autowarm�Q�预热）(j��)处理�?br />autowarmCount表示从旧的SolrIndexSearcher中取多少��Ҏ(gu��)��在新的SolrIndexSearcher中被重新生成�Q?/p>
如何重新生成由CacheRegenerator实现。在当前�?.4版本的Solr中，�q�个autowarmCount只能取预热的��Ҏ(gu��)��Q?/p>
��来�?.0版本可以指定为已有cache��Ҏ(gu��)��的百分比�Q�以便能更好的��^衡autowarm的开销�?qi��ng)效果�?/p>
如果不指定该参数�Q�则表示不做autowarm处理。实��C��Q�LRUCache直接使用LinkedHashMap来缓存数据，

由initialSize来限定cache的大��，淘汰�{�略也是使用LinkedHashMap的内�|�的LRU方式�Q?/p>��d��操作都是对map的全局锁，所以�ƈ发性效果方面稍差�?
1.2、solr.search.FastLRUCache
在配�|�方面，FastLRUCache除了(ji��n)需要LRUCache的参敎ͼ��q�可有选择性的指定下面的参敎ͼ�(x��)

1�Q�minSize�Q�当cache辑ֈ�它的最大数�Q�淘汰策略��光��到minSize大小�Q�默认是0.9*size�?br />2�Q�acceptableSize�Q�当淘汰数据�Ӟ��期望能降到minSize�Q�但可能�?x��)做不到�Q�则可勉为其隄��降到acceptableSize�Q?/p>
默认�?.95*size�?/p>
3�Q�cleanupThread�Q�相比LRUCache是在put操作中同步进行淘汰工作，FastLRUCache可选择��q��立的�U�程来做�Q?/p>
也就是配�|�cleanupThread的时候。当cache大小很大�Ӟ��每一�ơ的淘汰数据��可能会(x��)��p��较长旉��Q?/p>
�q�对于提供查询请求的�U�程来说��׃��太合适，��q��立的后台�U�程来做��很有必要。实��C��Q?/p>
FastLRUCache内部使用�?ji��n)ConcurrentLRUCache来缓存数据，它是个加�?ji��n)LRU淘汰�{�略的ConcurrentHashMap�Q?/p>
所以其�q�发性要好很多，�q�也是多数Java版Cache的极典型实现�?/p>
2、filterCache
filterCache存储�?ji��n)无序的lucene document id集合�Q�该cache�?�U�用途：(x��)

1�Q�filterCache
存储�?ji��n)filter queries(“fq”参数)得到的document id集合�l�果。Solr中的query参数有两�U�，即q和fq。如果fq存在�Q?/p>
Solr是先查询fq�Q�因为fq可以多个�Q�所以多个fq查询是个取结果交�?的过�E�）(j��)�Q�之后将fq�l�果和q�l�果取�ƈ�?/p>
在这一�q�程中，filterCache��是key为单个fq�Q�类型�ؓ(f��)Query�Q�，value为documentid集合�Q�类型�ؓ(f��)DocSet�Q�的cache�?/p>
对于fq为range query来说�Q�filterCache表现出其有�h(hu��n)值的一面�?br />2�Q�filterCache
�q�可用于facet查询�Q�http://wiki.apache.org/solr/SolrFacetingOverview�Q�，facet查询中各
facet的计数是通过�Ҏ(gu��)��query条�g的document
id集合�Q�可涉及(qi��ng)到filterCache�Q�的处理得到的。因为统计各facet计数可能�?x��)涉及(qi��ng)到所有的doc
id�Q�所以filterCache的大��需要能容下索引的文��数�?br />3�Q�如果solfconfig.xml中配�|�了(ji��n)�Q?/p>
那么如果查询有filter�Q�此filter是一需要过滤的DocSet�Q�而不是fq�Q�我未见得它有什么用�Q�，
则��用filterCache�?br />
下面是filterCache的配�|�示例：(x��)

对于是否使用filterCache�?qi��ng)如何配�|�filterCache大小�Q�需要根据应用特炏V��统计、效果、经验等各方面来评估�?/p>
对于使用fq、facet的应用，对filterCache的调优是很有必要的�?/p>
3、queryResultCache
��֐�思义�Q�queryResultCache是对查询�l�果的缓存（SolrIndexSearcher中的cache�~�存的都是document id set�Q�，
�q�个�l�果��是针对查询条�g的完全有序的�l�果�?下面是它的配�|�示例：(x��)

�~�存的key是个什么结构呢�Q�就是下面的�c�（key的hashcode��是QueryResultKey的成员变量hc�Q�：(x��)
publicQueryResultKey(Query query, Listfilters, Sort sort,intnc_flags)
{
this.query=query;
this.sort=sort;
this.filters=filters;
this.nc_flags=nc_flags;
inth=query.hashCode();
if(filters!=null)h^=filters.hashCode();
sfields=(this.sort!=null)?this.sort.getSort():defaultSort;
for(SortField sf:sfields)
{ // mix the bits so that sortFields are position dependent
// so that a,b won't hash to the same value as b,ah^=(h<<8)|(h>>>25);
// reversible hashif(sf.getField()!=null)h+=sf.getField().hashCode();h+=sf.getType();
if(sf.getReverse())h=~h;if(sf.getLocale()!=null)h+=sf.getLocale().hashCode();
if(sf.getFactory()!=null)h+=sf.getFactory().hashCode();}hc=h;
}
因�ؓ(f��)查询参数是有start和rows的，所以某个QueryResultKey可能命中�?ji��n)cache�Q�但start和rows却不在cache�?br />document id set范围内。当�?d��ng)��document id
set是越大命中的概率��大�Q�但�q�也�?x��)很��费内存�Q�这��需要个参数�Q�queryResultWindowSize来指定document id
set的大��。Solr中默认取��gؓ(f��)50,可配�|�，W(xu��)IKI上的解释很深��单明�?ji��n)�?x��)

50
相比filterCache来说�Q�queryResultCache内存?sh��)��用上要更少一些，但它的效果如何就很难说�?br /> ��q��(ch��)引数据来��_(d��)��通常我们只是在烦(ch��)引上存储应用主键id�Q�再从数据库�{�数据源获取其他需要的字段�?br /> �q��得查询过�E�变成，首先通过solr得到document id set�Q�再由Solr得到应用id集合�Q?br /> 最后从外部数据源得到完成的查询�l�果。如果对查询�l�果正确性没有苛�ȝ��要求�Q�可以在Solr之外独立的缓存完整的

查询�l�果�Q�定时作废）(j��)�Q�这时queryResultCache��׃��是很有必要，否则可以考虑使用queryResultCache。当�?d��ng)��如果发现�?br /> queryResultCache生命周期内，query重合度很低，也不是很有必要开着它�?
4、documentCache
又顾名思义�Q�documentCache用来保存对的。如果��用documentCache�Q�就��可能开�?br />
些，臛_��要大�q?lt;max_results> *�Q�否则因为cache的淘汎ͼ�
一�ơ请求期间还需要重新获取document一�ơ。也要注意document中存储的字段的多��，避免大量的内存消耗�?br /> 下面是documentCache的配�|�示例：(x��)

5、User/Generic Caches
Solr支持自定义Cache�Q�只需要实现自定义的regenerator卛_��Q�下面是配置�C�Z��Q?lt;!-- Example of a generic cache. These caches may be accessed by namethrough SolrIndexSearcher.getCache(),

cacheLookup(), and cacheInsert().The purpose is to enable easy caching of user/application level data.
The regenerator argument should be specified as an implementationof solr.search.CacheRegenerator if
autowarming is desired.-->
6、The Lucene FieldCache
lucene中有相对低��别的FieldCache�Q�Solr�q�不对它做管理，所以，lucene的FieldCache�q�是由lucene的IndexSearcher来搞�?

7、autowarm
上面有提到autowarm�Q�autowarm触发的时机有两个�Q�一个是创徏�W�一个Searcher�Ӟ��firstSearcher�Q�，一个是创徏个新

Searcher�Q�newSearcher�Q�来代替当前的Searcher。在Searcher提供��h��服务前，Searcher中的各个Cache可以
做warm处理�Q�处理的地方通常是SolrCache的init�Ҏ(gu��)��Q�而不同cache的warm�{�略也不一栗��?br /> 1�Q�filterCache�Q�filterCache注册�?ji��n)下面的CacheRegenerator�Q�就是由旧的key查询索引得到新值put到新cache中。solrConfig.filterCacheConfig.setRegenerator(newCacheRegenerator(){publicbooleanregenerateItem

(SolrIndexSearcher newSearcher, SolrCache newCache, SolrCache oldCache,ObjectoldKey,ObjectoldVal)
throwsIOException{newSearcher.cacheDocSet((Query)oldKey,null,false);returntrue;}});
2�Q�queryResultCache�Q�queryResultCache的autowarm不在SolrCache的init�Q�也��是��_(d��)��不是去遍历已
有的queryResultCache中的query key执行查询�Q�，而是通过SolrEventListener接口的void
newSearcher(SolrIndexSearcher newSearcher, SolrIndexSearcher
currentSearcher)�Ҏ(gu��)��Q�来执行配置中特定的query查询�Q�达到显�C�的预热lucene FieldCache的效果�?br /> queryResultCache的配�|�示例如下：(x��)

anythingname desc price desc populartiy desc

anything
name desc, price desc, populartiy desc
anythingcategory
inStock:trueprice:[0 TO 100]
3�Q�documentCache�Q�因为新索引的document id和烦(ch��)引文��的对应关系发生变化�Q�所以documentCache没有warm的过�E�，
落得白茫茫一片真�q�净。尽��autowarm很好�Q�也要注意autowarm带来的开销�Q�这需要在实际中检验其warm的开销�Q?br /> 也要注意Searcher的切换频率，避免因�ؓ(f��)warm和切换媄(ji��ng)响Searcher提供正常的查询服务�?br />
8、参考文�?
http://wiki.apache.org/solr/SolrCaching

CONAN 2012-06-13 14:12 发表评论

solr 的客��L(f��ng)��调用solrj 建烦(ch��)�?分页查询

CONAN — Wed, 30 May 2012 07:05:00 GMT
     摘要: �?nbsp;solr 3.5 配置�?qi��ng)应�?一) 讲过一�?nbsp;solr 3.5的详�l�配�|�，本节我们讲利用solr 的客��L(f��ng)��调用solr的应用了(ji��n)�Q?一、利用SolrJ操作solr API 使用SolrJ操作Solr�?x��)比利用httpClient来操作Solr要简单。SolrJ是封装了(ji��n)httpClient�Ҏ(gu��)��Q�来操作solr的API的。SolrJ底层�q?..  阅读全文

CONAN 2012-05-30 15:05 发表评论

solr的facet查询

CONAN — Wed, 30 May 2012 06:52:00 GMT
solr��以��D��为目的的查询�l�果�U�Cؓ(f��)facet. 它�ƈ不会(x��)修改查询�l�果信息, 只是在查询结果上�Ҏ(gu��)��分类��d��?ji��n)count信息, 然后用户�Ҏ(gu��)��count信息做进一步的查询, 比如淘宝的查询列表中, 上面�?x��)表�C�Z��同的�cȝ��相关查询�l�果的数�?

比如搜烦(ch��)数码相机, 在搜索结果栏�?x��)根据厂�? 分��L率等�l�度列出, �q�里厂商, 分��L率就是一个个facet.

然后在厂商下面会(x��)有nikon, canon, sony�{�品�? �q�个叫约�?constraints)

接下来是�Ҏ(gu��)��选择, 列出当前的导航�\�? �q�个叫面包屑(breadcrumb).

solr有几�U�facet:
普通facet, 比如从厂商品牌的�l�度建立fact
查询facet, 比如�Ҏ(gu��)��h��查询�? ��根据�h(hu��n)�? 讄��多个区间, 比如0-10, 10-20, 20-30�{?
日期facet, 也是一�U�特�D�的范围查询, 比如按照月䆾�q�行facet.

facet的主要好处就是可以�Q意对搜烦(ch��)条�g�q�行�l�合, 避免无效搜烦(ch��), 改善搜烦(ch��)体验.

facet都是在查询时通过参数指定. 比如
在http api中这样写:
"&facet=true&facet.field=manu"
java代码�q�样写：(x��)
new SolrQuery("*:*").setFacet(true).addFacetField("manu");
而xml�q�回的结果�ؓ(f��)�q�样�Q?
<lst name="facet_fields">
            <lst name="manu">
               <int name="Canon USA">17int>
               <int name="Olympus">12int>
               <int name="Sony">12int>
               <int name="Panasonic">9int>
               <int name="Nikon">4int>
            lst>
lst>
通过java代码可以�q�样获取facet�l�果�Q?
List<FacetField> facetFields = queryResponse.getFacetFields();
在已有的查询基础上增加facet query,可以�q�样写：(x��)
solrQuery.addFacetQuery("quality:[* TO 10]")
比如对�h(hu��n)格按照指定的区间�q�行facet, 可以�q�样加上facet后缀:

&facet=true&facet.query=price:[* TO 100]
&facet.query=price:[100 TO 200];&facet.query=[price:200 TO 300]
&facet.query=price:[300 TO 400];&facet.query=[price:400 TO 500]
&facet.query=price:[500 TO *]

如果要对��h��?00�?00期间的��品做�q�一步的搜烦(ch��), 那么可以�q�样�?使用�?ji��n)solr的过滤查�?:

引用

http://localhost:8983/solr/select?q=camera &facet=on&facet.field=manu&facet.field=camera_type &fq=price:[400 to 500]

注意�q�里的facet field不再包含price�?

如果�q�里对类型做�q�一步的查询, 那么query语句可以�q�样�?

引用

http://localhost:8983/solr/select?q=camera &facet=on&facet.field=manu &fq=price:[400 to 500] &fq=camera_type:SLR

facet的��用场�?
1.�cȝ��D��
2.自动提示, 需要借助一个支持多值的tag field.
3.热门关键词排�? 也需要借助一个tag field

CONAN 2012-05-30 14:52 发表评论

新版SolrCloud概述

CONAN — Wed, 30 May 2012 06:47:00 GMT
在Lucene/Solr的SVN trunk中的SolrCloud已经可用, 在即��发布的4.0版本中将正式包含.

目前SolrCloud已经成熟, 可以支持分布式烦(ch��)引和分布式搜�? 下面是我们一个项目采用新的SolrCloud的部�|�结构图:

看�v来是否非常简�? 下面我们看看内部的一些实现细�?

SolrCloud功能和架�?/strong>
下面是SolrCloud一些不错的功能:

中心(j��)化集��配�|?
自动容灾
�q�实时搜�?
领导选�D
索引持久�?

另外SolrCloud也能被配�|�成:
分片(shard)索引
每个shard可以有一个或多个副本(replica)

多个shard和replica可以�l�成一个Collection(从图中可以看出就是一个SolrCloud), 多个Collection可以部��v��C��个SolrCloud集群. 而一个搜索请求可以同时搜索多个Collection. 其工作流�E�就像下图中那样.

SolrCloud Shard, Replica, Replication
��像上图那样, 一个新的doc��发送到一个SolrCloud集群中�Q何一个节�? doc能自动选择发送到哪一个Shard, 如果Shard有多个副�? doc�?x��)自动进行同�? 与原来的master/slave�l�构有所不同, 数据同步是实时的(原来则是定期扚w��同步).

集群配置
SolrCloud集群的所有的配置存储在ZooKeeper. 一旦一个SolrCloud节点启动, 该节点的配置信息��发送到ZooKeeper上存�?

Shard Replica除了(ji��n)作�ؓ(f��)容灾备䆾存在, 另外一个作用就是分散查询请�? 提高整个集群的查询能�?

索引处理
索引文��的更新在Shard和Replica之间是自动和实时�? 因�ؓ(f��)不存在master server, doc可以发送到��M��一个SolrCloud(也就是一个Collection), 然后由SolrCloud完成剩下的事�? �q�样��׃��再存在以前master/slave的单炚w��?

搜烦(ch��)方式
有三�U�不同的搜烦(ch��)方式:
在单个Solr实例上搜�?
在单个Collection上搜�?卛_��一个Collection的多个Shard上搜�?
在指定的Shard上搜�?
在多个Collection上搜�? �q�将最后merge的结果返�?

�q�维��理
除了(ji��n)原来的标准core admin, �q�增加了(ji��n)其他方式:
在一个Collection上创��Z��个Shard
新徏一个Collection
增加节点.

下一步计�?/strong>
http://wiki.apache.org/solr/NewSolrCloudDesign
有新的SolrCloud设计�Ҏ(gu��)��.

CONAN 2012-05-30 14:47 发表评论

CONAN — Wed, 30 May 2012 06:44:00 GMT
原文:http://java.dzone.com/articles/lucene-solr-year-2011-review

2011�q�已�l�过�? 在这里针�Ҏ(gu��)��q�lucene和solr领域发生的点�Ҏ(gu��)��滴进行一下回��? 也算是对lucene和solr的一个盘�?

lucene成�ؓ(f��)apache基金�?x��)项目已逑֍��q?实际上lucene存在的历史已��过10�q?, solr 作�ؓ(f��)apache基金��目也差不多度过�?ji��n)六个春�U? 而这两个��目的发展离不开Otis(http://twitter.com/otisg )的长期努�?

在这一�q�里, solr和lucene发生�?ji��n)非常显著的变�? 增加�?ji��n)大量新的功�? 而这个变化可以说��过以往��M��一�q?

其中最�Ȁ动�h�?j��)的功能莫过于近实时搜�?ch��)功能(Near Real-Time search http://search-lucene.com/?q=NRT )的实�? 卛_��文档的修改会(x��)立马出现在搜索结果中. 虽然NRT依然�q�在�l�箋(hu��)改进�? 但是很多用户已经开始��用该功能.

字段折叠(Field Collapsing http://wiki.apache.org/solr/FieldCollapsing ) 也是solr�C�֌�中长期以来期待的一个功�? �q�个功能已在今年实现. 现在solr和lucene用户可以��Z��字段和查询条件对�l�果集进行进行分�l? �q�实��C��(ji��n)对分�l�进行控�? 此外�q�可以基于分�l�进行facet�q�算(而以前只能基于文�?.

在这一�q? lucene也引入了(ji��n)faceting module(https://issues.apache.org/jira/browse/LUCENE-3079 ), 从此以后, facet��不再是solr的专�? lucene用户可以�q�行facet�q�算�?

从今�q�开�? 你可以通过使用Join module(http://wiki.apache.org/solr/Join ) 对父子关联的文��建烦(ch��)�? �q�样我们可以在查询的�q�程中根据文档烦(ch��)引将父子文��q�行�q�接.

2011�q? 在多语言支持斚w��(http://wiki.apache.org/solr/LanguageAnalysis#Stemming ) ,solr和lucene也取得了(ji��n)重大�H�破: 加入�?ji��n)KStemFilter English stemmer(http://wiki.apache.org/solr/LanguageAnalysis#Notes_about_solr.KStemFilterFactory ) , 提供�?ji��n)对Unicode 4完整的支�? 增加�?ji��n)对中文和日文的支�? 增加�?ji��n)一个新的stemmer保护机制. 降低�?ji��n)synonym filter对内存的消�? 其中最大的一个增强是集成�?ji��n)Hunspell(http://wiki.apache.org/solr/LanguageAnalysis#Notes_about_solr.HunspellStemFilterFactory ), �q�样可以使用OpenOffice所支持的语�a��q�行stemming处理.

lucene 3.5.0的发�? 大幅度的降低�?ji��n)term词典的内存消�?在对term词典处理�? 比以前减��了(ji��n)3~5�?.

以前在��用lucene的时�? 如果对大数据量的搜烦(ch��)�l�果�q�行分页处理, 从头��d��会(x��)出现问题. 而在lucene 3.5.0�q�个版本, 通过引入searchAfter�Ҏ(gu��)��q�行�?ji��n)彻底的解�?

在这一�q? lucene和solr提供�?ji��n)一个新�? 更高�? 更可靠的��Z��Term Vector的高?sh��)��功�?

在这一�q? solr集成�?ji��n)扩展的Dismax查询解析�?http://search-lucene.com/?q=Extended+Dismax ), �q�一步提高�(sh��)��(ji��n)搜烦(ch��)�l�果的质�?

�q�一�q? 你可以��用函�?http://wiki.apache.org/solr/FunctionQuery#Sort_By_Function )�Ҏ(gu��)��索结果进行排�?比如�Ҏ(gu��)��某个值到指定点的距离�q�行排序), �q�且提供�?ji��n)一个新的根据空间搜索过滤器.

solr也提供了(ji��n)一个新�? ��Z��FST机器�?可以显著的降低内存消�?的suggest (http://wiki.apache.org/solr/Suggester )/自动完成搜烦(ch��)功能, 如果你对�q�个功能感兴��? 可以��x(ch��ng)��一下Sematext (http://sematext.com/products/autocomplete/index.html )提供的自动完成搜索功�?

�q�里�q�需要提到的��是solr卛_��提供的新的事务日�?transaction log https://issues.apache.org/jira/browse/SOLR-2700 )支持, 该支持将实现实时�q�回(real-time get https://issues.apache.org/jira/browse/SOLR-2656 )的功�? 卛_��d��一个文��之后你能立��x(ch��ng)��据id�q�回该文�? 事务日志也将用于SolrCloud分布式节点的恢复.

说到SolrCloud(http://wiki.apache.org/solr/SolrCloud ) �q�里(http://blog.sematext.com/2011/09/14/solr-digest-spring-summer-2011-part-2-solr-cloud-and-near-real-time-search/ )�q�有一��介�l? 对于SolrCloud, 用一句话来概�? ��是�q�用最新的设计原则�q�借助其他软�g模块(比如zookeeper)更快速的搭徏一套更强大solr分布式集��? 其核�?j��)思想��是拒绝单点故障, 采用中心(j��)化的集群和配�|�管�? 打破原有的master-slave架构, 做到容灾自动切换和动态调�?

2010�q�将两个��目的开发进行整合之�? �q�两个项目的发展非常�q�猛. �?011�q? lucene和solr在众多committer们的大力支持下发布了(ji��n)5个版�? 三月, lucene和solr 3.1版本发布, 3个月后的6�?�? 3.2版本发布. 一个月之后, 7�?�? lucene和solr 3.3版本发布. 9�?4�? 3.4版本发布, 11�? 3.5.0版本��利发布.

�?011�q? lucene和solr相关的会(x��)议也不少, 首先��d��是是5月䆾在旧金山举行的Lucene Revolution, otis在大�?x��)上做�?ji��n)题�(sh��)ؓ(f��)"Search Analytics: What? Why? How?"(http://java.dzone.com/articles/lucene-solr-year-2011-review )的演�? 其他�q�货猛击�q�里 (http://lucenerevolution.com/2011/agenda ) . 在六月䆾的Buzzwords大会(x��)�? otis在大�?x��)上做�?ji��n)"Search Analytics: What? Why? How?"的升�U�版演讲. 相关资料可参考官方网�? http://berlinbuzzwords.de . 10月䆾, 在巴塞罗那�D行了(ji��n)专门针对lucene和solr�?Lucene Eurocon 2011 大会(x��). Otis 在大�?x��)上做�?ji��n)主题?sh��)?Search Analytics: Business Value & BigData NoSQL Backend"(http://www.lucidimagination.com/sites/default/files/file/Eurocon2011/otis_gospodnetic_search_analytics_lucene_eurocon_2011.ppt )的主题演�? 而Rafał(http://twitter.com//kucrafal )在大�?x��)上做�?ji��n)"Explaining & Visualizing Solr 'explain' information"(http://www.lucidimagination.com/sites/default/files/file/Eurocon2011/Understanding%20and%20Visualizing%20Solr%20Explain%20information%20-%20Solr.pl%20-%20version%202.pdf )的演�?

�?011�q? lucene和solr又迎来了(ji��n)一�Ҏ(gu��)��的志同道合�?
•Andi Vajda
•Chris Male
•Dawid Weiss
•Erick Erickson
•Jan Høydahl
•Martin van Groningen
•Stanisław Osiński

对于一个成功的开源项�? 相关的图书对使用者也是必不可��? 虽然今年Lucene in Action没有推出新的版本, 但是Rafał Kuć在今�q?月给我们带来�?ji��n)它的新�?Solr 3.1 Cookbook". 在该书中, ��决solr的一些常见问�? Rafał�l�出�?ji��n)他的答�? 而David Smiley �?Eric Pugh在今�q�十一月推��Z��(ji��n)"Apache Solr 3 Enterprise Search Server"的新版本.

至于2012�q? lucene和solr�?x��)带来什么新的惊�? 让我们拭目以�?

CONAN 2012-05-30 14:44 发表评论

使用SolrJ生成索引

CONAN — Wed, 30 May 2012 06:43:00 GMT
代码很简�? 直接看就明白�? 可以在实际工作中借鉴, 原文�?a target="_blank">�q�里. �q�个例子使用两种方式来演�C�如何生成全量烦(ch��)�?
一个是从db中通过sql生成全量索引
一个是通过tika解析文�g生成全量索引
package SolrJExample;

import org.apache.solr.client.solrj.SolrServerException;
import org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer;
import org.apache.solr.client.solrj.impl.XMLResponseParser;
import org.apache.solr.client.solrj.response.UpdateResponse;
import org.apache.solr.common.SolrInputDocument;
import org.apache.tika.metadata.Metadata;
import org.apache.tika.parser.AutoDetectParser;
import org.apache.tika.parser.ParseContext;
import org.apache.tika.sax.BodyContentHandler;
import org.xml.sax.ContentHandler;

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.sql.*;
import java.util.ArrayList;
import java.util.Collection;

/* Example class showing the skeleton of using Tika and
   Sql on the client to index documents from
   both structured documents and a SQL database.

   NOTE: The SQL example and the Tika example are entirely orthogonal.
   Both are included here to make a
   more interesting example, but you can omit either of them.

*/
public class SqlTikaExample {
  private StreamingUpdateSolrServer _server;
  private long _start = System.currentTimeMillis();
  private AutoDetectParser _autoParser;
  private int _totalTika = 0;
  private int _totalSql = 0;

  private Collection _docs = new ArrayList();

  public static void main(String[] args) {
    try {
      SqlTikaExample idxer = new SqlTikaExample("http://localhost:8983/solr");

      idxer.doTikaDocuments(new File("/Users/Erick/testdocs"));
      idxer.doSqlDocuments();

      idxer.endIndexing();
    } catch (Exception e) {
      e.printStackTrace();
    }
  }

  private SqlTikaExample(String url) throws IOException, SolrServerException {
      // Create a multi-threaded communications channel to the Solr server.
      // Could be CommonsHttpSolrServer as well.
      //
    _server = new StreamingUpdateSolrServer(url, 10, 4);

    _server.setSoTimeout(1000);  // socket read timeout
    _server.setConnectionTimeout(1000);
    _server.setMaxRetries(1); // defaults to 0.  > 1 not recommended.
         // binary parser is used by default for responses
    _server.setParser(new XMLResponseParser());

      // One of the ways Tika can be used to attempt to parse arbitrary files.
    _autoParser = new AutoDetectParser();
  }

    // Just a convenient place to wrap things up.
  private void endIndexing() throws IOException, SolrServerException {
    if (_docs.size() > 0) { // Are there any documents left over?
      _server.add(_docs, 300000); // Commit within 5 minutes
    }
    _server.commit(); // Only needs to be done at the end,
                      // commitWithin should do the rest.
                      // Could even be omitted
                      // assuming commitWithin was specified.
    long endTime = System.currentTimeMillis();
    log("Total Time Taken: " + (endTime - _start) +
         " milliseconds to index " + _totalSql +
        " SQL rows and " + _totalTika + " documents");
  }

  // I hate writing System.out.println() everyplace,
  // besides this gives a central place to convert to true logging
  // in a production system.
  private static void log(String msg) {
    System.out.println(msg);
  }

  /**
   * ***************************Tika processing here
   */
  // Recursively traverse the filesystem, parsing everything found.
  private void doTikaDocuments(File root) throws IOException, SolrServerException {

    // Simple loop for recursively indexing all the files
    // in the root directory passed in.
    for (File file : root.listFiles()) {
      if (file.isDirectory()) {
        doTikaDocuments(file);
        continue;
      }
        // Get ready to parse the file.
      ContentHandler textHandler = new BodyContentHandler();
      Metadata metadata = new Metadata();
      ParseContext context = new ParseContext();

      InputStream input = new FileInputStream(file);

        // Try parsing the file. Note we haven't checked at all to
        // see whether this file is a good candidate.
      try {
        _autoParser.parse(input, textHandler, metadata, context);
      } catch (Exception e) {
          // Needs better logging of what went wrong in order to
          // track down "bad" documents.
        log(String.format("File %s failed", file.getCanonicalPath()));
        e.printStackTrace();
        continue;
      }
      // Just to show how much meta-data and what form it's in.
      dumpMetadata(file.getCanonicalPath(), metadata);

      // Index just a couple of the meta-data fields.
      SolrInputDocument doc = new SolrInputDocument();

      doc.addField("id", file.getCanonicalPath());

      // Crude way to get known meta-data fields.
      // Also possible to write a simple loop to examine all the
      // metadata returned and selectively index it and/or
      // just get a list of them.
      // One can also use the LucidWorks field mapping to
      // accomplish much the same thing.
      String author = metadata.get("Author");

      if (author != null) {
        doc.addField("author", author);
      }

      doc.addField("text", textHandler.toString());

      _docs.add(doc);
      ++_totalTika;

      // Completely arbitrary, just batch up more than one document
      // for throughput!
      if (_docs.size() >= 1000) {
          // Commit within 5 minutes.
        UpdateResponse resp = _server.add(_docs, 300000);
        if (resp.getStatus() != 0) {
          log("Some horrible error has occurred, status is: " +
                  resp.getStatus());
        }
        _docs.clear();
      }
    }
  }

    // Just to show all the metadata that's available.
  private void dumpMetadata(String fileName, Metadata metadata) {
    log("Dumping metadata for file: " + fileName);
    for (String name : metadata.names()) {
      log(name + ":" + metadata.get(name));
    }
    log("\n\n");
  }

  /**
   * ***************************SQL processing here
   */
  private void doSqlDocuments() throws SQLException {
    Connection con = null;
    try {
      Class.forName("com.mysql.jdbc.Driver").newInstance();
      log("Driver Loaded");

      con = DriverManager.getConnection("jdbc:mysql://192.168.1.103:3306/test?"
                + "user=testuser&password=test123");

      Statement st = con.createStatement();
      ResultSet rs = st.executeQuery("select id,title,text from test");

      while (rs.next()) {
        // DO NOT move this outside the while loop
        // or be sure to call doc.clear()
        SolrInputDocument doc = new SolrInputDocument(); 
        String id = rs.getString("id");
        String title = rs.getString("title");
        String text = rs.getString("text");

        doc.addField("id", id);
        doc.addField("title", title);
        doc.addField("text", text);

        _docs.add(doc);
        ++_totalSql;

        // Completely arbitrary, just batch up more than one
        // document for throughput!
        if (_docs.size() > 1000) {
             // Commit within 5 minutes.
          UpdateResponse resp = _server.add(_docs, 300000);
          if (resp.getStatus() != 0) {
            log("Some horrible error has occurred, status is: " +
                  resp.getStatus());
          }
          _docs.clear();
        }
      }
    } catch (Exception ex) {
      ex.printStackTrace();
    } finally {
      if (con != null) {
        con.close();
      }
    }
  }
}

CONAN 2012-05-30 14:43 发表评论

CONAN — Wed, 30 May 2012 06:40:00 GMT

转自�Q?a >http://rdc.taobao.com/team/jm/archives/1753
共整理三部分�Q�第一部分Solr常规处理�Q�第二部分针�Ҏ(gu��)��性处理，前者比较通用�Q�后者有局限性。务必根据具体应用特性，具体调节参数�Q�对比性能。第三部�?br />solr查询相关�?

具体应用需要全面去把控�Q�各个因素一赯��v作用�?/p>
�W�一部分
E文连�?http://wiki.apache.org/solr/SolrPerformanceFactors

Schema Design Considerations

indexed fields

   indexed fields 的数量将�?x��)�?ji��ng)响以下的一些性能�Q?/p>
索引�D늚�合�ƈ旉��
索引的大��?/span>

    我们可以通过��?span lang="EN-US">omitNorms=“true”来减��?span lang="EN-US">indexed fields数量增加所带来的媄(ji��ng)响�?/p>
stored fields

    Retrieving the stored fields ��实是一�U�开销。这个开销�Q�受每个文档所存储的字节媄(ji��ng)响很大�?strong>每个文��的所占用的空间越大，文��显的更�E��?/strong>�Q�这样从��盘?sh��)��读取数据，��需要更多的i/o操作�Q�通常�Q�我们在存储比较大的域的时候，��׃��(x��)考虑�q�样的事情，比如存储一��文章的文��。）(j��)

    可以考虑��比较大的域攑ֈ�solr外面来存储。如果你觉得�q�样做会(x��)有些别扭的话�Q�可以考虑使用压羃的域�Q�但是这样会(x��)加重cpu在存储和��d��域的时候的负担。不�q�这样却是可以较?y��u)?span lang="EN-US">i/0的负担�?/p>
    如果�Q�你�q�不是��L��使用stored fields的话�Q�可以��?span lang="EN-US">stored field的�g�q�加载，�q�样�?strong>以节省很多的性能�Q�尤其是使用compressed field 的时候�?/p>
Configuration Considerations

mergeFactor

    �q�个是合�q�因子，�q�个参数大概军_��?span lang="EN-US">segment(索引�D?span lang="EN-US">)的数量�?/p>
    合�ƈ因子�q�个值告�?span lang="EN-US">lucene�Q�在什么时候，要将几个segment合�ƈ成�ؓ(f��)一�?span lang="EN-US">segment, 合�ƈ因子��像是一个数字系�l�的基数一栗��?/p>
    比如��_(d��)��如果你将合�ƈ因子设成10�Q�那么每往索引中添�?span lang="EN-US">1000个文档的时候，��׃��(x��)创徏一个新的烦(ch��)引段。当�W?span lang="EN-US">10个大��ؓ(f��)1000的烦(ch��)引段��d��q�来的时候，�q�十个烦(ch��)引段��׃��(x��)被合�q�成一个大��ؓ(f��)10�Q?span lang="EN-US">000的烦(ch��)引段。当十个大小�?span lang="EN-US">10�Q?span lang="EN-US">000的烦(ch��)引段生成的时候，它们��׃��(x��)被合�q�成一个大��ؓ(f��)100�Q?span lang="EN-US">000的烦(ch��)引段。如此类推下厅R�?/p>

�q�个值可以在solrconfig.xml 中的
*mainIndex*中设�|�。（不用��?span lang="EN-US">indexDefaults中设�|�）(j��)

mergeFactor Tradeoffs

  较高的合�q�因�?/p>
      较低的合�q�因�?/p>
    HashDocSet Max Size Considerations
  hashDocSet�?/span>solrconfig.xml中自定义优化选项,
使用�?/span>filters(docSets)
中，更小�?/span>sets�Q�表明更��的内存消耗、遍历、插入�?/span>


hashDocSet参数值最后基于烦(ch��)引文��L��来定�Q�烦(ch��)引集合越大，hashDocSet��g��大�?/span>

Calulate 0.005 of the total number of documents that you are going to store. Try values on either ‘side’ of that value to arrive at the best query times. �?When query times seem to plateau, and performance doesn’t show much difference between the higher number and the lower, use the higher.

Note: hashDocSet is no longer part of Solr as of version 1.4.0, see SOLR-1169.

Cache autoWarm Count Considerations

    当一个新�?span lang="EN-US">searcher 打开的时候，它缓存可以被预热�Q�或者说使用从旧�?span lang="EN-US">searcher的缓存的数据�?span lang="EN-US">“自动加热”�?span lang="EN-US">autowarmCount是这��L(f��ng)��一个参敎ͼ�它表�C�Z��旧缓存�(sh��)��拯��到新�~�存?sh��)��的对象数量�?span lang="EN-US">autowarmCount�q�个参数��会(x��)影响“自动预热”的时�?/strong>。有些时候，我们需要一些折?sh��)��的考虑�Q?span lang="EN-US">seacher启动的时间和�~�存加热的程度。当然啦�Q�缓存加热的�E�度��好�Q��用的旉��׃��(x��)��长�Q�但往往�Q�我们�ƈ不希望过长的seacher启动旉��。这�?span lang="EN-US">autowarm 参数可以�?span lang="EN-US">solrconfig.xml文�g中被讄��?/p>
   详细的配�|�可以参�?span lang="EN-US">solr�?span lang="EN-US">wiki�?/p>
Cache hit rate�Q�缓存命中率�Q?/h2>
    我们可以通过solr�?span lang="EN-US">admin界面来查看缓存的状态信息�?strong>提高solr�~�存的大��往往是提高性能的捷�?/strong>。当你��?strong>面搜索的时�?/strong>�Q�你或许可以注意一�?span lang="EN-US">filterCache,�q�个是由solr实现的缓存�?/p>

详细的内容可以参�?span lang="EN-US">solrCaching�q�篇wiki�?/p>
Explicit Warming of Sort Fields

      如果你有许多域是��Z��排序的，那么你可以在“newSearcher”�?span lang="EN-US">“firstSearcher”event
listeners中添加一些明��N��要预热的查询�Q�这�?strong>FieldCache ��׃��(x��)�~�存�q�部分内�?/strong>�?/p>
Optimization Considerations

    优化索引�Q�是我们�l�常�?x��)做的事情，比如�Q�当我们建立好烦(ch��)引，然后�q�个索引不会(x��)再变更的情况�Q�我们就�?x��)做一�ơ优化了(ji��n)�?/p>
    但，如果你的索引�l�常�?x��)改变，那么你就需要好好的考虑下面的因素的�?/p>
lucene在同��h��有缓存的情况下，一个没有经�q�优化的索引的性能�?x��)比�l�过优化的烦(ch��)引的性能��?/span>10%……
�?/span>
     优化�Q�会(x��)��所有的索引�D�合�q�成��Z��个烦(ch��)引段�Q�所以，优化�q�个操作其实可以帮助避免“too many files”�q�个问题�Q�这个错误是由文件系�l�抛出的�?/p>
Updates and Commit Frequency Tradeoffs


如果从机 �l�常�?��L��更新的话�Q�从机的性能是会(x��)受到影响的。�ؓ(f��)�?ji��n)避免，�׃��q�个问题而引��L(f��ng)��性能下降�Q�我们还必须�?ji��n)解从机是怎样执行更新的，�q�样我们才能更准��去调节一些相关的参数�Q?span lang="EN-US">commit的频率，spappullers, autowarming/autocount�Q?span lang="EN-US">,�q�样�Q�从机的更新才不�?x��)太频繁�?/p>
commitsolrsnapshotpostCommittrueoptimizationsnapShot.
slaveSnappullercrontabmastersnapshotslavesnapinstall.
searcheropen   �q�里讨论三个有关的参敎ͼ�(x��)

number/frequency of snapshots —-snapshotsnappullers �?/span> crontabslaveCache autowarming solrconfig.xml     如果�Q�你惌��的效果是频繁的更�?span lang="EN-US">slave上的索引�Q�以便这��L(f��ng)��h��比较�?span lang="EN-US">“实时索引”。那么，你就需要让snapshot��可能频�J�的�q�行�Q�然后也�?span lang="EN-US">snappuller频繁的运行。这��P��我们或许可以�?span lang="EN-US">5分钟更新一�ơ，�q�且�q�能取得不错的性能�Q�当然啦�Q?span lang="EN-US">cach的命中率是很重要的，恩，�~�存的加热时间也��会(x��)影响到更新的频繁度�?/p>
    cache�Ҏ(gu��)��能是很重要�?/span>。一斚w��Q�新的缓存必��L��有��够的�~�存量，�q�样接下来的的查询才能够从缓存�(sh��)��受益。另一斚w��Q�缓存的预热��可能占用很长一�D�|��_(d��)��其是，它其实是只��用一个线�E�，和一�?span lang="EN-US">cpu在工作�?span lang="EN-US">snapinstaller太频�J�的话，solr
slave��会(x��)处于一个不太理想的状态，可能它还在预热一个新的缓存，然而一个更新的searcher�?span lang="EN-US">opern�?ji��n)�?/p>
    怎么解决�q�样的一个问题呢�Q�我们可能会(x��)取消�W�一�?span lang="EN-US">seacher�Q�然后去处理一个更�?span lang="EN-US">seacher�Q�也��x(ch��ng)��W�二个。然而有可能�W�二�?span lang="EN-US">seacher �q�没有被使用上的时候，�W�三个又�q�来�?ji��n)。看吧，一个恶性的循环�Q�不是。当然也有可能，我们刚刚预热好的时候就开始新一轮的�~�存预热�Q�其实，�q�样�~�存的作用压根就没有能体现出来。出现这�U�情�늚�时候，降低snapshot的频率才是硬道理�?/p>
Query Response Compression

    在有些情况下�Q�我们可以考虑��?span lang="EN-US">solr xml response 压羃后才输出。如�?span lang="EN-US">response非常大，��׃��(x��)触及(qi��ng)NIc i/o限制�?/p>
    当然压羃�q�个操作��会(x��)增加cpu的负担，其实�Q?span lang="EN-US">solr一个典型的依赖�?span lang="EN-US">cpu处理速度的服务，增加�q�个压羃的操作，��无疑会(x��)降低查询性能。但是，压羃后的数据��会(x��)是压�~�前的数据的6分之一的大��?/strong>。然�?span lang="EN-US">solr的查询性能也会(x��)�?span lang="EN-US">15%左右的消耗�?/p>
  至于怎样配置�q�个功能�Q�要看你使用的什么服务器而定�Q�可以查阅相关的文��?/p>
Embedded vs HTTP Post

使用embeded 来徏立烦(ch��)引，��会(x��)比��?span lang="EN-US">xml格式来徏立烦(ch��)引快50%�?/p>
RAM Usage Considerations�Q�内存方面的考虑�Q?/h2>
OutOfMemoryErrors

    如果你的solr实例没有被指定��够多的内存的话，java virtual machine也许�?x��)�?span lang="EN-US">outof memoryError�Q�这�?strong>�q�不对烦(ch��)引数据��生媄(ji��ng)�?/strong>。但是这个时候，��M��?span lang="EN-US">adds/deletes/commits操作都是不能够成功的�?/p>
Memory allocated to the Java VM

    最��单的解决�q�个�Ҏ(gu��)��是�Q�当然前提是java virtual machine�q�没有��用掉你全部的内存�Q�增加运�?span lang="EN-US">solr�?span lang="EN-US">java虚拟机的内存�?/p>
Factors affecting memory usage我想�Q�你或许也会(x��)考虑怎样��d��?span lang="EN-US">solr的内存�(sh��)��用量。其中的一个因素就�?span lang="EN-US">input document的大��。当我们使用xml执行add操作的时候，��׃��(x��)有两个限制�?/p>
documentfieldfieldmaxFieldLength每增加一个域�Q�也是会(x��)增加内存的��用的�?/span>

�W�二部分

1. 多core的时�?/p>
多core 如果同一旉��q�行core 切换�Q�会(x��)��D��内存、cpu压力�q�大�Q�可以扩展Solr代码�Q�限制最多同时core
切换的执行个数。保证不�?x��)出现高load或者高cpu 风险

2�Q�应用较高安�?/p>
最后不低于2个结点工作，�q�且最�?个结�Ҏ(gu��)��跨机器的�?br />offline与online切换的时候，如果数据量不是很多，可以考虑index与search合一�Q�如果数据量较大�Q�超�q?000w的时候，��index
offline或者search�l�点之外的其他结点上执行index

3.cache参数配置

如果更新很频�J�，��D��commit和reopen频繁�Q�如果可以的话，关闭cache.
如果讉K��中依赖cache提示性能�Q�那么最好关闭cache warm�Q�no facet 需�?br />或者开开启cache warm 有facet需要，对fieldvalue cache很依赖的话�?br />实时更新的话�Q�通常document cache命中率比较低�Q�完全可以不开启这个配�|?/p>
4.reopen 和commit

如果可以的话�Q�主��盘索引�Q�不参入segment合�ƈ�Q�新的烦(ch��)引段��C��同的目录。�ƈ且reopen的时候，�ȝ��(ch��)引的不变动�?/p>
commit与reopen异步�?/p>
5.有一部分数据如果不变动，可以考虑使用memory cache 或者locale cache �q��性能和空间开销�Q�同旉��免FGC

6.中间变量压羃、单例化

所有查询或者徏索引�q�程中，��量��创建对象，而通过set改变对象��|��以及(qi��ng)单例化，提升性能。一些较大中间变量，如果可以的话�Q�采取一些整数压�~?/p>
7.对象表示重定�?br />例如日期、地区、url、byte�{�一些对象，可以考虑差倹{��区位码、可别部分、压�~�等�l�构�Q��得内存开销降低间接使得内存?sh��)��用率提高，获得更好性能�?/p>
8.index与store 隔离
��是index发挥它的查询性能�Q�store发挥它的存储、响应性能�?br />也就是不要将所有的内容都放在index中，��量使得field的属性stored=false

9. 使用solr、lucene最新版�?/p>
10. �׃�n分词实例
自定义的分词�Q�务必��用单例。千万不要一个document创徏一个分词对�?/p>
�W�三部分 Solr查询

1. �Ҏ(gu��)��指定域排�?br />展示的时候，对于数字的徏议，展示最�q?或�?个月数据。例如�h(hu��n)��|��防止作弊
dump或者徏索引的时候，�Ҏ(gu��)��字加以上下界��(g��)��，�?qi��ng)早发现数字本��n正确�Q�而实际意义不合理的数�?/p>
2. 排序可变�?br />默认的排序务必有自己的相兛_��敎ͼ��q�且�q��各方面需求�?br />排序要变�Q�但是不至于大的波动。排序的�l�节不公开�Q�但是排序的�l�果可以解释的清楚�?/p>
3.�U�上�U�下
有些分值可以线下完成，有些分值线上完成。看需求�?/p>
4.多域查询
如果默认查询多个域，不妨��多个域合成一个域�Q�只差一个域

5.高�(sh��)��
高�(sh��)��可以在solr里面或者外面执行的�Q�不一定在solr里面执行�Q�可以在solr之外执行
同理�Q�分词可以在�U�下执行好，dump只执行简单的�I�格分词卛_��

6.�l�计
facet�l�计可以先上与线下相�l�合�Q�不一定完全依赖线上即时计数�?/p>
7.��d��搜烦(ch��)
��d��搜烦(ch��)查询串务必严格处理，既要��L��效查询串�Q�也要适当扩展查询丌Ӏ?br />明确查询路径和hit=0的对应处理�?/p>

CONAN 2012-05-30 14:40 发表评论

solr学习(f��n)�W�记-linux下配�|�solr(�?

CONAN — Wed, 30 May 2012 06:38:00 GMT

本文地址�Q?/span>

http://zhoujianghai.iteye.com/blog/1540176

首先介绍一下solr�Q?/span>

Apache Solr (读音: SOLer) 是一个开源�?/span>高性能、采用Java开发�?/span>��Z��Lucene的全文搜索服务器�Q?/span>文��通过Http利用XML加到一个搜索集合中�Q�查询该集合也是通过 http收到一个XML/JSON响应来实现�?/span>Solr 中存储的资源是以 Document 为对象进行存储的。每个文��由一�p�d��?Field 构成�Q�每�?Field 表示资源的一个属性。Solr 中的每个 Document 需要有能唯一标识其自�w�的属性，默认情况下这个属性的名字�?id�Q�在 Schema 配置文�g�Q�schema.xml�Q�中使用�Q?code style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px">id�q�行描述。solr有两个核�?j��)文�Ӟ��solrconfig.xml和schema.xml�?/span>solrconfig.xml是solr的基��文�g�Q�里面配�|�了(ji��n)各种web��h��处理器、请求响应处理器、日志、缓存等;schema.xml配置映射�?ji��n)各�U�数据类型的索引�Ҏ(gu��)��Q�分词器的配�|�、烦(ch��)引文��中包含的字�D�也在此配置�?/span>

工作中主要用来分词和搜烦(ch��)�Q�简单的工作原理是：(x��)利用分词器对数据源进行分词处理，然后�Ҏ(gu��)��分词�l�果建立索引�?查询的时候，利用分词器对查询语句�q�行分词�Q�根据查询语句分词的�l�果在烦(ch��)引库中进行匹配，最后返回结果�?/span>

废话��说�Q�下面开始solr之旅吧：(x��)

一.安装JDK和Tomcat

�Q?�Q�：(x��)安装jdk 下蝲jdk安装包，解压到jdk-1.x目录

�Q?�Q�：(x��)安装tomcat�Q�下载tomcat安装包，解压到apache-tomcat目录�?/span>

修改tomcat安装目录下的conf目录的server.xml

扑ֈ��Q�加�?span style="line-height: 18px">URIEncoding="UTF-8"�Q��ؓ(f��)�?/span>支持中文�?/span>

讄��Java和tomcat环境变量

上面两步比较��单，�q�里��只��单描�q�C��下，不明白的可以�|�上查资料�?/span>

�? 安装solr

下蝲solr包，http://labs.renren.com/apache-mirror/lucene/solr/3.5.0/apache-solr-3.5.0.zip

解压�~�到apache-solr目录�Q�把apache-solr/dist目录下的apache-solr-3.5.0.war 复制�?TOMCAT_HOME/webapps目录下，重命名�ؓ(f��)solr.war

复制apache-solr/example/solr到tomcat根目录下�Q�如果你想配�|�多core�Q�实例）(j��)�Q�就复制apache-solr /example/multicore到tomcat根目录下�Q�不用复制solr�?ji��n)�?j��)�Q�作为solr/home�Q�以后也可以往该目录添�?core�Q�每个core下面都可以有自己的配�|�文件�?/span>

在apache-tomcat/conf/Catalina/localhost/下创建solr.xml�Q�跟webapps下的solr��目同名�Q�，指定solr.war和solr/home的位�|�，让tomcat启动时就自动加蝲该应用�?/span>

solr.xml内容如下�Q?/span>

然后在tomcat的bin目录下执�?/startup.sh�Q�启动tomcat

在地址栏访问http://localhost:8080/solr/

��会(x��)出现solr�Ƣ迎界面和admin入口

注：(x��)如果出现org.apache.solr.common.SolrException: Error loading class 'solr.VelocityResponseWriter' 异常�Q�最��单的解决�Ҏ(gu��)��Q?/span>扑ֈ�$TOMCAT_HOME/solr/conf/solrconfig.xml�Q�把注释掉或�?/span>enable:false卛_��?/span>如果一切顺利的话，现在可以看到solr的web��理界面�?ji��n)。不�q�要惛_��现分词的功能�Q�得安装一个中文分词器�Q�这里推�?span>IKAnalyzer�?/span>mmseg4j�?/span>

IKAnalyzer是一个开源的�Q�基于java语言开发的轻量�U�的中文分词工具包，采用�?ji��n)特有�?#8220;正向�q�代最�l�粒度切分算�?#8220;�Q�具�?0万字/�U�的高速处理能力，采用�?ji��n)多子处理器分析模式�Q�支持：(x��)英文字母�Q�IP地址、Email、URL�Q�、数字（日期�Q�常用中文数量词�Q�罗马数字，�U�学计数法）(j��)�Q�中文词汇（姓名、地名处理）(j��)�{�分词处理�?/span>优化的词典存储，更小的内存占用。支持用戯��典扩展定�?/span>

mmseg4j �?Chih-Hao Tsai �?MMSeg ��法(http://technology.chtsai.org/mmseg/ )实现的中文分词器�Q��ƈ实现 lucene �?analyzer �?solr 的TokenizerFactory 以方便在Lucene和Solr中��用�?/span>MMSeg ��法有两�U�分词方法：(x��)Simple和Complex�Q�都是基于正向最大匹配。Complex 加了(ji��n)四个规则�q�虑。官方说�Q�词语的正确识别率达��C��(ji��n) 98.41%。mmseg4j 已经实现�?ji��n)这两种分词��法�?/span>

�? 配置中文分词�?/span>

下面分别安装�q�两个中文分词器�Q�当焉��择安装其中一个也是可以的�?/span>

�Q?�Q?span style="color: #ff0000">安装IKAnalyzer

下蝲地址�Q?span style="font-size: 13px"> http://code.google.com/p/ik-analyzer/downloads/list

在当前目录下新徏IKAnalyzer目录�Q�解压到该目录下�Q�unzip IKAnalyzer2012_u5.zip -d ./IKAnalyzer

把IKAnalyzer目录下的IKAnalyzer2012.jar文�g拯��?$TOMCAT_HOME/webapps/solr/WEB-INF/lib/�?/span>

配置schema.xml�Q�编�?TOMCAT_HOME/solr/conf/schema.xml�Q�在文�g中添加下面这个fieldtype

注：(x��)下面的代码中多了(ji��n)很多“<span style="font-size: x-small;">”标签�Q�这个是讄��字体时iteye�~�辑器自��q��成的�?/p>
<span style="font-size: x-small;"><span style="font-size: x-small;"><span style="font-size: small;"><fieldType name="text" class="solr.TextField" positionIncrementGap="100">
        <analyzer type="index">
            <tokenizer class = "org.wltea.analyzer.solr.IKTokenizerFactory" isMaxWordLength="false" />
            <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" />
            <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1" />
            <filter class="solr.LowerCaseFilterFactory" />
            <filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt" />
            <filter class="solr.RemoveDuplicatesTokenFilterFactory" />
        analyzer>
        <analyzer type="query">
            <tokenizer class = "org.wltea.analyzer.solr.IKTokenizerFactory" isMaxWordLength="true" />
            <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true" />
            <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
            <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="0" catenateNumbers="0" catenateAll="0" splitOnCaseChange="1" />
            <filter class="solr.LowerCaseFilterFactory" />
            <filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt" />
            <filter class="solr.RemoveDuplicatesTokenFilterFactory" />
        analyzer>
    fieldType>span>span>span>

��d��一个烦(ch��)引字�D�field�Q��ƈ应用上面配置的fieldtype

<field name="game_name" type="text" indexed="true" stored="true" required="true" />

然后扑ֈ��q�一句：(x��)text把它�Ҏ(gu��)��game_name

在浏览器打开http://localhost:8080/solr/admin/analysis.jsp�Q�就可以�q�行分词处理�?ji��n)�?/span>

IKAnalyzer��d��自定义分词词典：(x��)词典文�g格式为无BOM的UTF-8�~�码的文本文�?文�g扩展名不限，一�ơ可以添加多个词库，每个词库�?;"分开。把IKAnalyzer 目录下的IKAnalyzer.cfg.xml和stopword.dic拯��?TOMCAT_HOME/webapps/solr/WEB_INF /classes目录下，可以自己新徏一个mydic.dic文�g�Q�然后在IKAnalyzer.cfg.xml里进行配�|��?br />

�Q?�Q?span style="color: #ff0000">安装mmseg4j

下蝲地址�Q?/span>http://code.google.com/p/mmseg4j/downloads/list

在当前目录下新徏mmseg4j目录�Q�解压到该目录下�Q�unzip mmseg4j-1.8.5.zip -d ./mmseg4j

把mmseg4j目录下的mmseg4j-all-1.8.5.jar文�g拯��?$TOMCAT_HOME/webapps/solr/WEB-INF/lib/�?/span>

配置schema.xml�Q�编�?TOMCAT_HOME/solr/conf/schema.xml�Q�在文�g中添加下面这个fieldtype

<fieldtype name="textComplex" class="solr.TextField" positionIncrementGap="100">
        <analyzer>
            <tokenizer class="com.chenlb.mmseg4j.solr.MMSegTokenizerFactory" mode="complex" dicPath="/home/zhoujh/java/apache-tomcat7/solr/dict">
            tokenizer>
        analyzer>
    fieldtype>
    <fieldtype name="textMaxWord" class="solr.TextField" positionIncrementGap="100">
        <analyzer>
            <tokenizer class="com.chenlb.mmseg4j.solr.MMSegTokenizerFactory" mode="max-word" dicPath="/home/zhoujh/java/apache-tomcat7/solr/dict">
            tokenizer>
        analyzer>
    fieldtype>
    <fieldtype name="textSimple" class="solr.TextField" positionIncrementGap="100">
        <analyzer>
            <tokenizer class="com.chenlb.mmseg4j.solr.MMSegTokenizerFactory" mode="simple" dicPath="/home/zhoujh/java/apache-tomcat7/solr/dict">
            tokenizer>
        analyzer>
    fieldtype>

注意�Q?span style="white-space: pre">dicPath的值改成你自己机器上相应的目录�?/span>

然后修改之前��d��的filed�Q�让其��用mmseg4j分词�?/span>

<field name="game_name" type="textComplex" indexed="true" stored="true" required="true" />

配置mmseg4j分词词典�Q?span style="font-size: 13px">MMSEG4J的词库是可以动态加载的�Q?/span>词库的编码必��L��UTF-8�Q?/span>mmseg4j 默认从当前目录下�?data 目录��d��上面的文�Ӟ��当然也可以指定别的目录，比如我就攑֜�自定义的dict目录�?/span>�?/span>自定义词库文件名必需�?"words" 为前�~��?".dic" 为后�~��?/span>如：(x��)/data/words-my.dic�?/span>

�q�里直接把mmseg4j/data目录下的所�?dic文�g拯��?TOMCAT_HOME/solr/dict目录下。共有：(x��)4个dic文�g�Q�chars.dic、units.dic�?words.dic�?words-my.dic。下面简单解释一下这几个文�g的作用�?/span>

1、chars.dic�Q�是单个字，和对应的频率�Q�一行一对，字在全面�Q�频率在后面�Q�中间用�I�格分开。这个文件的信息�?complex 模式要用到的。在最后一条过虑规则中使用�?ji��n)频率信息�?/span>

2、units.dic�Q�是单位的字�Q�如�Q�分、秒、年�?/span>

3、words.dic�Q�是核心(j��)的词库文�Ӟ��一行一条，不需要其它�Q何数据（如词长）(j��)�?/span>

4、words-my.dic�Q�是自定义词库文�?/span>

在浏览器打开http://localhost:8080/solr/admin/analysis.jsp�Q�就可以看到分词效果�?ji��n)�?/span>

现在�Q�这两种分词�Ҏ(gu��)��都已配置好了(ji��n)�Q�想用哪�U�就把查询的filed的type讄��成哪�U��?/span>

CONAN 2012-05-30 14:38 发表评论

Solr 创徏索引 From DataBase

CONAN — Wed, 30 May 2012 06:33:00 GMT
     摘要: The Data Import Handler Framework Solr includes a very popular contrib module for importing data known as the DataImportHandler (DIH in short). It's a data processing pipeline built specificallyfor S...  阅读全文

CONAN 2012-05-30 14:33 发表评论

CONAN — Wed, 30 May 2012 06:23:00 GMT
     摘要: 以下资料整理自网�l�，觉的有必要合�q�在一��P��q�样方便查看。主要分��Z��部分�Q�第一部分是对《db-data-config.xml》的配置内容的讲解（属于高��内容�Q�，�W�二部分是DataImportHandler�Q�属于基��Q?�W�三部分是对db-data-config.xml的进�Ӟ��q�个国内可能�q�没有�h写过啊，我在google、baidu上都没有搜烦(ch��)刎ͼ�最后可是拔代码�Q�看solr的英文文��找的）(j��) �W�一部分�?..  阅读全文

CONAN 2012-05-30 14:23 发表评论

CONAN — Wed, 30 May 2012 06:18:00 GMT

一、字�D�配�|�（schema�Q?/span>

schema.xml位于solr/conf/目录下，�c�M��于数据表配置文�g�Q?/p>
定义�?ji��n)加入�?ch��)引的数据的数据类型，主要包括type、fields和其他的一些缺省设�|��?/p>

1、先来看下type节点�Q�这里面定义FieldType子节点，包括name,class,positionIncrementGap�{�一些参数�?/p>
name�Q�就是这个FieldType的名�U��?/li>
class�Q�指向org.apache.solr.analysis包里面对应的class名称�Q�用来定义这个类型的行�ؓ(f��)�?/li>

< schema name = "example" version = "1.2" >
  < types >
    < fieldType name = "string" class = "solr.StrField" sortMissingLast = "true" omitNorms = "true" />
    < fieldType name = "boolean" class = "solr.BoolField" sortMissingLast = "true" omitNorms = "true" />
    < fieldtype name = "binary" class = "solr.BinaryField" />
    < fieldType name = "int" class = "solr.TrieIntField" precisionStep = "0" omitNorms = "true"
                                                                positionIncrementGap = "0" />
    < fieldType name = "float" class = "solr.TrieFloatField" precisionStep = "0" omitNorms = "true"
                                                                positionIncrementGap = "0" />
    < fieldType name = "long" class = "solr.TrieLongField" precisionStep = "0" omitNorms = "true"
                                                                positionIncrementGap = "0" />
    < fieldType name = "double" class = "solr.TrieDoubleField" precisionStep = "0" omitNorms = "true"
                                                                positionIncrementGap = "0" />
  ...
   types >
  ...
schema >

必要的时候fieldType�q�需要自己定义这个类型的数据在徏立烦(ch��)引和�q�行查询的时候要使用的分析器analyzer�Q�包括分词和�q��o(h��)�Q�如下：(x��)

view plain print ?

< fieldType name = "text_ws" class = "solr.TextField" positionIncrementGap = "100" >
  < analyzer >
    < tokenizer class = "solr.WhitespaceTokenizerFactory" />
   analyzer >
fieldType >
< fieldType name = "text" class = "solr.TextField" positionIncrementGap = "100" >
  < analyzer type = "index" >

    < field name = "all" type = "text" indexed = "true" stored = "false" multiValued = "true" />
fields >

3、徏议徏立一个拷贝字�D�，��所有的全文�?字段复制��C��个字�D�中�Q�以便进行统一的检索：(x��)

     以下是拷贝设�|�：(x��)

view plain print ?

< copyField source = "name" dest = "all" />
< copyField source = "summary" dest = "all" />

4、动态字�D�，没有具体名称的字�D�，用dynamicField字段

如：(x��)name�?_i�Q�定义它的type为int�Q�那么在使用�q�个字段的时候，��d��以_i�l�果的字�D�都被认为符合这个定义。如name_i, school_i

view plain print ?

< dynamicField name = "*_i"    type = "int"      indexed = "true"    stored = "true" />
< dynamicField name = "*_s"    type = "string"    indexed = "true"    stored = "true" />
< dynamicField name = "*_l"    type = "long"     indexed = "true"    stored = "true" />
< dynamicField name = "*_t"    type = "text"      indexed = "true"    stored = "true" />
< dynamicField name = "*_b"    type = "boolean" indexed = "true"    stored = "true" />
< dynamicField name = "*_f"    type = "float"    indexed = "true"    stored = "true" />
< dynamicField name = "*_d"    type = "double" indexed = "true"    stored = "true" />
< dynamicField name = "*_dt" type = "date"      indexed = "true"    stored = "true" />

schema.xml文档注释中的信息�Q?/span>

1、�ؓ(f��)�?ji��n)改�q�性能�Q�可以采取以下几�U�措施：(x��)

��所有只用于搜烦(ch��)的，而不需要作为结果的field�Q�特别是一些比较大的field�Q�的stored讄��为false
��不需要被用于搜烦(ch��)的，而只是作为结果返回的field的indexed讄��为false
删除所有不必要的copyField声明
��Z��(ji��n)索引字段的最��化和搜索的效率�Q�将所有的 text fields的index都设�|�成field�Q�然后��用copyField��他们都复制��C��个�ȝ�� text field上，然后对他�q�行搜烦(ch��)�?/li>
��Z��(ji��n)最大化搜烦(ch��)效率�Q��用java�~�写的客��L(f��ng)��与solr交互�Q��用流通信�Q?/li>
在服务器端运行JVM�Q�省�ȝ��l�通信�Q�，使用��可能高的Log输出�{��Q�减��日志量�?/li>

2�?span style="color: #0000ff">< schema name =" example " version =" 1.2 " >

name�Q�标识这个schema的名�?/li>
version�Q�现在版本是1.2

3、filedType

< fieldType name =" string " class =" solr.StrField " sortMissingLast =" true " omitNorms =" true " />

name�Q�标识而已�?/li>
class和其他属性决定了(ji��n)�q�个fieldType的实际行为。（class以solr开始的�Q�都是在org.appache.solr.analysis包下�Q?/li>

可选的属性：(x��)

sortMissingLast和sortMissingFirst两个属性是用在可以内在使用String排序的类型上�Q�包括：(x��)string,boolean,sint,slong,sfloat,sdouble,pdate�Q��?/li>
sortMissingLast="true"�Q�没有该field的数据排在有该field的数据之后，而不��请求时的排序规则�?/li>
sortMissingFirst="true"�Q�跟上面倒过来呗�?/li>
2个值默认是讄��成false

StrField�c�d��不被分析�Q�而是被逐字地烦(ch��)�?存储�?/p>
StrField和TextField都有一个可选的属�?#8220;compressThreshold”�Q�保证压�~�到不小于一个大��（单位�Q�char�Q?/p>

< fieldType name =" text " class =" solr.TextField " positionIncrementGap =" 100 " >

solr.TextField 允许用户通过分析器来定制索引和查询，分析器包括一个分词器�Q�tokenizer�Q�和多个�q��o(h��)器（filter�Q?/p>

positionIncrementGap�Q�可选属性，定义在同一个文��中此类型数据的�I�白间隔�Q�避免短语匹配错误�?/li>

name:    字段�c�d��?nbsp;
class:    java�c�d��
indexed:    �~�省true�?说明�q�个数据应被搜烦(ch��)和排序，如果数据没有indexed�Q�则stored应是true�?nbsp;
stored:    �~�省true。说明这个字�D�被包含在搜索结果中是合适的。如果数据没有stored,则indexed应是true�?nbsp;
sortMissingLast:    指没有该指定字段数据的document排在有该指定字段数据的document的后�?nbsp;
sortMissingFirst:    指没有该指定字段数据的document排在有该指定字段数据的document的前�?nbsp;
omitNorms:    字段的长度不影响得分和在索引时不做boost�Ӟ��讄��它�ؓ(f��)true。一般文本字�D�不讄��为true�?nbsp;
termVectors:    如果字段被用来做more like this 和highlight的特性时应设�|��ؓ(f��)true�?nbsp;
compressed:    字段是压�~�的。这可能��D��索引和搜索变慢，但会(x��)减少存储�I�间�Q�只有StrField和TextField是可以压�~�，�q�通常适合字段的长度超�q?00个字�W��?nbsp;
multiValued:    字段多于一个值的时候，可设�|��ؓ(f��)true�?nbsp;
positionIncrementGap:    和multiValued
一起��用，讄��多个��g��间的虚拟�I�白的数�?

< tokenizer class =" solr.WhitespaceTokenizerFactory " />

�I�格分词�Q�精��匹配�?/p>

< filter class =" solr.WordDelimiterFilterFactory " generateWordParts =" 1 " generateNumberParts =" 1 " catenateWords =" 1 " catenateNumbers =" 1 " catenateAll =" 0 " splitOnCaseChange =" 1 " />

在分词和匚w��Ӟ��考虑 "-"�q�字�W�，字母数字的界限，非字母数字字�W�，�q�样 "wifi"�?wi fi"都能匚w��"Wi-Fi"�?/p>

< filter class =" solr.SynonymFilterFactory " synonyms =" synonyms.txt " ignoreCase =" true " expand =" true " />

同义�?nbsp;

< filter class =" solr.StopFilterFactory " ignoreCase =" true " words =" stopwords.txt " enablePositionIncrements =" true " />

在禁用字�Q�stopword�Q�删除后�Q�在短语间增加间�?/p>
stopword�Q�即在徏立烦(ch��)引过�E�中�Q�徏立烦(ch��)引和搜烦(ch��)�Q�被忽略的词�Q�比如is this�{�常用词。在conf/stopwords.txt�l�护�?/p>

4、fields

< field name =" id " type =" string " indexed =" true " stored =" true " required =" true " />

name�Q�标识而已�?/li>
type�Q�先前定义的�c�d��?/li>
indexed�Q�是否被用来建立索引�Q�关�p�d��搜烦(ch��)和排序）(j��)
stored�Q�是否储�?/li>
compressed�Q�[false]�Q�是否��用gzip压羃�Q�只有TextField和StrField可以压羃�Q?/li>
mutiValued�Q�是否包含多个�?/li>
omitNorms�Q�是否忽略掉Norm�Q�可以节省内存空��_(d��)��只有全文本field和need an index-time boost的field需要norm。（具体没看懂，注释里有矛盾�Q?/li>
termVectors�Q�[false]�Q�当讄��true�Q�会(x��)存储 term vector。当使用MoreLikeThis�Q�用来作为相��D��的field应该存储��h��?/li>
termPositions�Q�存�?term vector中的地址信息�Q�会(x��)消耗存储开销�?/li>
termOffsets�Q�存�?term vector 的偏�U�量�Q�会(x��)消耗存储开销�?/li>
default�Q�如果没有属性需要修改，��可以用�q�个标识下�?/li>

< field name =" text " type =" text " indexed =" true " stored =" false " multiValued =" true " />

包罗万象�Q�有点夸张）(j��)的field�Q�包含所有可搜烦(ch��)的text fields�Q�通过copyField实现�?/p>

< copyField source =" cat " dest =" text " />

< copyField source =" name " dest =" text " />

< copyField source =" manu " dest =" text " />

< copyField source =" features " dest =" text " />

< copyField source =" includes " dest =" text " />

在添加烦(ch��)引时�Q�将所有被拯��field�Q�如cat�Q�中的数据拷贝到text field�?/p>
作用�Q?/p>
��多个field的数据放在一起同时搜索，提供速度
��一个field的数据拷贝到另一个，可以�?�U�不同的方式来徏立烦(ch��)引�?/li>

< dynamicField name =" *_i " type =" int " indexed =" true " stored =" true " />

如果一个field的名字没有匹配到�Q�那么就�?x��)用动态field试图匚w��定义的各�U�模式�?/p>
"*"只能出现在模式的最前和最�?/li>
较长的模式会(x��)被先��d��匚w��
如果2个模式同时匹配上�Q�最先定义的优先

< dynamicField name =" * " type =" ignored " multiValued=" true " />

如果通过上面的匹配都没找刎ͼ�可以定义�q�个�Q�然后定义个type�Q�当String处理。（一般不�?x��)发生�?j��)

但若不定义，找不到匹配会(x��)报错�?/span>

5、其他一些标�{?/p>

< uniqueKey > id uniqueKey >

文��的唯一标识�Q?nbsp;必须填写�q�个field�Q�除非该field被标记required="false"�Q�，否则solr建立索引报错�?/p>
< defaultSearchField > text defaultSearchField >

如果搜烦(ch��)参数中没有指定具体的field�Q�那么这是默认的域�?/p>
< solrQueryParser defaultOperator =" OR " />

配置搜烦(ch��)参数短语间的逻辑�Q�可以是"AND|OR"�?/p>

二、solrconfig.xml

1、烦(ch��)引配�|?/p>

mainIndex 标记�D�定义了(ji��n)控制Solr索引处理的一些因�?

useCompoundFile�Q�通过��很�?Lucene 内部文�g整合到单一一个文件来减少使用中的文�g的数量。这可有助于减少 Solr 使用的文件句柄数目，代�h(hu��n)是降低了(ji��n)性能。除非是应用�E�序用完�?ji��n)文件句柄，否�?false 的默认值应该就已经��_��?/p>
useCompoundFile�Q�通过��很多Lucene内部文�g整合��C��个文�Ӟ��来减��用中的文件的数量。这可有助于减少Solr使用的文件句柄的数目�Q�代��h��降低�?ji��n)性能。除非是应用�E�序用完�?ji��n)文件句柄，否则false的默认值应该就已经��_��?ji��n)�?/li>
mergeFacor�Q�决定Lucene�D�被合�ƈ的频率。较?y��u)��的��|��最��ؓ(f��)2�Q��用的内存较少但导致的索引旉��也更慢。较大的值可使烦(ch��)引时间变快但�?x��)牺牲较多的内存。（典型的时间与�I�间的��^衡配�|�）(j��)
maxBufferedDocs�Q�在合�ƈ内存?sh��)��文��和创徏新段之前�Q�定义所需索引的最��文档数。段是用来存储烦(ch��)引信息的Lucene文�g。较大的值可使烦(ch��)引时间变快但�?x��)牺牲较多内存�?/li>
maxMergeDocs�Q�控制可由Solr合�ƈ�?Document 的最大数。较?y��u)��的��|��<10,000�Q�最适合于具有大量更新的应用�E�序�?/li>
maxFieldLength�Q�对于给定的Document�Q�控制可��d��到Field的最大条目数�Q�进而阶�D�该文��。如果文��可能会(x��)很大�Q�就需要增加这个数倹{��然后，若将�q�个��D��|�得�q�高?sh��)��(x��)导致内存?sh��)��错误�?/li>
unlockOnStartup�Q�告知Solr忽略在多�U�程环境中用来保护烦(ch��)引的锁定机制。在某些情况下，索引可能�?x��)由于不正确的关机或其他错误而一直处于锁定，�q�就妨碍�?ji��n)添加和更新。将其设�|��ؓ(f��)true可以��用启动索引�Q�进而允许进行添加和更新。（锁机�Ӟ��(j��)

2、查询处理配�|?/p>

query标记�D�中以下一些与�~�存无关的特性：(x��)

maxBooleanClauses�Q�定义可�l�合在一起�Ş成以个查询的字句数量的上限。正常情�?024已经��_��。如果应用程序大量��用了(ji��n)通配�W�或范围查询�Q�增加这个限制将能避免当��D��出时�Q�抛出TooMangClausesException�?/li>
enableLazyFieldLoading�Q�如果应用程序只�?x��)检索Document上少数几个Field�Q�那么可以将�q�个属性设�|��ؓ(f��) true。懒散加载的一个常见场景大都发生在应用�E�序�q�回一些列搜烦(ch��)�l�果的时候，用户常常�?x��)单��d��中的一个来查看存储在此索引中的原始文��。初始的现实常常只需要现实很短的一�D�信息。若是检索大型的Document�Q�除非必需�Q�否则就应该避免加蝲整个文��?/li>

query部分负责定义与在Solr中发生的旉��相关的几个选项�Q?/p>

概念�Q�Solr�Q�实际上是Lucene�Q��用称为Searcher的Java�c�L��处理Query实例。Searcher��烦(ch��)引内容相关的数据加蝲到内存�(sh��)��。根据烦(ch��)引、CPU已经可用内存的大��，�q�个�q�程可能需要较长的一�D�|��间。要改进�q�一设计和显著提高性能�Q�Solr引入�?ji��n)一�?#8220;温暖”�{�略�Q�即把这些新的Searcher联机以便为现场用��h��供查询服务之前，先对它们�q�行“热��n”�?/p>
newSearcher和firstSearcher事�g�Q�可以��用这些事件来制定实例化新Searcher或第一个Searcher�Ӟ��应该执行哪些查询。如果应用程序期望请求某些特定的查询�Q�那么在创徏新Searcher或第一个Searcher时就应该反注释这些部分�ƈ执行适当的查询�?/li>

query中的��~�存�Q?/p>

filterCache�Q�通过存储一个匹配给定查询的文�� id 的无序集�Q�过滤器�?Solr 能够有效提高查询的性能。缓存这些过滤器意味着对Solr的重复调用可以导致结果集的快速查找。更常见的场景是�~�存?sh��)��个过滤器�Q�然后再发�v后箋(hu��)的精炼查询，�q�种查询能��用过滤器来限制要搜烦(ch��)的文档数�?/li>
queryResultCache�Q��ؓ(f��)查询、排序条件和所��h��文档的数量缓存文�?id 的有序集合�?/li>
documentCache�Q�缓存Lucene Document�Q��用内部Lucene文档id�Q�以便不与Solr唯一id相�؜淆）(j��)。由于Lucene的内部Document id 可以因烦(ch��)引操作而更改，�q�种�~�存?sh��)��能自热�?/li>
Named caches�Q�命名缓存是用户定义的缓存，可被 Solr定制插�g 所使用�?/li>

其中filterCache、queryResultCache、Named caches�Q�如果实��C��(ji��n)org.apache.solr.search.CacheRegenerator�Q�可以自热�?/p>
每个�~�存声明都接受最多四个属性：(x��)

class�Q�是�~�存实现的Java�?/li>
size�Q�是最大的条目�?/li>
initialSize�Q�是�~�存的初始大��?/li>
autoWarmCount�Q�是取自旧缓存�(sh��)��预热新缓存的条目数。如果条目很多，��意味着�~�存的hit�?x��)更多，只不�q�需要花更长的预热时间�?/li>

对于所有缓存模式而言�Q�在讄��~�存参数�Ӟ��都有必要在内存、cpu和磁盘访问之间进行均衡。统计信息管理页�Q�管理员界面的Statistics�Q�对于分析缓存的 hit-to-miss 比例以及(qi��ng)微调�~�存大小的统计数据都非常有用。而且�Q��ƈ非所有应用程序都�?x��)从�~�存受益。实际上�Q�一些应用程序反而会(x��)�׃��需要将某个永远也用不到的条目存储在�~�存?sh��)��这一额外步骤而受到媄(ji��ng)响�?/p>

CONAN 2012-05-30 14:18 发表评论

DataImportHandler--remove data from index

CONAN — Wed, 30 May 2012 06:11:00 GMT

Deleting data from an index using DIH incremental indexing, on Solr wiki, is residually treated as something that works similarly to update the records. Similarly, in a previous article, I used this shortcut, the more that I have given an example of indexing wikipedia data that does not need to delete data.

Having at hand a sample data of the albums and performers, I decided to show my way of dealing with such cases. For simplicity and clarity, I assume that after the first import, the data can only decrease.

Test data

My test data are located in the PostgreSQL database table defined as follows:
Table "public.albums" Column | Type | Modifiers --------+---------+----------------------------------------------------- id | integer | not null default nextval('albums_id_seq'::regclass) name | text | not null author | text | not null Indexes: "albums_pk" PRIMARY KEY, btree (id)

The table has 825,661 records.

Test installation

For testing purposes I used the Solr instance having the following characteristics:

Definition at schema.xml:

<fields>
<field name="id" type="string" indexed="true" stored="true" required="true" />
<field name="album" type="text" indexed="true" stored="true" multiValued="true"/>
<field name="author" type="text" indexed="true" stored="true" multiValued="true"/>
fields>
<uniqueKey>iduniqueKey>
<defaultSearchField>albumdefaultSearchField>

Definition of DIH in solrconfig.xm
<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
  <str name="config">db-data-config.xmlstr>
lst>
requestHandler>

And the file DIH db-data-config.
<dataConfig>
<dataSource driver="org.postgresql.Driver" url="jdbc:postgresql://localhost:5432/shardtest" user="solr" password="secret" />
<document>
  <entity name="album" query="SELECT * from albums">
   <field column="id" name="id" />
   <field column="name" name="album" />
   <field column="author" name="author" />
  entity>
document>
dataConfig>

Deleting Data

Looking at the table shows that when we remove the record, he is deleted without leaving a trace, and the only way to update our index would be to compare the documents identifiers in the index to the identifiers in the database and deleting those that no longer exist in the database. Slow and cumbersome. Another way is adding a column deleted_at: instead of physically deleting the record, only add information to this column. DIH can then retrieve all records from the set date later than the last crawl. The disadvantage of this solution may be necessary to modify the application to take such information into consideration.

I apply a different solution, transparent to applications. Let’s create a new table:

1 CREATE TABLE deletes

2 (

3 id serial NOT NULL,

4 deleted_id bigint,

5 deleted_at timestamp without time zone NOT NULL,

6 CONSTRAINT deletes_pk PRIMARY KEY (id)

7 );

This table will automagically add an identifier of those items that were removed from the table albums and information when they were removed.

Now we add the function:

01 CREATE OR REPLACE FUNCTION insert_after_delete()

02 RETURNS trigger AS

03 $BODY$ BEGIN

04 IF tg_op = 'DELETE' THEN

05 INSERT INTO deletes(deleted_id, deleted_at)

06 VALUES (old.id, now());

07 RETURN old;

08 END IF;

09 END $BODY$

10 LANGUAGE plpgsql VOLATILE;

and a trigger:

1 CREATE TRIGGER deleted_trg

2 BEFORE DELETE

3 ON albums

4 FOR EACH ROW

5 EXECUTE PROCEDURE insert_after_delete();

How it works

Each entry deleted from the albums table should result in addition to the table deletes. Let’s check it out. Remove a few records:

1 => DELETE FROM albums where id < 37;

2 DELETE 2

3 => SELECT * from deletes;

4 id | deleted_id |         deleted_at

5 ----+------------+----------------------------

6 26 |         35 | 2010-12-23 13:53:18.034612

7 27 |         36 | 2010-12-23 13:53:18.034612

8 (2 rows)

So the database part works.

We fill up the DIH configuration file so that the entity has been defined as follows:

1 <entity name="album" query="SELECT * from albums"

2   deletedPkQuery="SELECT deleted_id as id FROM deletes WHERE deleted_at > '${dataimporter.last_index_time}'">

This allows the import DIH incremental import to use the deletedPkQuery attribute to get the identifiers of the documents which should be removed.

A clever reader will probably begin to wonder, are you sure we need the column with the date of deletion. We could delete all records that are found in the table deletes and then delete the contents of this table. Theoretically this is true, but in the event of a problem with the Solr indexing server we can easily replace it with another – the degree of synchronization with the database is not very important – just the next incremental imports will sync with the database. If we would delete the contents of the deletes table such possibility does not exist.

We can now do the incremental import by calling the following address: /solr/dataimport?command=delta-import
In the logs you should see a line similar to this:
INFO: {delete=[35, 36],optimize=} 0 2
Which means that DIH properly removed from the index the documents, which were previously removed from the database.

CONAN 2012-05-30 14:11 发表评论

Solr 使用 Log4j

CONAN — Wed, 30 May 2012 06:01:00 GMT

大家知道在解压开solr的web�E�序�Q�apache-solr-3.2.0.war�Q�时�Q�在其WEB-INF/lib目录下有slf4j- api-1.5.5.jar�Q�slf4j-jdk14-1.5.5.jar�q�两个jar包，故可知其默认使用的是jdk的日志数据，其日志都是输入到 tomcat的logs中；再看其是�l�合slf4j�q�行jdk的日志数据；slf4j�q�不是一�U�具体的日志�pȝ��Q�而是一个用��h��志系�l�的facade�Q�允许在部��v最�l�应用时方便的变更其日志�pȝ��。故solr使用log4j也是ok的，即采用log4j替换jdk的日志输入；做法如下�Q?br />1. ��solr/WINF-WEB/lib中的slf4j-api-1.5.5.jar�Q�slf4j-jdk14-1.5.5.jar删除�Q�新加入 log4j-1.2.15.jar slf4j-api-1.5.0.jar slf4j-log4j12-1.5.0.jar或是其对应的jar包；
2.在solr/WEB-INF/下创建classes目录�Q�因为默认的包中没有该目录，光��是��用jsp操作�Q?br />3. ��写好的log4j.properties攑ֈ�solr/WEB-INF/classes�? 其内容如下，

log4j.rootLogger=INFO
log4j.logger.org.apache.solr=INFO,ROLLING_FILE

log4j.appender.ROLLING_FILE=org.apache.log4j.RollingFileAppender
log4j.appender.ROLLING_FILE.Append=false
log4j.appender.ROLLING_FILE.File=/var/log/solr.log
log4j.appender.ROLLING_FILE.MaxBackupIndex=50
log4j.appender.ROLLING_FILE.MaxFileSize=200MB
log4j.appender.LOGFILE.Threshold=INFO
log4j.appender.ROLLING_FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.ROLLING_FILE.layout.ConversionPattern=%d{yyyy-MM-dd HH\:mm\:ss} %p [%c]\:%L Line – %m%n

4.重启tomcat卛_��
PS�Q�如果是采用JNDI部��v�Q�最好将以上的重新打包war�Q�在替换旧的

CONAN 2012-05-30 14:01 发表评论