支持 聯繫支持 | 系統狀況 系統狀態

目錄搜索架構

在本主題中,您將了解用於CMS和CMS的目錄搜索技術的體系結構。 Playback APIs.

概述

自2019年XNUMX月起,目錄搜索功能已升級到Elasticsearch。 此次升級提供了許多好處,其中最主要的好處是改進了相關性和準確性,並顯著改善了性能-響應時間更加一致,通常快一倍。 這項新功能將影響 CMS API, Playback API,Studio交互式搜索和目錄搜索方法。

儘管Brightcove為使Elasticsearch結果保持一致付出了巨大的努力,但還是存在差異,並且,如果您對搜索結果的特定依賴關係進行編碼,則集成的可能性可能很小,這很小的可能性是很小的。

搜索結果的差異和影響

在研究潛在影響時,Brightcove發現超過90%的搜索返回的結果與返回的結果數相匹配。 這表明預期結果應該相差不大,不會導致API集成出現任何問題。

對照

此圖以藍色顯示兩個系統之間的結果數量完全匹配的搜索結果數量,以紅色顯示數量上完全不同的搜索結果數量。

作為我們推出的一部分,Elasticsearch已經提供了幾個月的所有默認搜索,即對空字符串的搜索,因此用戶已經可以毫無問題地查看和使用Elasticsearch結果。

但是,我們從這種比較中學到的東西是有限的。 充其量,我們只能推斷出特定搜索的意圖,並且目錄數據是可變的。

已知差異

以下差異在很大程度上是基本差異,或者是在對搜索結果進行廣泛分析後得出的決策結果-無法完全消除。

詞幹

詞幹 是將變形的(或有時衍生的)單詞減少為它們的過程 詞幹,基數或 形式-通常是書面形式。

詞幹,英語為詞幹 應該指出 字符串 as , 像貓一樣。 詞幹算法也可以減少單詞 釣魚, 釣魚的費舍爾 到莖 。 詞根不必是一個詞,例如Porter算法可以減少 爭論, 爭論, 認為, 爭論烏鱧 到莖 阿古.

我們現有的搜索使用Lancaster(Paice / Husk)詞幹分析器,該算法通常被認為過於激進-例如,這導致缺乏區別 打火機 在蘭開斯特(Lancaster)下將被視為同一術語。

Elasticsearch使用的是一種更新較新且較不積極的算法(Porter2),該算法已在業界得到廣泛採用,通常被認為是一項重大改進(Lancaster現在很少見)。 詞幹的變化可能會影響搜索的很大一部分(約35%):這並不是說結果 有所不同,只是他們 可能 有所不同-但總的來說應該會更好:也就是說,某些客戶子集可能依賴於舊的行為。

相關性

我們現有的搜索似乎具有更嚴格的TF規範化。 這會導致在較大字段中找到的術語具有不同的相關性排序(即,現有方法認為匹配項的相關性較低,因為它相對於文檔的長度較小,因此賦予該術語的權重較小)。

特殊字符

特殊字符在我們現有的搜索中被剝離,這幾乎等同於剝離標點符號和相關字符-而不是剝離,我們通常在Elasticsearch中對它們進行轉義,因此搜索有可能會將它們考慮在內。

術語處理

現有的搜索查詢會執行“術語欺騙”,而在Elasticsearch中,我們刪除格式錯誤的術語,請將此搜索考慮為空 tags: 術語: q=tags: state:ACTIVE

  • 現有: tags:state:ACTIVE —搜索帶有標記的視頻 state:ACTIVE
  • Elasticsearch: state:ACTIVE —刪除空詞

有許多與處理懸掛標點和查詢有關的微妙情況,它們通常是畸形的,我們嘗試產生我們認為查詢的意圖,但是不幸的是,在這些情況下,我們正在猜測用戶可能的意圖(實際上,我們應該返回一個錯誤,允許他們優化搜索範圍)

只能播放

有兩種將搜索限制為當前可播放的視頻的機制:查詢可以包含標誌,或者查詢本身可能需要可播放性的某些方面。

  • 現有:根據更新的字段的值查詢
  • Elasticsearch:這是根據計算的日期範圍查詢的

Elasticsearch通常應該更準確並產生更好的結果(與現有機制相關聯存在滯後,並且標記維護機制並不完全可靠)。

索引準確度

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”

用戶希望返回所有必須帶有單詞“ light”的視頻。 使用 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)
  • 準確性:“使用打火機做篝火”甚至不應該出現在結果集中,因為視頻標題中根本沒有出現“ light”一詞。

使用Elasticsearch,這只會返回一個視頻:

      Video#1 - “Don’t look into the light”

這是一個改進,因為:

  • 相關性:順序正確。
  • 準確性:僅返回一個視頻,因為它是標題中唯一帶有“ 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"

同樣,這有兩個問題:

  • 相關性:訂單不正確。 返回的第一個視頻應為“已宣布停車禁令”,因為其中帶有“禁令”字樣。
  • 準確性:完全不應返回“銀行假期”和“被搶匪”,因為“銀行”不是“銀行”或“匪徒”一詞的一部分。

使用Elasticsearch時,結果如下所示:

      Video#1 - "Parking Ban Announced"
      Video#2 - "Parking to be Banned"
      Video#3 - "City Banning Parking"

這是一個改進,因為:

  • 相關性:順序正確。
  • 準確性:僅返回帶有單詞“ Ban”(“ Ban”,“ Banning”和“ Banned”)詞幹的視頻。

頁面最後更新於12年2020月XNUMX日