分布式搜索方案选型

一：Solr

      我第一个了解到的分布式搜索框架是solr,它是由java开发的，基于lucene的分布式搜索引擎，提供了相似于webserver的编程接口，是一个比较成熟的搜索引擎，目前不少公司都在使用。很快我就部署了一个由4台机器组成的solr集群，开始导公司的数据进去测试，导的数据为200万。导入速度很是快。接下来就开始测试查询效率，发现它是有缓存的，第一次查询的时间基本上在80～150毫秒之间，第二次查因为有缓存，查询时间基本上只须要18~35毫秒，能够说很是之快。它如何作到分布式？由于如今作的是集群，每台机器存储的信息是同样的，怎样作到把索引信息进行拆分？因而就到solr的官网查资料，原来solr是有索引分片功能的，能够经过分片把索引拆分红多个部分，分布到不一样的机器上。知道怎样作后就部署了两个分片，测试后发现性能差很少，不过这样还有问题就是怎样作到索引分布的负载均衡？solr并无提供自带的负载均衡，彻底要本身编程实现，并且实现起来很是复杂，因而放弃了这个方案。

solr官网：http://lucene.apache.org/solr/

二：Solandra

     我在学校项目实践时使用过solandra，它是一个基于solr和nosql数据库cassandra的分布式搜索引擎。cassandra是由facebook开源的nosql数据库，facebook的信箱搜索就是基于它实现的，它是基于列结构的，不一样与关系数据库。它的数学模型基于google的bigtable和Amazon的Dynamo，它的一个重要特性是没有对外没有中心节点，因此不会存在单点故障的问题，若是当前猪节点挂了，那么它余下的节点会进行自动投票，选举出新的节点，这种特性将来一定是全部分布式系统的特性之一。它是当前热门的nosql数据库之一。

       我看了下它的源码，它从底层上从新实现了solr索引的存储，把索引数据保存到cassandra中。它的这种实现方式给了我一个思路，就是lucene和nosql数据库结合的可行性。因为solandra的零配置和自动发现的特性，很容易就部署起来，基本上一启动服务就好了。我把原先用于测试的200万数据导浸solandra中，它彻底是黑盒模式的，你根本不知道你的数据分布到了那台机器，你能够设置副本数来冗余数据，增长可用性和容错性。

       导完数据就对它进行性能测试，发现它的第一次查询效率很是低，平均查询时间4秒，比原生的solr低了不少，我猜想这里性能的差距主要是由于它把索引存储cassandra中，本来的是直接保存到文件系统中的，如今是先从数据库读取到文件系统，多了一步，因此查询效率有所差别，不过这样的好处是真正实现了索引的分布式存储。想到若是运行当中有台机器挂了怎么办？因而就开始测试它的容灾性，结果发现，若是是一个3台机的solandra机器，挂了其中一台机仍是能够查的，可是若是挂了两台机就搜索不出东西。这是由于我把索引的副本定义为2即集群中有两份完整的索引。因为它索引不可见的黑盒特性咱们并不知道它实际上索引的分布状况，这样的话对后期索引的维护并很差。加上它查询效率的问题，最终放弃该方案。

solandra项目地址：https://github.com/tjake/Solandra

三：SolrCloud

    逛solr官网时无心发现了solrCloud这个开源项目，即solr云或叫分布式solr。它是基于solr的，使用zookeeper做为节点之间通讯管理，它具备solr的全部特征，并提供索引分片的功能，不过这是要本身在配置文件中配置分片信息的。它好的地方是它是个实时的搜索引擎，即将推出的lucene4.0将实现实时搜索，而solrCloud就是基于开发中的lucene4.0的，目前solrCloud也是个本成品，本着试试的心态根据官方配置文档搭建了

一个三台机器，三个分片的分布式环境并对其进行测试。查询效率与三台机的solr集群差很少，都比较快。不过它的搜索接口很很差，你要在请求的url中指定分片的地址，如：http://localhost:8983/solr/collection1/select?shards=shard1,shard2,shard3。还有一个很差的地方是和solr同样，创建索引时它没有自动给你作负载均衡，若是你一直往分片1中插数据它也无论你的，你要本身编程去完成索引的均衡分配，这样的话工做量就很大了。因而放弃solrCloud。

