目錄搜尋架構
概覽
截至 2019 年 4 月，目錄搜索功能已升級為彈性搜索。這項升級提供了許多優點，其中主要是提高相關性和準確性，並大幅提高性能 — 響應時間更加一致，通常是快兩倍。這項新功能會影響 CMS API、播放 API、Studio 互動式搜尋和目錄搜尋方法。
雖然 Brightcove 已經投入了大量的努力來使 Elasticsearch 結果一致，但存在差異，並且如果您編寫了搜索結果的特定依賴關係，則集成可能無法像預期那樣行事。
搜尋結果差異與影響
在研究潛在的影響時，Brightcove 發現，超過 90% 的搜索返回結果與返回的結果數量相匹配。這是一個指標，預期的結果不應該有足夠的不同，導致 API 集成的任何問題。
此圖表顯示完全符合兩個系統之間結果數量的搜尋結果數目，以及以紅色數字不同的搜尋結果數目。
作為我們推出的一部分，所有默認搜索和空字符串上的搜索已經由 Elasticsearch 提供了幾個月-因此用戶已經看到並使用 Elasticsearch 結果沒有問題。
然而，我們可以從這種比較中學到什麼是有限制的。充其量，我們只能推斷特定搜索的意圖，目錄數據是流動的。
已知的差異
下面的差異在很大程度上是基本的，或者在對搜索結果進行廣泛分析後達成的決策結果-它們是不可能完全消除的。
詞幹
詞幹是將轉折（或有時衍生的）單詞減少為詞幹，基礎或根形式的過程-通常是書面單詞形式。
一個在詞幹上操作的英語詞幹分析器貓應該確定這樣的字符串作為貓 , 貓似的和斤 .詞幹提取算法也可以減少單詞釣魚 , 釣魚和漁夫到莖魚 .詞幹不必是一個詞，例如波特算法減少爭論 , 爭論的 , 爭論 , 爭論和阿格斯到莖argu .
我們現有的搜索使用蘭開斯特（Pa/Husk）詞幹器，這種算法通常被認為是過於侵略性-這導致缺乏區分，例如，在蘭開斯特下更輕和輕 將被視為同一個術語。
Elasticsearch 使用了一種更新和更不具侵略性的算法（Porter2），它已經在行業中廣泛採用，並且通常被認為是一個顯著的改進（Lancaster 現在很少見）。詞幹器的變化可能會影響搜索的顯著（〜 35％）比例：這並不是說結果會有所不同，只是它們可能會有所不同-但總的來說，這應該更好：也就是說，客戶可能依賴於舊的行為。
相關性
我們現有的搜索似乎有更嚴格的 TF 規範化。這會導致在較大字段中找到的術語進行不同的相關性排序（即現有人認為匹配較不相關，因為它對術語的權重較小，因為它相對於文檔的長度較小）。
特殊字元
特殊字符在我們現有的搜索中被剝離，這幾乎等於剝離標點符號和相關字符-而不是剝離，我們通常在 Elasticsearch 中逃避它們，因此有可能搜索將其考慮在內。
術語處理
現有的搜索查詢執行「術語平滑化」，而在 Elasticsearch 中，我們刪除格式錯誤的術語，請考慮使用空tags:詞搜索：q=tags: state:ACTIVE
- 現有：
tags:state:ACTIVE— 搜尋標籤為state:ACTIVE - 彈性搜索：
state:ACTIVE-刪除空詞
有許多與處理懸掛的標點符號和查詢有關的細微邊緣情況，這些情況通常是格式錯誤，我們試圖產生我們認為查詢的意圖，但在這些情況下，我們不幸地猜測用戶可能的意圖（當我們真的應該返回一個錯誤允許他們細化他們的搜索）
僅可播放
有兩種機制可將搜尋限制為目前可播放的視訊：查詢可以包含旗標，或者查詢本身可能需要某些方面的可玩性。
- 現有：這是根據已更新的欄位值來查詢
- 彈性搜索：這是基於計算的日期範圍查詢
Elasticsearch 通常應該更準確，並產生更好的結果（存在與現有機制相關聯的滯後，標誌維護機制不完全可靠）。
指數準確度
Elasticsearch 索引比現有索引更新「更新」，並傾向於更快地反映更新-情況並非總是如此，但通常情況下，Elasticsearch 的經驗是結果將更準確地反映底層目錄數據的狀態。現有和 Elasticsearch 都是分佈式系統，因此在它們返回的結果中並不完全一致：對任何一個系統的重複查詢可能會返回不同的結果（特別是在同時運行刪除操作的情況下）。
現有的搜尋結果會根據帳號配置給的分片狀態而變更 — 特定分片的全域狀態可以 (且會) 影響任何特定查詢的結果：彈性搜索沒有這個缺陷。
範例
範例 1
假設有兩個具有以下標題的視頻：
Video#1: has the title “Don’t look into the light”
Video#2: has the title “Using a lighter to make a campfire”
用戶希望返回必須有「光」一詞的所有視頻。使用 CMS API，查詢將如下所示：
q=%2Blight or q=+light
使用現有的搜索，這將按順序返回兩個視頻：
Video#2 - “Using a lighter to make a campfire”
Video#1 - “Don’t look into the light”
這有兩個問題：
- 相關性：訂單不正確「不要看光」(影片 #2) 應該會出現在「用打火機製造營火」之前 (影片 #1)
- 精度：「使用更輕的營火」甚至不應該出現在結果集中，因為影片標題中根本不會出現「光」一詞。
使用彈性搜索，這將只返回一個視頻：
Video#1 - “Don’t look into the light”
這是一個改進，因為：
- 相關性：順序是正確的
- 精度：只有一個視頻被返回，因為它是標題中唯一帶有「光」字的視頻。
範例 2
如我們的描述用於阻止的CMS API文檔，支持詞幹搜索，但不支持部分單詞搜索。因此，假設有 5 個具有以下標題的視頻：
Video#1 - "Parking Ban Announced"
Video#2 - "Parking to be Banned"
Video#3 - "City Banning Parking"
Video#4 - "Bank Holiday"
Video#5 - "Bandit Captured"
使用者希望傳回名稱欄位中必須有禁止字詞的所有視訊。使用 CMS API，查詢將如下所示：
q=%2Bname%3Aban or q=+name:ban
我們期望「禁止」、「禁止」和「禁止」會產生搜尋結果，因為「禁令」是三者之一。
但是，使用目前的搜尋系統，這會以下列順序傳回所有五個視訊：
Video#2 - "Parking to be Banned"
Video#3 - "City Banning Parking"
Video#1 - "Parking Ban Announced"
Video#4 - "Bank Holiday"
Video#5 - "Bandit Captured"
同樣，這有兩個問題：
- 相關性：訂單不正確「禁止停車場宣布」應該是第一個回來的視頻，因為它有「禁止」這個詞。
- 精度：「銀行假期」和「強盜俘虜」不應歸還，因為「禁令」不是「銀行」或「強盜」一詞的一部分。
使用彈性搜索，結果如下所示：
Video#1 - "Parking Ban Announced"
Video#2 - "Parking to be Banned"
Video#3 - "City Banning Parking"
這是一個改進，因為：
- 相關性：順序是正確的
- 精度：只有以「禁止」(「禁止」、「禁止」和「禁止」) 為主的影片才會退回。