サポート サポートへのお問い合わせ | システムステータス システムステータス
ページコンテンツ

    カタログ検索アーキテクチャ

    このトピックでは、CMSAPIとPlaybackAPIの両方で使用されるカタログ検索テクノロジのアーキテクチャについて学習します。

    概要

    2019年4月の時点で、カタログ検索機能がElasticsearchにアップグレードされました。このアップグレードには多くの利点がありますが、その主なものは、関連性と精度の向上、およびパフォーマンスの劇的な向上です。応答時間ははるかに一貫性があり、通常は2倍高速です。この新機能は、CMS API、Playback API、Studioインタラクティブ検索、およびカタログ検索方法に影響します。

    Brightcoveは、Elasticsearchの結果の一貫性を保つために多大な労力を費やしてきましたが、違いがあり、検索結果に対する特定の依存関係をコーディングした場合、統合が期待どおりに動作しない可能性があります。

    検索結果の違いと影響

    潜在的な影響を調査したところ、Brightcoveは、検索の90%以上が、返される結果の数に関して一致する結果を返すことを発見しました。これは、期待される結果がAPI統合で問題を引き起こすほど異なってはならないことを示しています。

    比較

    このグラフは、2つのシステム間の結果の数と正確に一致する検索結果の数を青で示し、数が異なる検索結果の数を赤で示しています。

    ロールアウトの一環として、すべてのデフォルト検索、つまり空の文字列での検索は、Elasticsearchによってすでに数か月間提供されているため、ユーザーはすでにElasticsearchの結果を問題なく表示および使用しています。

    ただし、この種の比較から学べることには限界があります。せいぜい、特定の検索の意図しか推測できず、カタログデータは流動的です。

    既知の違い

    以下の違いは主に基本的なものであり、検索結果を徹底的に分析した後に到達した決定の結果であり、完全に排除することは不可能です。

    ステミング

    ステミング屈折した(または時には派生した)単語をそれらに減らすプロセスです語幹、ベースまたはルートフォーム—一般的に書かれた単語フォーム。

    語幹を操作する英語の語幹ネコそのようなものを特定する必要があります文字列なので catlikeそしてキャティ。ステミングアルゴリズムも単語を減らす可能性があります釣り釣りそしてフィッシャー茎に。語幹は単語である必要はありません。たとえば、ポーターアルゴリズムは主張する主張した主張する主張するそしてアーガス茎にargu

    私たちの既存の検索では、ランカスター(Paice / Husk)ステマーを使用しています。このアルゴリズムは、一般に過度に攻撃的であると見なされています。たとえば、区別が不足しています。ライターそしてランカスターでは同じ用語と見なされます。

    Elasticsearchは、業界で広く採用され、一般的に大幅な改善と見なされている、より最近の攻撃性の低いアルゴリズム(Porter2)を使用しています(Lancasterは現在まれです)。ステマーの変更は、検索のかなりの割合(〜35%)に影響を与える可能性があります。つまり、結果が意志違います、ただ彼らがかもしれない異なる—しかし、一般的には、これはより良いはずです。とはいえ、一部の顧客は古い動作に依存している可能性があります。

    関連性

    私たちの既存の検索では、より厳密なTF正規化が行われているようです。これにより、より大きなフィールドで見つかった用語の関連性の並べ替えが異なります(つまり、ドキュメントの長さに比べて用語の重みが小さいため、既存の一致では関連性が低いと見なされます)。

    特殊文字

    特殊文字は既存の検索内で削除されます。これは句読点や関連文字を削除することとほぼ同じです。通常、Elasticsearchでは削除する代わりにエスケープするため、検索でそれらが考慮される可能性があります。

    タームハンドリング

    既存の検索クエリは `term smooshing`を実行しますが、Elasticsearchでは不正な形式の用語を削除します。この検索は空であると考えてください。tags:期間:q=tags: state:ACTIVE

    • 既存tags:state:ACTIVE—タグが付いた動画を検索するstate:ACTIVE
    • Elasticsearchstate:ACTIVE—空の用語を削除します

    ぶら下がっている句読点や一般的に不正なクエリの処理に関連する微妙なエッジケースがいくつかあり、クエリが意図したものと思われるものを生成しようとしますが、残念ながら、ユーザーが意図したものを推測しています(本当にエラーを返して、検索を絞り込む必要がある場合)

    再生可能のみ

    現在再生可能な動画に検索を制限するには、2つのメカニズムがあります。クエリにフラグを含めるか、クエリ自体に再生可能性の何らかの側面を要求することができます。

    • 既存:これは、更新されたフィールドの値に基づいて照会されます
    • Elasticsearch:これは計算された日付範囲に基づいて照会されます

    Elasticsearchは通常、より正確でより良い結果を生成するはずです(既存のメカニズムに関連するラグがあり、フラグのメンテナンスメカニズムは完全に信頼できるわけではありません)。

    インデックスの精度

    Elasticsearchインデックスは既存のインデックスよりも「新鮮」であり、更新をより速く反映する傾向があります。これは常に当てはまるわけではありませんが、Elasticsearchの一般的な経験では、結果は基になるカタログデータの状態をより正確に反映します。既存のシステムとElasticsearchはどちらも分散システムであるため、返される結果が完全に一貫しているわけではありません。どちらのシステムに対してもクエリを繰り返すと、異なる結果が返される可能性があります(特に、同時に実行される削除操作が多数ある場合)。

    アカウントが割り当てられているシャードの状態に基づいて、既存の検索結果が変化します。特定のシャードのグローバル状態は、特定のクエリの結果に影響を与える可能性があります(実際に影響します)。Elasticsearchにはこの欠点はありません。

    例1

    次のタイトルの2つのビデオがあるとしましょう。

          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つの問題があります。

    • 関連性:順序が正しくありません。「ライトを覗くな」(動画 #2) が「ライターを使ってキャンプファイヤーを作る」(動画 #1) の前に表示されるはずです
    • 正確さ:ビデオタイトルに「ライト」という言葉がまったく表示されないため、「ライターを使ってキャンプファイヤーを作る」は結果セットにも表示されません。

    Elasticsearchでは、これはビデオ1つのみを返します。

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

    これは次の理由による改善です。

    • 関連性:順序は正しいです。
    • 正確さ:タイトルに「light」という単語が含まれている唯一のビデオであるため、ビデオ1のみが返されます。

    例2

    私たちのステミング用のCMSAPIドキュメント、ステミングはサポートされていますが、部分的な単語検索はサポートされていません。したがって、次のタイトルのビデオが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

    期待は、「Ban」、「Baning」、「Baning」、「Baned」の3つすべての語幹として検索結果を出すことです。

    ただし、現在の検索システムでは、5 つの動画がすべて次の順序で返されます。

          Video#2 - "Parking to be Banned"
          Video#3 - "City Banning Parking"
          Video#1 - "Parking Ban Announced"
          Video#4 - "Bank Holiday"
          Video#5 - "Bandit Captured"

    繰り返しますが、これには2つの問題があります。

    • 関連性:順序が正しくありません。「駐車禁止発表」は、「禁止」という言葉が含まれているため、最初に返された動画でなければなりません。
    • 正確さ:「Bank Holiday」と「Bandit Captured」は「Bank」や「Bandit」という言葉の一部ではないため、「Bank Holiday」と「Bandit Captured」は全く返すべきではありません。

    Elasticsearchを使用すると、結果は次のようになります。

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

    これは次の理由による改善です。

    • 関連性:順序は正しいです。
    • 正確さ:「Ban」(「禁止」、「禁止」、「禁止」)という語幹を持つ動画のみが返されます。