Meilisearch v0.9:新功能?

我們剛剛發布了新版本,其開發的動力來自於我們對易用性的渴望。
我們意識到,由於設計上的選擇,某些功能不容易使用。整個團隊圍坐在桌旁,討論 API 路由及其 RESTful 性質,直到每個人都同意一個提案。我們希望在簡單性和自訂性之間取得良好的平衡。
那麼,v0.9 中有哪些新功能?
- 刪除結構描述!
- 包含網路介面來嘗試您的搜尋
- 新的設定處理
- 簡化的自訂排名規則
- 新增主鍵
- 新的內建排名規則名稱
- 簡化的驗證
- 生產和開發模式
- 錯誤修復、語法變更和改進
無結構描述
無結構描述的想法在我們心中醞釀了一段時間。在開始使用時,使用者不應被要求指定 Meilisearch 應如何處理每個欄位,而僅在他們的需求非常具體且與眾不同時才需要。
現在,預設情況下,Meilisearch 將顯示每個文件欄位,使它們都可搜尋,並根據提供的文件結構推斷文件的主鍵。
這個解決方案在開始使用 Meilisearch 時減少了許多摩擦。
網路介面
在先前的版本中,一旦您啟動了 Meilisearch 引擎並在其中插入了一些文件,流暢的體驗就到此為止了。為了嘗試搜尋,您必須使用 curl 或 SDK 提交請求,或者建立一個連接到 Meilisearch 的前端搜尋欄。
現在,Meilisearch 附帶了網路介面,您只需要開啟網頁瀏覽器並輸入 Meilisearch 的位址即可在本機訪問它。這將引導您進入一個包含搜尋欄的網頁,該搜尋欄可讓您在選定的索引中進行搜尋。
由於生產環境需要 API 金鑰才能進行搜尋,因此網路介面僅在開發模式下可用。
設定
現在可以在設定中配置任何使您的 Meilisearch 執行個體啟動並運作所不必要的項目。
對於每個設定都有一個路由,因此可以僅更新特定的設定。全域設定路由讓您可以發布一個描述您的自訂項的組態檔案,這將有助於建立基於相同設定的類似 Meilisearch 執行個體。
範例
{ "rankingRules": [ "typo", "words", "proximity", "attribute", "wordsPosition", "exactness", "desc(release_date)" ], "distinctAttribute": null, "searchableAttributes": [ "title", "description", "uid" ], "displayedAttributes": [ "title", "description", "release_date", "rank", "poster" ], "stopWords": null, "synonyms": { "wolverine": ["xmen", "logan"], "logan": ["wolverine", "xmen"] }, "indexNewFields": false }
簡化的自訂排名規則
在先前的版本中,建立自己的規則可能會令人困惑。我們簡化了這項任務!您現在要做的就是在排名規則列表中,針對您的其中一個欄位新增一個遞增 (asc()
) 或遞減 (desc()
) 規則。
"rankingRules": [ "typo", "words", "proximity", "attribute", "wordsPosition", "exactness", "desc(release_date)" ]
如果您按照此範例更新排名規則,您將注意到您的變更已立即被 Meilisearch 考慮在內。這表示一旦套用所有其他規則,Meilisearch 將認為具有較新 release_date 的文件比舊文件更相關。
主鍵
Meilisearch 將嘗試從您上傳的文件中推斷主鍵。此推斷將搜尋在其屬性中包含字串 id
的第一個欄位。
有時,可能會發生找不到任何金鑰的情況。在這種情況下,Meilisearch 無法推斷它。
由於 Meilisearch 需要主鍵來儲存文件,如果後者無法推斷,我們設定了兩種替代方法來將主鍵傳達給 Meilisearch。
- 在建立索引時給定它
{ "uid": "movies", "primaryKey": "movieUniqueName" }
- 在新增文件時給定它
curl -X POST 'https://127.0.0.1:7700/indexes/movies/documents?primaryKey=movieUniqueName' --data @movies.json
新的排名規則名稱
在先前的版本中,排名規則名稱太長,並且可能包含不必要的特殊字元。從現在開始,它們已得到簡化。以下是新的內建排名規則清單
typo
words
proximity
attribute
wordsPosition
exactness
簡化的驗證
當將主金鑰新增至 Meilisearch 時,會在啟動時產生私密金鑰和公開金鑰。
公開金鑰僅授予執行搜尋和取得文件的路由的權限。
私密金鑰授予對 Meilisearch 中除 GET /keys
路由以外的所有其他路由的存取權。由於它會傳回公開和私密金鑰,因此此路由只能使用主金鑰存取。
請閱讀此文章以了解有關 Meilisearch 中驗證的更多資訊.
生產和開發模式
在啟動 Meilisearch 執行個體時,現在可以使用設定環境的選項。
預設情況下,環境設定為開發模式。
在開發模式下,您不必提供主金鑰。在這種情況下,每個路由都可以存取,而無需任何 API 金鑰。您也可以存取網路介面。
在生產模式下,如果未提供主金鑰,則該執行個體將被認為不安全,無法用於生產,並且不會啟動。
錯誤修復、語法變更和改進
- 移除更新系統中的死鎖
- 即使在不知道主鍵的情況下,也可以新增設定
POST /documents/delete
變更為POST /documents/delete-batch
- 加速重新索引系統
- 如果在搜尋期間未提示任何醒目提示,則傳回的文件中將不會有
_highlighted
欄位 - 從搜尋查詢參數中移除
searchableAttributes
。 - 若要了解索引的統計資料,路由現在是:
GET /indexes/:index_uid/stats
而不是GET /stats/:index_uid
- 文件 ID 只能包含以下字元:
A-Z a-z 0-9
、-
和_
我們在路由設計上進行的一些調整是為了發布可用版本而採取的臨時選擇。例如,/key
路由雖然功能正常,但太簡單,不符合開發人員的常見需求。我們目前正在考慮如何更好地處理它,並樂於接受任何建議!
此版本花費了我們大約三個月的時間才完成,其中考慮到 v0.8.5 並未正式發布,而是新增到 v0.9 版本中。我們在流程組織方面做了大量工作,以確保所有內容都能同時就緒:核心 Meilisearch、文件和 SDK。
我們很高興這些最新的變更將如何改善使用者使用 Meilisearch 的體驗。此版本是我們的貢獻者和我們之間進行大量討論的結果。我們很期待聽到您使用 Meilisearch 的經驗。任何建議或回饋都非常歡迎,因為這些都是長期且雄心勃勃的專案的前提,該專案將基於我們今天做出的決策而建立。