Solr结合hbase处理大数据的方法
在solr 4.0 以后，一个重要特性是加入了分布式和实时性搜索。Solr的分布式部署方式叫做solr cloud。
1、配置文件的管理
其用于控制如何对一条记录的分词和索引方式的配置文件index.xml、控制一个solr core(独立的能够提供搜索和索引的其本单位)的有关参数的配置文件solrconfig.xml、控制从多种数据源（常用的如数据库数据源）抽取数据的模板的配置文件data-config.xml等配置文件上传于一个分布式的内存存储系统zookeeper(它还可以协调分布式系统的状态等)。
2、使用方式
根据一条数据具体交给哪个shard建立索引现可将使用方式分为以下几种，在solr 源代码中由以下几个内决定。
2.1、PlainIdRouter
此方式是在第一台solr节点启动的时候，需要指定一个将整个集群分成多少个逻辑部分(shard)的DnumShards,一旦指定，就现在的solr cloud版本来说将不可改变，不能扩展。每台solr节点在启动时，都需要为其指定zookeeper 集群的地址，以便于它去那里取得solr core启动时需要的配置文件，注意一个solr节点（即一个独立的tomcat项目）可以同时包含几个solr core,分属于不同的或者相同的solr shard。当所有的shard 都有了相应的多个或者一个core(具体多少个确定于你的配置Replication Factor),solr cloud便可以对外提供搜索和对数据建立索引的能力和接口了。它提供的接口可以有很多种，如客户端 solrj ,http协议、Python。此种方式的好处是，对数据建立索引的客户端不需要关心数据交给哪个shard处理，集群自动分发数据到一个shard（根据主键的hash值取模hash_function(doc.getKey()) % N）。
2.2、CompoliteIdRouter
此方式与2.1的相同，都要在定一台solr节点启动时，指定DnumShards,内部也需要对主键取hash值。但是现在如果有这么个需求，如果你有如下4条数据：
typeid
a 1
a 2
b 3
b 4
你希望type为a的数据都位于同一个shard里面，type为b的数据位于另一个shard里面。就需要利用CompoliteIdRouter，其使用方式是在传递给schema.xml里面配置的主健字段的值如下，用!将type和id连接起来，如a!1、a!2、b!3、b!4。
2.3、ImplicitDocRouter
此方式的最大特点是不需要在第一个结点启动时指定DnumShards，也不需要hash函数。而且如果你控制得好，还可以动态的添加shard，可以解决solr cloud不能动态扩展的问题。比如说你的数据是每天在新产生数据，你可以每天产生一个shard来容纳当天的数据。稍微麻烦点的是，在建立索引时你需要明确指定此数据放入哪个shard,通过在你的doc 中添加一个字段shard来指明。但他不只是带来动态扩展的好处,在搜索的时候如果你清楚你的数据是位于哪些shard里面的，你就可在搜索的时候指定参数shards=shard1,shard2…这样solr集群就只会去搜索这几个shard，如果你的集群的shard数很大，能极大的提高搜索速度。
3、搜索速度优化及jvm内存调优
为了减少搜索速度，减少索引文件大小，可选择只存储部分字段，如主建字段等。将每条数据存放在hbase数据库中，在展示结果的时候，通过全文搜索得出的主健值 ，通过hbase的row-key得到每条记录。而这正是hbase的长处。
Jvm 内在溢出问题可参考这两篇文章
http://blog.csdn.net/aisoo/article/details/8263841
http://kenwublog.com/docs/java6-jvm-options-chinese-edition.htm
另还有一个solrconfig.xml里面的配置对于大数据处理时内存溢出相当关键，具体参数请看文件里面的说明。