分布式搜索方案选型(转)

分布式搜索方案选型之一：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/