Meilisearch 发现 Rubygems

作为一名Rails和Ruby爱好者,我经常寻找能完美满足我用例的gem。当我需要解决一个问题时,我希望选择“正确”的、最合适的解决方案。
Ruby gem是Ruby社区中创建的广泛库。查找任何任务的现成解决方案的最佳地点是rubygems.org网站,这是一个可以通过主页上的搜索框进行搜索的gem公共仓库。RubyGems网站是一个高效的工具,方便了软件包的共享和安装。但是,尽管它的搜索栏非常有用,我还是决定创建一个更适合我们需求的替代搜索栏。
即时搜索体验
首先,我想实现即时搜索体验。这意味着:
- 响应时间低于50毫秒
- 用户在输入时无需按回车键即可在搜索框下方立即显示所有匹配结果
RubyGems网站目前还没有实现这一点,因为每次请求都会加载一个新页面。
相关性
您可以使用RubyGems的搜索栏获得相关且准确的结果,但大多数时候只有通过高级搜索才能实现,这并不总是方便。您必须决定在不同部分填写什么。您是要通过输入其名称(例如“devise”)来搜索特定软件包,还是通过其摘要匹配关键字(例如“deployment”)来查找软件包?
然而,尽管有此功能,您可能仍无法找到符合您需求的gem。例如,如果您输入“pagination”,您会期望在结果中看到“kaminari”gem,它是RoR社区中最流行的分页gem。以下是当我们提交关键字“pagination”时,RubyGem搜索栏返回的结果。如您所见,“kaminari”直到第9个结果才出现。
即使细化搜索,第一个显示的结果也是“kanimari-core”,这并不是我们希望找到的更合适、更著名的“kaminari”包,但总比没有好。
如果我们进行包含拼写错误的请求,例如“pagintion”,页面将显示为无结果,并建议您下一次搜索使用类似的词语。
作为用户体验了这些之后,我的目标是创建一个能够理解您需求并即时找到结果的单一搜索栏!
Meilisearch满足所有这些要求,甚至更多!
我从未实现过搜索引擎;我甚至从未用过,除了一个没有配置的基本Elasticsearch实例用于概念验证。因此,我需要的是一个易于设置的工具,能够同时处理速度和相关性。这就是Meilisearch非常适合这个项目的原因。
Meilisearch是一个超相关且快速的搜索引擎。换句话说,它可以在50毫秒内返回数据集中最相关的结果,从而给人一种强烈的即时感。
此外,无需任何配置,它就能处理搜索中的拼写错误:即错别字。尝试提交“devose”而不是“devise”,Meilisearch将返回“devise”作为第一个结果。
最后,Meilisearch是开源的,并集成了简单的RESTful API。您可以使用cURL或Meilisearch的包装器之一与API无缝通信。
创建替代搜索栏
所有gem数据都以PostgreSQL转储文件的形式在RubyGems网站上提供,并每日更新。因此,我编写了一个Ruby脚本来下载最新数据集,解析PostgreSQL转储文件,并将所有数据推送到我的Meilisearch实例。当然,它使用meilisearch-ruby包装器与API通信。该脚本托管在Heroku上,并每天通过Heroku Scheduler运行。
关于Meilisearch实例,我们在Meili管理着一个内部Kubernetes集群,这是一个方便的工具,可以托管像这样的演示。对于好奇的读者,如果想了解更多,Meilisearch本身下载和运行起来相当容易(Homebrew、APT、Docker等)。
在HTML和CSS方面,我保留了RubyGems网站的原始结构。我的目的是以与原始网站相同的精神开发“即时搜索体验”。前端使用GitHub Pages部署。
轻松提高相关性
无需任何设置,Meilisearch就能返回相当相关的结果。当输入“devise”或“faraday”等gem名称时,我们的搜索引擎可以快速找到最合适的软件包。不幸的是,目前对于关键字来说并非总是如此。
我们回到我的“pagination”示例。如果我在不配置任何东西的情况下再次运行搜索,Meilisearch显示的第一结果将是Pagination gem。我在结果中根本没有看到Kaminari。那是因为默认情况下,查找标题中包含请求词的文档优先于描述中包含请求词的文档。由于数据集中有许多gem的标题中包含“pagination”,这就解释了为什么Kaminari根本没有出现。
我需要Meilisearch也包含库的受欢迎程度。在我的数据集中,Ruby gem的受欢迎程度由下载次数表示。我将我的gem分为八个流行度组(下载次数超过5000万次、超过3000万次等等),从0
到7
。后者被认为是最著名的组。
我将此信息作为名为fame
的字段添加到每个文档(即gem)中。然后,我将此规则集成到Meilisearch设置中,作为自定义排序规则。
看看上面的代码片段。简而言之,Meilisearch将逐一执行所有这些规则(_sum_of_typos
、_number_of_words
...),并按此顺序对文档进行排序。当我添加我的自定义规则,即在rankingOrder
中添加fame
并在rankingRules
中添加fame: 'dsc'
时,我实际上是要求Meilisearch按受欢迎程度降序排序。
您可能已经注意到,我在示例中还有第二个自定义规则:total_downloads
,这样我的结果将按下载次数排序。但是由于我选择将此规则放在列表的末尾,这意味着它被认为不如其他规则重要,因此它将是最后一个应用的规则。顺序确实很重要。
我不会再详细介绍Meilisearch的默认排名规则,尽管这是一个特别有趣的话题。描述我们的搜索引擎如何工作确实值得单独写一篇文章!😉 剧透:Meilisearch使用的是桶排序!
现在,如果您输入一个全局关键字,如“pagination”,您将首先找到Kaminari;如果您尝试使用一个不太著名的gem名称,例如“pagy”,您仍然会得到您期望的gem!🎉
Meilisearch + 您 = 💛
这些微小的设置非常容易集成,您的项目可能也需要类似的行为。
如果您想准备好自己的Meilisearch体验,这里有一些有用的链接:
- 文档
- Meilisearch在GitHub上的仓库:通过点赞支持Meili!⭐️
- 该项目仓库
如果您对我们的项目、它的运作方式感兴趣,或者您有任何反馈,请随时联系团队!😁