两天后还是决定将搜索更换为algolia

2020-11-21 约 1000 字预计阅读 2 分钟 - 次阅读

警告

本文最后更新于 2020-11-21，文中内容可能已过时。

博客搭建好之后，还算满意。试用过程中，偶然发现页面跳转时每次都会请求几个lunr相关支持的js文件，搜索时，又会下载index.js文件。

对lunr支持的文件，还是比较大的；index.js就是文档索引内容了，这个文件和网站内容数量成正比。目前文章只有十多篇，index.js文件就有70kb。

随着文章的发布，index.js会不断增大，且每次点击搜索框进行搜索，都会下载此文件。内容不多的情况下，速度相较于algolia更快。~~（网络原因，即使选择官方最近的数据中心，还是略卡）~~

一番思索后，决定将lunr换成algolia（虽然因网络原因，目前lunr更快），原因：并非每次加载页面都需要搜索支持，而使用lunr总是会下载搜索相关支持文件，algolia就没有这个问题。

lunr每次搜索前、都会请求对lunr支持的js文件、及将要分析的索引文档（index.json）。也就是说，搜索功能本身及将要搜索的全部网站数据索引，都是一次性发送到客户端，在客户端浏览器上运行的。这种方式太过简单粗暴。

algolia则是将索引分析任务交给第三方服务器（algolia官方的），需要分析的索引文档，提前上传到algolia服务器，搜索时，客户端仅发送搜索的关键字、身份校验的一些信息。algolia分析本地索引文件，处理完成后将结果返回给客户端。

相对lunr，algolia少了向客户端发送搜索引擎功能文件（因为搜索在服务器做了，搜索功能本身可以做的更强大）、及索引文件。仅仅是搜索关键字、和处理结果的传输，就省了很大一笔网络开销，这也是它的高效之处。

algolia比lunr多了一次网络请求。一般公司里项目做搜索，搜索引擎服务器和业务服务器是通过内网链接，网络延迟很低很低。使用algolia的唯一痛点就在这了，即使选择algolia在国内的数据中心（香港），也还是有点延迟的。

每次发布新内容，如果手动上传索引文件到algolia，是相当麻烦的。 Algolia Atomic 是一个不错的选择。