概覽
自 2019 年 4 月起，目錄搜索功能已升級到 Elasticsearch。這項升級提供了許多優點，其中主要是提高相關性和準確性，並大幅提高性能 — 響應時間更加一致，通常是快兩倍。這項新功能會影響 CMS API、播放 API、Studio 互動式搜尋和目錄搜尋方法。
雖然 Brightcove 已經投入了大量的努力來使 Elasticsearch 結果一致，但存在差異，並且如果您編寫了搜索結果的特定依賴關係，則集成可能無法像預期那樣行事。
搜尋結果差異與影響
在研究潛在的影響時，Brightcove 發現，超過 90% 的搜索返回結果與返回的結果數量相匹配。這是一個指標，預期的結果不應該有足夠的不同，導致 API 集成的任何問題。
此圖表顯示完全符合兩個系統之間結果數量的搜尋結果數目，以及以紅色數字不同的搜尋結果數目。
作為我們推出的一部分，所有默認搜索和空字符串上的搜索已經由 Elasticsearch 提供了幾個月-因此用戶已經看到並使用 Elasticsearch 結果沒有問題。
然而，我們可以從這種比較中學到什麼是有限制的。充其量，我們只能推斷特定搜索的意圖，目錄數據是流動的。
已知的差異
下面的差異在很大程度上是基本的，或者在對搜索結果進行廣泛分析後達成的決策結果-它們是不可能完全消除的。
詞幹
詞幹提取是將變形（或有時派生）詞減少到它們的過程詞幹 , 基地或根形式——通常是書面文字形式。
一個在詞幹上操作的英語詞幹分析器貓應該確定這樣的字符串作為貓 , 貓似的和斤 .詞幹提取算法也可以減少單詞釣魚 , 釣魚和漁夫到莖魚 .詞幹不必是一個詞，例如波特算法減少爭論 , 爭論的 , 爭論 , 爭論和阿格斯到莖argu .
我們現有的搜索使用 Lancaster (Paice/Husk) 詞幹分析器，這種算法通常被認為過於激進——這導致缺乏區分，例如打火機和光在 Lancaster 下將被視為相同的術語。
Elasticsearch 使用了一種更新和更不具侵略性的算法（Porter2），它已經在行業中廣泛採用，並且通常被認為是一個顯著的改進（Lancaster 現在很少見）。詞幹分析器的變化可能會影響很大一部分（~35%）的搜索：這並不是說結果將要不同，只是他們可能有所不同——但總的來說，這應該會變得更好：也就是說，某些客戶子集可能會依賴於舊的行為。
相關性
我們現有的搜索似乎有更嚴格的 TF 規範化。這會導致在較大字段中找到的術語進行不同的相關性排序（即現有人認為匹配較不相關，因為它對術語的權重較小，因為它相對於文檔的長度較小）。
特殊字元
特殊字符在我們現有的搜索中被剝離，這幾乎等於剝離標點符號和相關字符-而不是剝離，我們通常在 Elasticsearch 中逃避它們，因此有可能搜索將其考慮在內。
術語處理
現有的搜索查詢執行“term smooshing”，而在 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"
這是一個改進，因為：
- 相關性：順序是正確的
- 精度：只有以「禁止」(「禁止」、「禁止」和「禁止」) 為主的影片才會退回。