Paper Contacter le support | état du système L'état du système

Catalogue Recherche Architecture

Dans cette rubrique, vous découvrirez l'architecture de la technologie de recherche de catalogue utilisée à la fois pour le CMS et Playback APIs.

Vue d'ensemble

Depuis avril 2019, la fonctionnalité de recherche dans le catalogue a été mise à niveau vers Elasticsearch. Cette mise à niveau offre un certain nombre d'avantages, notamment la pertinence et l'exactitude améliorées, ainsi que les performances considérablement améliorées: le temps de réponse est beaucoup plus homogène et en général deux fois plus rapide. Cette nouvelle fonctionnalité affectera le CMS API, Playback API, Studio de recherche interactive et les méthodes de recherche de catalogue.

Bien que Brightcove ait investi beaucoup d'efforts pour rendre les résultats Elasticsearch cohérents, il existe des différences, et il existe une petite possibilité que si vous avez codé des dépendances spécifiques sur les résultats de la recherche, votre intégration ne se comportera pas comme prévu.

Résultat de la recherche Différences et impact

En étudiant l'impact potentiel, Brightcove a constaté que plus de 90% des recherches renvoient des résultats qui correspondent en termes de nombre de résultats renvoyés. Il s'agit d'un indicateur indiquant que les résultats attendus ne devraient pas être suffisamment différents pour causer des problèmes avec les intégrations d'API.

Comparaison

Ce graphique indique le nombre de résultats de recherche correspondant exactement au nombre de résultats entre les deux systèmes en bleu et ceux dont le nombre diffère en rouge.

Dans le cadre de notre déploiement, toutes les recherches par défaut, les recherches sur la chaîne vide, sont déjà fournies par Elasticsearch depuis plusieurs mois. Les utilisateurs voient et utilisent déjà les résultats Elasticsearch sans problèmes.

Il y a cependant des limites à ce que nous pouvons apprendre de ce type de comparaison. Au mieux, nous ne pouvons que déduire l'intention d'une recherche particulière et les données du catalogue sont fluides.

Différences connues

Les différences ci-dessous sont en grande partie fondamentales, ou résultent de décisions prises après une analyse approfondie des résultats de la recherche - elles sont impossibles à éliminer complètement.

Stemming

Stemming est le processus de réduction des mots infléchis (ou parfois dérivés) à leur tige de mot, base ou racine forme - généralement une forme écrite.

Un stemmer pour l'anglais opérant sur la tige cat devrait identifier ces instruments à cordes as chats, comme un chat et méchant. Un algorithme dérivé peut également réduire les mots pêche, pêché et pêcheur à la tige poisson. La tige ne doit pas nécessairement être un mot, par exemple l'algorithme de Porter réduit argumenter, argumenté, soutient, argumentant et argus à la tige argu.

Notre recherche existante utilise le stemmer de Lancaster (Paice / Husk), cet algorithme est généralement considéré comme trop agressif - cela entraîne un manque de distinction, par exemple plus léger et lumière serait considéré comme le même terme sous Lancaster.

Elasticsearch utilise un algorithme plus récent et beaucoup moins agressif (Porter2) qui a été largement adopté dans l'industrie et qui est généralement considéré comme une amélioration significative (Lancaster est maintenant rare). Le changement de radical influence potentiellement une proportion importante (~ 35%) de recherches: cela ne veut pas dire que les résultats aura être différent, juste qu'ils pourrait être différent - mais en général cela devrait être pour le mieux: cela dit, certains sous-ensembles de clients peuvent être dépendants de l'ancien comportement.

Pertinence

Notre recherche existante semble avoir une normalisation plus stricte de la TF. Cela entraîne un type de pertinence différent pour les termes trouvés dans des champs plus grands (c’est-à-dire que la correspondance considère que la correspondance est moins pertinente car elle donne moins de poids au terme car elle est plus petite par rapport à la longueur du document).

Caractères spéciaux

Les caractères spéciaux sont supprimés dans notre recherche existante. Cela équivaut à supprimer les signes de ponctuation et les caractères associés. Au lieu de supprimer, nous les échappons généralement dans Elasticsearch. Il est donc possible qu'une recherche les prenne en compte.

Traitement des termes

Les requêtes de recherche existantes exécutent `term smooshing` alors que dans Elasticsearch, nous supprimons les termes mal formés, considérons cette recherche avec un caractère vide. tags: terme: q=tags: state:ACTIVE

  • Existant: tags:state:ACTIVE - rechercher des vidéos avec un tag de state:ACTIVE
  • ElasticSearch: state:ACTIVE - Laisse tomber le terme vide

