Meilisearch 发现 Rubygems

作为 Rails 和 Ruby 的爱好者，我经常搜索能够完美满足我的用例的 gem 包。当需要解决问题时，我希望选择正确的，最合适的解决方案。

Ruby gem 包是在 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 包数据 都在 RubyGems 的网站上以 PostgreSQL 转储文件的形式提供，并且每天更新。因此，我编写了一个 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 包分为八个知名度组（下载次数超过 5 千万次、超过 3 千万次等等），从 0 到 7。后者被认为是知名度最高的组。

我将此信息添加到每个文档（即 gem 包）中，作为一个名为 fame 的字段。然后，我将此规则集成到 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！⭐️
• 此项目的仓库

如果您对我们的项目、其工作原理或您有任何反馈感兴趣，请随时 联系团队！😁