站内搜索解决方案有哪些?怎么选
对很多 APP、网站或者业务来说，搜索是一项既不可或缺，又难以调整到满意状态的功能。比如对于电商类网站或 APP 来说，用户不光是需要搜索关键词，有时候还需要过滤价格、用同义词进行搜索等。而搭建一个好用好维护，排序让用户满意的站内搜索也并非易事。本文里，我们总结市面上所有的站内搜索解决方案，方便准备接入或提升搜索功能的同学们参考。
市面上的搜索解决方案有哪些
虽然信息检索系统自 2000 年 Google 开始发力以来，有了长足的进步，但站内搜索或企业内部搜索的格局却一直变化不大。
很多公司在数据规模较小，用户使用习惯较为简单时，会选择使用数据库的模糊搜索功能。但由于数据库的模糊搜索只能满足严格的短语匹配，很难适应用户多样的搜索词请求。同时前后缀模糊匹配，即类似"%电视%"的匹配耗时较长，通常会给用户带来很糟糕的体验。
对于很多公司来说，搜索功能虽然必不可少，但是投入团队和人力专门做搜索，却与公司业务南辕北辙。因此，市面开始出现一些开源的或商用的搜索解决方案。我们在这里介绍所有我们能找到的站内搜索解决方案，同时对比它们的优缺点
Elastic Search
Elastic Search（以下简称 ES） 无疑是日志搜索和大规模分布式搜索的王者。目前在纽交所上市的 ES 市值达到 120 亿美元，也可以看出市场对其的信心。
但是 ES 一开始就被设计成分布式搜索引擎，主要设计用途是处理海量日志信息。Elastic Search 的使用场景多为上 TB 数据，比如 Splunk 提供的日志处理服务和阿里云提供的日志处理服务等，都用的是 Elastic Search 作为其后端服务支撑。
同时，ES 专注于能用性，因此如果需要将 ES 用于站内搜索解决方案，需要大量的二次开发和调优。为了能调整出令用户满意的搜索体验，你通常需要一位深谙搜索的后端工程师或搜索工程师来专门开发，而经验上这样的工程师也是比较难招到的。
如果需要使用 ES 来处理中文搜索的话，需要使用一系列插件，比如 IK 或结巴分词等等。同时 Elastic Search 的排序是基于单分数的排序系统，这就意味着你需要设计一个“靠谱的”排序评分函数。而多数情况下即使极为有经验的搜索工程师也需要大量的尝试和迭代，才能将排序调整到一个可用程度。除此之外，如果你对用户的搜索体验在意，比如希望用户每次搜索等待时间不超过 1 秒的话，则在 Elastic Search 中可能需要大量调优和避免踩坑。
因此，如果你的业务本身是日志处理，比如国内的日志易，那么使用 Elastic Search 无可厚非。但如果你的业务是电商、SaaS、社交或者媒体等，使用 Elastic Search 无异于用重机枪来对抗蚊子——不光打不到，还需要极多的工程师资源来处理其带来的一系列问题。在这些情况下，我们推荐使用一些成熟的站内搜索解决方案，比如下面要介绍的卡拉搜索
卡拉搜索作为搜索解决方案
卡拉搜索是由我们开发的站内搜索解决方案。我们在 Lucene 的基础上重写了核心的搜索和排序模块，重用了 Lucene 的倒排引擎和搜索 API（这点与 Elastic Search 类似）。但是卡拉搜索设计的出发点就是专门的站内搜索引擎和数据库搜索引擎，因此我们剔除了了大量只与日志搜索相关的功能，同时加入了大量专属于站内搜索的功能，比如说
- 极强的易用性，几分钟即可接入；统一的后台可用于管理数据和排序器，实时调整结果
- 自带开箱即用的分词系统
- 可定义同义词、近义词。针对国内复杂的监管需求，我们也提供监管解决方案
- 丰富灵活的过滤器（对结果进行价格过滤、时间过滤等）
- 注重速度和用户体验，每次搜索通常在 50 毫秒内返回，同样情况下比 ES 快 10 倍
如果对卡拉搜索感兴趣，欢迎参考我们的网站卡拉搜索。
Solr
Solr 是 Apache Lucene 的一个子项目，由 Yonik Seeley 发起。
Solr 目前是目前全球使用最广泛的搜索引擎之一，它用Java编写，也建立在Lucene之上。换句话说，Solr 围绕 Lucene 的HTTP 封装。因此，如果你的团队中有人对 Lucene 特别熟悉，需要用到非常多底层的功能，我们推荐使用 Solr。
但是与 Elastic Search 类似，Solr 也是通用搜索引擎，因此使用非常复杂。作为站内搜索并不容易，甚至比 Elastic Search 更加麻烦一些，原因是 Solr 的开发者生态较小，因此如果遇到问题则非常难找到对应的帮助。
对比起来，如果是需要站内搜索功能，我们建议多数公司优先考虑使用卡拉搜索，其次考虑 Elastic Search，最后在工程师熟悉 Lucene 的前提下，再考虑 Solr。
Sonic
Sonic 是唯一极端优化速度，且响应速度接近卡拉搜索的搜索引擎，但它并不能被称为是一个“解决方案”，因为如果你需要使用 Sonic 的话，需要同时实现很多周边的模块。
比如说，Sonic 的搜索结果是 id，而你需要重新从数据库中将对应的对象注入，因此你可能需要在搜索服务上加入对象注入的特定逻辑。另一方面，虽然 Sonic 支持中文 lexing，但具体的分词以及对排序的影响等，则并没有特别支持。
总体而言，虽然 Sonic 在 github 上拥有大量簇拥，潜力十足，但现阶段其作为一个创业公司的 20% 项目（Sonic 是 Crisp 这家客服软件公司员工为其 Crisp 软件特别添加且开源的搜索引擎），并没有非常丰富的生态，无法达到开箱可用的要求。
因此，在上文提到的所有工具中，如果需要站内搜索解决方案，我们建议的顺序是
卡拉搜索 > Elastic Search > Solr > Sonic
Algolia
Algolia 可以说是卡拉搜索的老师，其主要顾客位于欧美，因此所有的功能和引擎设计都是针对英文用户。而多层排序设置、开箱即用等功能则与卡拉搜索一致。
同时 Algolia 的引擎为英文等字母语言设计，而卡拉搜索的引擎则专门为中文设计，如果你的用户在海外，那我们建议你使用 Algolia。另一方面，Algolia 的数据中心遍布欧美，你的海外用户也因此可以达到较快的搜索速度。
如果你的用户多数位于国内，主要使用中文搜索，则首先考虑卡拉搜索。我们专门针对 Algolia 和卡拉搜索的对比写了一篇对比文章。
总结
本文中我们总结了市面上常见的站内搜索/APP内搜索解决方案，同时针对不同的情况和使用场景，给出了对比和推荐理由。如果你对卡拉搜索感兴趣，欢迎联系我们