Il existe un certain nombre de cas délicats liés à la gestion de la ponctuation non résolue et aux requêtes généralement mal formées. Nous essayons de produire ce que nous pensons que la requête était destinée à être, mais dans ces cas, nous devinons malheureusement ce que l'utilisateur aurait pu vouloir ( quand vraiment nous aurions dû renvoyer une erreur leur permettant d'affiner leur recherche)

Jouable seulement

Il existe deux mécanismes pour limiter une recherche aux vidéos actuellement lisibles: la requête peut inclure un indicateur ou la requête elle-même peut nécessiter un aspect de la jouabilité.

  • Existant: il est interrogé en fonction de la valeur d'un champ mis à jour
  • Elasticsearch: cette question est interrogée sur la base de plages de dates calculées

Elasticsearch devrait généralement être plus précis et produire de meilleurs résultats (un décalage est associé au mécanisme existant et le mécanisme de maintenance des indicateurs n'est pas entièrement fiable).

Précision de l'index

L’indice Elasticsearch est plus «frais» que l’index existant et a tendance à refléter les mises à jour plus rapidement - ce n’est pas toujours le cas, mais en général, l’expérience Elasticsearch montre que les résultats reflètent plus précisément l’état des données de catalogue sous-jacentes. Les systèmes existants et Elasticsearch sont des systèmes distribués et ne sont donc pas entièrement cohérents dans les résultats renvoyés: une requête répétée sur l'un ou l'autre système peut potentiellement renvoyer des résultats différents (notamment dans le cas où plusieurs opérations de suppression s'exécutent simultanément).

Les résultats de recherche existants changent en fonction de l'état du fragment auquel un compte est affecté. L'état global d'un fragment particulier peut (et a) une incidence sur les résultats d'une requête particulière: Elasticsearch ne présente pas ce problème.

Exemples

Exemple 1

Disons qu'il y a deux vidéos avec les titres suivants:

      Video#1: has the title “Don’t look into the light”
      Video#2: has the title “Using a lighter to make a campfire”

L'utilisateur souhaite renvoyer toutes les vidéos qui doivent comporter le mot «light». En utilisant le CMS API, la requête ressemblerait à ceci:

      q=%2Blight or q=+light

Avec la recherche existante, les deux vidéos seront retournées dans l'ordre:

      Video#2 - “Using a lighter to make a campfire”
      Video#1 - “Don’t look into the light”

Il y a deux problèmes avec ceci:

  • Pertinence: La commande est incorrecte. "Ne regardez pas dans la lumière" (Vidéo n ° 2) devrait apparaître avant "Utiliser un briquet pour faire un feu de camp" (Vidéo n ° 1)
  • Précision: "Utiliser un briquet pour faire un feu de camp" ne devrait même pas apparaître dans le jeu de résultats car le mot "light" n'apparaît pas du tout dans le titre de la vidéo.

Avec Elasticsearch, ceci ne renverra qu'une vidéo:

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

C'est une amélioration parce que:

  • Pertinence: la commande est correcte.
  • Précision: seule la vidéo 1 est renvoyée car il s'agit de la seule vidéo contenant le mot «lumière» dans le titre.

Exemple 2

Comme décrit dans notre CMS API documentation pour stemming, la prise en charge est prise en charge, mais pas la recherche de mots partielle. Alors disons qu'il existe des vidéos 5 avec les titres suivants:

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

L'utilisateur souhaite renvoyer toutes les vidéos qui doivent avoir le mot interdire dans le champ du nom. En utilisant le CMS API, la requête ressemblerait à ceci:

      q=%2Bname%3Aban or q=+name:ban

On s’attend à ce que «Interdiction», «Interdiction» et «Interdit» produisent des résultats de recherche, car «Interdiction» fait partie intégrante des trois.

Cependant, avec le système de recherche actuel, les cinq vidéos seront renvoyées dans cet ordre:

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

Là encore, il y a deux problèmes:

  • Pertinence: la commande est incorrecte. "Interdiction de stationnement annoncée" devrait être la première vidéo renvoyée car elle contient le mot "Interdiction".
  • Précision: "Jour férié" et "Bandit capturé" ne doivent absolument pas être renvoyés car "Interdiction" ne fait pas partie du mot "Banque" ou "Bandit".

Avec Elasticsearch, les résultats sont les suivants:

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

C'est une amélioration parce que:

  • Pertinence: la commande est correcte.
  • Précision: Seules les vidéos contenant le mot «Ban» («Ban», «Interdiction» et «Interdit») sont renvoyées.

Dernière mise à jour de la page le 12 juin 2020