solr hbase 大数据

Solr结合hbase处理大数据的方法

 

在solr 4.0 以后,一个重要特性是加入了分布式和实时性搜索。Solr的分布式部署方式叫做solr cloud。

1、配置文件的管理

其用于控制如何对一条记录的分词和索引方式的配置文件index.xml、控制一个solr core(独立的能够提供搜索和索引的其本单位)的有关参数的配置文件solrconfig.xml、控制从多种数据源(常用的如数据库数据源)抽取数据的模板的配置文件data-config.xml等配置文件上传于一个分布式的内存存储系统zookeeper(它还可以协调分布式系统的状态等)。

2、使用方式

根据一条数据具体交给哪个shard建立索引现可将使用方式分为以下几种,在solr 源代码中由以下几个内决定。

 
solr hbase 大数据_第1张图片
 

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里面的配置对于大数据处理时内存溢出相当关键,具体参数请看文件里面的说明。

你可能感兴趣的:(solr)