分布式搜索方案选型

 

分布式搜索方案选型

                                                                           --- 不同选型之讨论

 

分布式搜索方案选型之一：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是当今云计算的热门使用项目，由apache开源是一个海量数据的处理和存储方案，它的主要核心就是它的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，这个没研究过，有空可以试下。

 

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

elasticsearch官网：http://www.elasticsearch.org/