solrCloud项目地址：http://wiki.apache.org/solr/SolrCloud

四：Solr+Katta

     一个叫katta的开源项目进入个人视线，它是一个分布式索引创建和管理工具，底层是hadoop的hdfs分布式文件系统，hadoop是当今云计算的热门使用项目，由apatch开源是一个海量数据的处理和存储方案，它的主要核心就是它的hdfs分布式文件存储系统和mapreduce算法，它们分别是google论文中的gfs和mapreduce的开源实现。目前大公司的云计算平台基本上都是基于它来搭建的。由于我以前在学校作的一个搜索引擎项目也是基于它的，因此我对它仍是比较熟悉的，经过以前写过的自动化部署脚本，我很快就搭起了一个由4台机器组成的hadoop集群，每台机160G的硬盘，乘于4的话就是640G了，并且这640G仍是一个总体来的哦，之后若是空间不够了，或者运算能力不够了的话就直接加机器就好了，使用hadoop能够很是容易的提升整个系统的运算能力，google的核心技术之一就它了。而katta这个项目只是个lucene的索引管理工具，经过hadoop的mapreduce算法来批量创建索引，它的很大部分特性都是参考了nutch（一个基于hadoop的开源爬虫项目），它提供的搜索功能很弱，只有最基本的查询方法，一些高级的如：分组，统计，范围查询都没有的，因而试试看看可否把它和solr进行集成，由于solr提供了很强大的搜索功能，网上搜索发现有人已经研究实现它了，就是这个帖子https://issues.apache.org/jira/browse/SOLR-1395，不过配置过程极其复杂，并且还要该不少的源码，我看那帖子是从10年就开始了的，他们的讨论已经持续一年多了，貌似尚未什么结果，可见难度仍是比较大的。就没有深刻去了解。

 

katta官网：http://katta.sourceforge.net/

五（终篇）：Elasticsearch

     最后发现了elasticsearch这个分布式搜索框架，我一看它的介绍就以为，就是它了。它基本上全部我想要的特性都包含了，分布式搜索，分布式索引，零配置，自动分片，索引自动负载，自动发现，restful风格接口。因而就开始使用，部署了四台机器，并把索引导了进去，我设置的分片为3，即把索引分红三片，副本为2，即有两份完整的索引。

      经过它的管理工具能够很清晰的看到它索引分布的状况：哪块分布在那里，占用空间多少均可以看到，而且能够管理索引。还发现当一台机挂了时，整个系统会对挂机里的内容从新分配到其它机器上，当挂掉的机从新加入集群时，又会从新把索引分配给它。固然，这些规则都是能够根据参数进行设置的，很是灵活。对它的搜索效率进行测试，查询时间基本上维持在200毫秒左右，第二次搜索的话由于有缓存，因此和solr差很少。但通过详细对比测试后发现，solr在建索引时的查询性能很是之差，由于solr在建索引时会产生io的阻塞，形成搜索性能的降低，但elasticsearch不会，由于它是先把索引的内容保存到内存之中，当内存不够时再把索引持久化到硬盘中，同时它还有一个队列，是在系统空闲时自动把索引写到硬盘中。

       它的存储方式有四种，1.像普通的lucene索引，存储在本地文件系统中。2.存储在分布式文件系统中，如freeds。3.存储在hadoop的hdfs中。4.存储在亚马逊的s3云平台中。它支持插件机制，有丰富的插件。好比和mongoDB couchDB同步的river插件，分词插件，hadoop插件，脚本支持插件等。它有个第三方的solr接口模拟插件，使用这个插件可使你本来基于solr的系统无须改代码直接切换到elasticsearch中，它仍是个准实时的搜索引擎，所谓实时搜索引擎就是当你索引一个文档后你搜索这个文档当即就能搜索到。因而就决定使用这套分布式搜索框架。

 

后记：以前还简单了解过LinkedIn的zoie，它也是个准实时搜索框架，不过它是不支持分布式的，如今LinkedIn开源出了基于zoie的分布式搜索框架sensei，这个没研究过，有空能够试下。

 

elasticsearch solr对比评测：http://engineering.socialcast.com/2011/05/realtime-search-solr-vs-elasticsearch/
elasticsearch官网：http://www.elasticsearch.org/