白话 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，但是那段代码会相对来说比较不易懂，也不好维护。

二是语法。Solr 和 Ruby 结合，很多程序可以写的特别小巧且灵活。而 ES 的纯 JSON 表达则略显臃肿。但是就好像 Ruby 和 Java 的区别，这种 JSON 表达更具有一致性，所有的代码会有很类似的结构，更好懂。另外 Solr 从最开始的设计就比较针对文本搜索。而 ES 对于非文本的数据似乎有着更好的支持。加上其比较一致性的语法规范，对于复杂的 Query 的组合，ES 语句的读写都要更简单明了。

还有一些和公司当时 Infra 相关联的其他因素。

一是前面说的，当时我们的 Solr 和 ETL 在两个 Repo 里。这样以来，每次的 Deploy 就需要两个 Repo Deploy 的相互协调。而且所有的代码改动的兼容性管理就略复杂。而 ES 我们是和我们的 ETL 一起做到了一个独立的 Java Service 里。代码管理和部署都相对简单的多。

二是数据 Pipeline 的建立。当时公司里 Kafka 的 Producer 和 Consumer 对 Java 有了比较好的支持，所以新的基于 ES 的搜索系统可以比较方便的从 Kafka 里拿数据。而 Solr ＋ Ruby 的老系统只能使用比较老的 Trigger 和 Feed 来拿数据。这样一来，很多 Upstream 的数据管道的建立而言，ES 要干净漂亮的多。

三是性能。当时使用了 ES 的分布式支持，而老的 Solr 系统其实是单节点多 Replica 的架构。很自然的，查询性能上 ES 确实要好很多。

搜索和推荐

很多时候，搜索系统和推荐系统是可以共用部分后端 Service 的。因为他们可以使用相同的 Index 数据，也就是只需要建立一套数据 Pipelien 和 ETL系统。在此之上，Query 可以使用不同的方式来实现，从而达到搜索或者推荐的功能。ES 和 Solr 都提供了类似的不同的 API。当时我们做出来的搜索后端，后来就有另一个项目组使用我们的数据，基于其上加了一些复杂的机器学习模型，做出了一个推荐系统。而我们的搜索部分，只使用了一些最基本的 Filter 和 Scoring 机制。

搜索系统的定制

虽然说使用原始的 Lucene 挑战性更大，很多公司一开始便选择搭建自己的搜索后端（如 Airbnb）。也有一些公司使用一段时间 Solr 或者 ES 后转而开发自己的搜索引擎。而定制的原因主要就是灵活性。

（编辑：南平站长网）

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