Meilisearch 尋找 Rubygems

身為 Rails 和 Ruby 愛好者，我經常搜尋能夠完美涵蓋我的使用案例的 gem。當我需要解決問題時，我想要選擇正確的、最合適的解決方案。

Ruby gem 是在 Ruby 社群內部建立的廣泛程式庫。尋找任何任務的現成解決方案的最佳地點是網站 rubygems.org，這是一個公開的 gem 儲存庫，可以使用首頁上的搜尋框進行搜尋。RubyGems 的網站是一個有效的工具，可促進套件的共享和安裝。但是，儘管其搜尋列非常有幫助，我還是決定建立一個更適合我們需求的替代搜尋列。

即時搜尋體驗

首先，我想實作即時搜尋體驗。這表示

• 回應時間低於 50 毫秒
• 在使用者輸入時，立即在搜尋框下方顯示所有符合的結果，而無需他們按下 Enter 鍵

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。後者被視為最熱門的群組。

我將此資訊以 fame 為名稱的欄位新增至每個文件（即 gem）。然後，我將此規則整合到 Meilisearch 設定中作為自訂排名規則。

看看上面的程式碼片段。簡單來說，Meilisearch 會依序執行所有這些規則 (_sum_of_typos、_number_of_words...)，並依此順序排序您的文件。當我在 rankingOrder 中新增自訂規則，即 fame，並在 rankingRules 中新增 fame: 'dsc' 時，實際上是在要求 Meilisearch 依熱門程度遞減排序。

您可能已經注意到，我在範例中有第二個自訂規則：total_downloads，因此我的結果將依下載次數排序。但是，由於我選擇將此規則放在清單末尾，表示它被認為不如其他規則重要，因此它將是最後一個套用的規則。順序絕對很重要。

我不會進一步詳述 Meilisearch 預設的排名規則，即使這是一個特別有趣的主題。描述我們的搜尋引擎如何運作確實值得另寫一篇文章！😉 劇透一下：Meilisearch 使用的是桶排序！

現在，如果您輸入一個像「pagination」這樣的通用關鍵字，您會發現 Kaminari 排在第一位；如果您嘗試使用一個像「pagy」這樣較不知名的 gem 名稱再次搜尋，您仍然會得到您期望的 gem！🎉

Meilisearch + 你 = 💛

這些小設定很容易整合，而您的專案可能也需要類似的行為。

如果您想為自己的 Meilisearch 體驗做好準備，這裡有一些有用的連結：

• 文件
• GitHub 上Meilisearch 的儲存庫：請給它一個星星來支持 Meili！⭐️
• 這個專案的儲存庫

如果您對我們的專案、它的運作方式或有任何回饋感興趣，請隨時聯繫團隊！😁