soporte Contactar con asistencia técnica | estado del sistema Estado del Sistema

Arquitectura de búsqueda de catálogo

En este tema, aprenderá sobre la arquitectura de la tecnología de búsqueda de catálogo utilizada tanto para el CMS como para Playback APIs.

Resumen

A partir de abril 2019, la funcionalidad de búsqueda en el catálogo se actualizó a Elasticsearch. Esta actualización proporciona una serie de beneficios, entre los que se destacan la relevancia y la precisión, y el rendimiento mejorado dramáticamente. El tiempo de respuesta es mucho más consistente y generalmente el doble de rápido. Esta nueva funcionalidad afectará a la CMS API, Playback API, Estudio de búsqueda interactiva y los métodos de búsqueda por catálogo.

Si bien Brightcove ha invertido una gran cantidad de esfuerzo para hacer que los resultados de Elasticsearch sean consistentes, existen diferencias, y existe una pequeña posibilidad de que si ha codificado dependencias específicas en los resultados de búsqueda, su integración no se comporte como se esperaba.

Diferencias de Resultados de Búsqueda e Impacto

Al estudiar el impacto potencial, Brightcove descubrió que más del 90% de las búsquedas arrojan resultados que coinciden en términos de la cantidad de resultados devueltos. Este es un indicador de que los resultados esperados no deberían ser lo suficientemente diferentes como para causar problemas con las integraciones de API.

comparación

Este gráfico muestra el número de resultados de búsqueda que coinciden exactamente con el número de resultados entre los dos sistemas en azul, y los que difieren en número en rojo.

Como parte de nuestro despliegue, todas las búsquedas predeterminadas, esas búsquedas en la cadena vacía, ya han sido proporcionadas por Elasticsearch durante varios meses, por lo que los usuarios ya están viendo y usando los resultados de Elasticsearch sin problemas.

Sin embargo, hay limitaciones a lo que podemos aprender de este tipo de comparación. En el mejor de los casos, solo podemos inferir la intención de una búsqueda en particular, y los datos del catálogo son fluidos.

Diferencias conocidas

Las diferencias a continuación son en gran medida fundamentales, o el resultado de las decisiones tomadas después de un análisis exhaustivo de los resultados de búsqueda: son imposibles de eliminar por completo.

Stemming

Stemming es el proceso de reducir las palabras inflexas (o algunas veces derivadas) a sus palabra raízbase o raíz forma - generalmente una forma de palabra escrita.

Un stemmer para ingles que opera en el tallo. gato debe identificar tal instrumentos de cuerda as gatos, felino y malicioso. Un algoritmo de derivación también podría reducir las palabras pesca, pescado y pescador al tallo Pescado. El vástago no necesita ser una palabra, por ejemplo, el algoritmo Porter reduce argumentar, argumentó, argumenta, argumentando y Argos al tallo discutir.

Nuestra búsqueda existente utiliza el stemmer Lancaster (Paice / Husk), este algoritmo generalmente se considera demasiado agresivo; esto resulta en una falta de distinción, por ejemplo. encendedor y ligero Sería considerado como el mismo término bajo Lancaster.

Elasticsearch utiliza un algoritmo más reciente y mucho menos agresivo (Porter2) que ha ganado una amplia adopción en la industria y generalmente se considera una mejora significativa (Lancaster ahora es poco frecuente). El cambio de stemmer tiene un impacto potencial en una proporción significativa (~ 35%) de búsquedas: es decir, no se obtiene resultados. va a ser diferente, solo que ellos podría ser diferente, pero en general esto debería ser para mejor: dicho esto, algunos subconjuntos de clientes pueden depender del comportamiento anterior.

Pertinencia

Nuestra búsqueda existente parece tener una normalización de TF más estricta. Esto provoca una clasificación de relevancia diferente para los términos que se encuentran en campos más grandes (es decir, existente considera que la coincidencia es menos relevante ya que le da menos importancia al término, ya que es más pequeño en relación con la longitud del documento).

Caracteres especiales

Los caracteres especiales se eliminan dentro de nuestra búsqueda existente, esto equivale a la puntuación y los caracteres relacionados: en lugar de eliminar, generalmente los evitamos en Elasticsearch, por lo que existe la posibilidad de que una búsqueda los tenga en cuenta.

Manejo de términos

