白话 IT 之 聊聊搜索

有很多人对两者做过对比。例如：http://solr-vs-elasticsearch.com，从 API 、Infrastructure、Indexing、Searching、Customizability 等多个方面对两者的优缺点进行了详尽的阐述。总体说来，目前两者的版本对于大部分人需要的性能都有比较好的支持。并没有说哪个比另一个好。只有一些小的特性上有一些区别，例如 ES 的 percolation，Solr 的 Pivot Facets 等。这里说几个曾经比较大的区别（这些区别似乎在后来的版本中逐渐不那么明显）。

一是对于 Cluster 上各结点的管理。之前我在《白话 IT 之 从 ElasticSearch 到 ZooKeeper》一文中提过一些。ES 内部的节点管理系统存在 Split Brain 的问题。而 SolrCloud 使用 ZooKeeper 管理节点，解决了这个问题，但是意味着 SolrCloud 需要 ZooKeeper 的部署。但是因为 ES 其实也可以使用外部 ZooKeeper 来取代其内置的节点管理，因此，这一区别也就不那么明显。

二是 Re-sharding。我用 Solr 和 ES 是三年前，那时候两者都不能动态改变 Shard 的个数。每次改 Shard 个数，都要把所有 Index Data 抹掉重新做 Indexing（从头 ETL 所有数据）。所以我们一开始设计系统的时候，对于 Shard 的配置就特别谨慎。但是 2013 年之后，Solr 就可以支持 Shard Splitting 了。所以从这一点上来说，ES 有一定的局限性。但是 ES 同时又支持 Shard 的 Rebalancing，这一点 Solr 又没有。总之，如果一开始设计系统的时候知道两者的局限性，或者 Re-index 整个搜索系统数据的代价不是太大的情况下，Re-sharding 和 Shard Rebalancing 也不是什么大问题。

三是社区支持，也就是遇到疑难杂症的时候是不是能够很快找到解决方案。三年前的时候，Solr 比 ES 要成熟很多，那时候很多 ES 遇到的问题都很难找到详尽的解释，不过现在似乎两者的用户群都很成熟，并没有很明显的区别。此外因为 Solr 是完全开源的，ES 是允许任意用户 Contribute 但是必须 ES 的人 Review 和 Approve 才能 Merge。所以熟悉 Solr 的开发者可能更为众多。

此外还有一些比较细致的比较，我觉得这篇文章写得很好，推荐阅读：

Solr or Elasticsearch — That is the Question: https://www.datanami.com/2015/01/22/solr-elasticsearch-question/

个人感受

当年在 Square 的时候，其实 Solr 和 ES 都用过。最开始 Sqaure 的搜索后端是用 Solr 写的，和 Ruby 结合。当时 Solr 的一些定制，如 Schema，是一个 Repo，其 ETL 是在另一个 Repo。后来一次 Hackathon，我和几个同事因为好玩儿，用一周的时间用当时刚刚开始火的 ES 重写了一个搜索的原型（当然，只有一些最基本的功能，数据 Pipeline 都没有搭好，比较 Hack 地去写入一些数据。）通过这个简单的原型我们展示了 ES 的一些优势，所以后来就把整个搜索后端移到了 ES 上，做成一个独立的 Java Service。

那么当时我们从 Solr 转到 ES，是因为哪些优势呢？

一就是 Nested Typing。什么意思呢？打个比方，你需要 Index 一些类似于淘宝上店家的信息，同时又需要 Index 一些类似于商品的信息。而这两个数据之间其实是有一种类似于父子关系的联系的。ES 对此有着很好的支持。这样，你在 Indexing 的 ETL 中，可以自然地描述两个数据的关系（商品属于某店家），在查询时，也可以比较方便的写出需要对父类或子类进行 Filter 的 Query。而当时我们的搜索后端正需要这样的一个特性。虽然说用 Solr 也有办法 Work Around，但是那段代码会相对来说比较不易懂，也不好维护。

（编辑：网站开发网_安阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!