白话 IT 之 聊聊搜索

二是语法。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 后转而开发自己的搜索引擎。而定制的原因主要就是灵活性。

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

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