Las consultas de búsqueda existentes realizan `term smooshing` mientras que en Elasticsearch eliminamos los términos mal formados, considere esta búsqueda con un vacío tags: término: q=tags: state:ACTIVE

  • Existente: tags:state:ACTIVE - búsqueda de videos con una etiqueta de state:ACTIVE
  • Elasticsearch: state:ACTIVE - soltar el término vacío

Hay una serie de casos de borde sutil relacionados con el manejo de puntuación colgante y consultas que generalmente tienen un formato incorrecto. Intentamos producir lo que creemos que se pretendía que fuera la consulta, pero en estos casos desafortunadamente estamos adivinando lo que un usuario podría haber querido ( cuando realmente deberíamos haber devuelto un error permitiéndoles refinar su búsqueda)

Solo jugable

Hay dos mecanismos para restringir una búsqueda a videos que actualmente se pueden reproducir: la consulta puede incluir una marca, o la consulta en sí puede requerir algún aspecto de la jugabilidad.

  • Existente: esto se consulta en función del valor de un campo que se actualiza
  • Elasticsearch: esto se consulta en base a rangos de fechas calculadas

En general, Elasticsearch debería ser más preciso y producir mejores resultados (existe un retraso asociado con el mecanismo existente, y el mecanismo de mantenimiento de la bandera no es completamente confiable).

Indice de precisión

El índice de Elasticsearch es más "fresco" que el índice existente y tiende a reflejar las actualizaciones más rápido; no siempre es así, pero en general, la experiencia con Elasticsearch es que los resultados reflejarán con mayor precisión el estado de los datos del catálogo subyacente. Tanto los existentes como los de Elasticsearch son sistemas distribuidos y, por lo tanto, no son del todo coherentes con los resultados que obtienen: una consulta repetida contra cualquiera de los sistemas puede generar resultados diferentes (especialmente en el caso de que haya varias operaciones de eliminación que se ejecuten simultáneamente).

Los resultados de búsqueda existentes cambian según el estado del fragmento al que se asigna una cuenta: el estado global de un fragmento particular puede (y lo hace) afectar los resultados de cualquier consulta en particular: Elasticsearch no tiene esta deficiencia.

Ejemplos

ejemplo 1

Digamos que hay dos videos con los siguientes títulos:

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

El usuario desea devolver todos los videos que deben tener la palabra "light". Utilizando la CMS API, la consulta se vería como:

      q=%2Blight or q=+light

Con la búsqueda existente, esto devolverá ambos videos en el orden:

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

Hay dos problemas con esto:

  • Pertinencia: El pedido es incorrecto. “No mire a la luz” (Video # 2) debe aparecer antes de “Usar un encendedor para hacer una fogata” (Video # 1)
  • Exactitud: "Usar un encendedor para hacer una fogata" ni siquiera debería aparecer en el conjunto de resultados ya que la palabra "luz" no aparece en el título del video.

Con Elasticsearch, esto solo devolverá el video uno:

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

Esta es una mejora porque:

  • Relevancia: El orden es correcto.
  • Precisión: solo se devuelve Video one, ya que es el único video con la palabra "light" en el título.

ejemplo 2

Como se describe en nuestro CMS API documentación para la derivación, se admite la derivación, pero no búsquedas parciales de palabras. Así que digamos que hay videos 5 con los siguientes títulos:

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

El usuario desea devolver todos los videos que deben tener la palabra prohibición en el campo de nombre Utilizando la CMS API, la consulta se vería como:

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

La expectativa es que "Ban", "Banning" y "Banned" produzcan resultados de búsqueda, ya que "Ban" es una raíz de los tres.

Sin embargo, con el sistema de búsqueda actual, esto devolverá los cinco videos en este orden:

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

De nuevo, hay dos problemas con esto:

  • Relevancia: El pedido es incorrecto. "Se anunció la prohibición de estacionamiento" debe ser el primer video que se devuelve, ya que tiene la palabra "Prohibición".
  • Exactitud: "Bank Holiday" y "Bandit Captured" no deben devolverse en absoluto, ya que "Ban" no forma parte de la palabra "Bank" o "Bandit".

Con Elasticsearch, los resultados se ven como:

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

Esta es una mejora porque:

  • Relevancia: El orden es correcto.
  • Exactitud: solo se devuelven los videos con los vástagos de la palabra "Prohibición" ("Prohibición", "Prohibición" y "Prohibido").

Página actualizada por última vez el 12 jun 2020