Solr4.0(SolrCloud) & ElasticSearch(ES) 比较(二)

来源： 三山五岳合创斋 Solr4.0(SolrCloud) & ElasticSearch(ES) 比较(二)

好久没有更新该系列，主要忙于之前的评估，结束后又是对solr4.0的深入研究和修改。好废话少说，我们开始今天内容 开始solr4.0（cloud）之前我们先看看ElasticSearch（ES）与solr3.6对一些常见feature支持情况的比较。强调这里是solr3.6而非solr4.0。两者的根本区别是后者基于分布式的架构。
 上面是一些常见feature的比较。这里要说的是最后的两项。 索引的rebuild 索引的重构需要对源数据的存储。这是搜素引擎自己要关心的安全问题。目前存储选择主要是传统的数据库或者分布式数据库（DDB）和类似的NoSql数据库。传统的数据库免费的自然是MySql。商业数据库以oracal居多。而云存储的备份选择就比较多了：CouchDB，Redis，MongoDB，Membase，Neo4j，HBase，Cassandra等等，选择原则各有不同。参考8种Nosql数据库比较 不管是传统RDB或者新兴Nosql存储都涉及到搜索引擎和存储系统的整合。以冗余的数据空间来换取索引内容的安全。这种妥协对于商用搜索引擎是十分必要的。 跨DC的备份 目前尚未有开源搜索项目支持。实际上开源搜索项目主要还是针对大中型搜索集群，对于跨DC的超大规模集群并不是目前开源项目的目标。可能是考虑到主流用户群的需求还是集中在中大型甚至小型搜索上（google是在好几年前就实现了跨DC的能力）。 下面再看看对一些重要feature在ElasticSearch和Solr3.6上进行添加或修改的难易程度     可以看到除了在添加、删除shard上ES不能支持外。其特征是多余solr3.6的 Chang shard这里主要指在服务运行时增加或删除shard，尤其是增加shard通常是一个重要的feature。我们知道应用数据是不断增加的，随着数据的积累，索引请求的增加，加入新的shard来出理不断增长的数据就成为一个和合理而自然的需要。然而ES的架构决定其很难做到shard的伸缩。而同样的solr包括现在的4.0版也不支持shard数的热增长。假如要强行在shard层做修改以试图支持这种Scalability，那么ES的代价将高于solr（4.0） 。但对于shard的热增长两者都可以通过其它方式去较好的解决。此处不详述。 上面我们看了ES和Solr3.6的比较。我们看SOlr4.0有哪些变动，先看看4.0的架构   Solr4.0相对于Solr3.6的新特征：

•Central configuration of the entire cluster.

•Automatic load-balancing and fail-over for query.

•Zookeeper for coordination and configuration.

•Near Real-time.

 

solr4.0 与ES的feature比较

 上面是Solr4.0 alpha版的特征为基础。Solr4.0在Beta版之后又增加了collection的概念，相当于Tennacy。所以此处Multi Tenancy 在Solr4.0中是支持的了。其他重要的feaure两者相差不大。 权限控制：这里要特别提出权限验证的问题。对于商用产品权限验证是必须的。两者都不支持权限验证。需要用户自己增加这一块的功能。然而就目前来看，两者在增加该功能的难易程度来说，ES是相对容易很多。原因为ES内部节点之间使用自定义协议；而Solr4.0内部节点之间使用了和外部一样的http协议，并且节点间的通信关系混乱，所以对目前的Solr4.0增加权限验证以及ACL将很难寻找到一个优雅的解决方案，但并不是不可以。 除此之外solr4.0还有一些其它难于再次开发的地方，以后再叙述。 下一次将把Solr4.0 alpha同ES的性能测试比较结果列出来，以作参考。由于alpha版并不成熟，性能上可能会和正式版有一定差距。

总结

总体来说Solr4.0正式版也刚发布不到半年。存在的问题不少，其架构能否经得起考验，还有待时间来证明。从代码的优雅程度还是和ES有一定的差距，但代码的易读性上好于ES（ES大量使用模式，且调用层次太深，方法的追踪麻烦）