Meilisearch 找到 Rubygems

作为一名 Rails 和 Ruby 爱好者，我经常寻找能够完美满足我用例的 gem。当我需要解决问题时，我希望选择最合适的、最称心的解决方案。

Ruby gems 是 Ruby 社区内部创建的广泛库。寻找任何任务现成解决方案的最佳地点是 rubygems.org 网站，这是一个公开的 gem 仓库，可以通过主页上的搜索框进行搜索。RubyGems 网站是一个高效的工具，便于软件包的分享和安装。尽管它的搜索栏非常有用，但我决定创建一个更符合我们需求的替代搜索栏。

实时搜索体验

首先，我想实现一种实时搜索体验。这意味着

• 响应时间低于 50 毫秒
• 用户输入时，无需按下回车键，即可在搜索框下方立即呈现所有匹配结果

这在 RubyGems 网站中尚未实现，因为每次发出请求都会加载新页面。

相关性

使用 RubyGems 的搜索栏可以获得相关且准确的结果，但大多数情况下只能通过执行高级搜索来实现，这并不总是方便。你必须决定在不同部分填写什么。你是打算通过输入名称（例如：“devise”）来搜索特定软件包，还是通过摘要匹配关键词（例如：“deployment”）来查找软件包？

然而，尽管有此功能，你可能仍然找不到满足你需求的 gem。例如，如果你输入“pagination”，你会期望在结果中看到 gem “kaminari”，这是 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 dump 文件的形式在 RubyGems 网站上提供，并每日更新。因此，我编写了一个 Ruby 脚本来下载最新的数据集，解析 PostgreSQL dump 文件，并将所有数据推送到我的 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 gems 的流行度通过下载量表示。我将我的 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 体验，这里有一些有用的链接

• 前往文档
• GitHub 上的 Meilisearch 仓库：通过点亮星标来支持 Meili！⭐️
• 这个项目的仓库

如果你对我们的项目感兴趣，想了解它的工作原理，或者有任何反馈，请随时联系团队！😁