Support Kontakt Support | Systemstatus Systemstatus

Katalogsuche-Architektur

In diesem Thema lernen Sie die Architektur der Katalogsuchtechnologie kennen, die sowohl für das CMS als auch für das CMS verwendet wird Playback APIs.

Überblick

Ab April 2019 wurde die Katalogsuchfunktion auf Elasticsearch aktualisiert. Dieses Upgrade bietet eine Reihe von Vorteilen, darunter vor allem die verbesserte Relevanz und Genauigkeit sowie die drastisch verbesserte Leistung - die Antwortzeiten sind wesentlich konsistenter und im Allgemeinen doppelt so schnell. Diese neue Funktionalität wirkt sich auf die CMS API, Playback API, Interaktive Suche in Studio und die Katalogsuchmethoden.

Obwohl Brightcove erhebliche Anstrengungen unternommen hat, um die Elasticsearch-Ergebnisse konsistent zu machen, gibt es Unterschiede, und es besteht eine geringe Wahrscheinlichkeit, dass sich Ihre Integration möglicherweise nicht wie erwartet verhält, wenn Sie bestimmte Abhängigkeiten von Suchergebnissen codiert haben.

Unterschiede und Auswirkungen der Suchergebnisse

Bei der Untersuchung der möglichen Auswirkungen hat Brightcove festgestellt, dass mehr als 90% der Suchanfragen Ergebnisse liefern, die hinsichtlich der Anzahl der zurückgegebenen Ergebnisse übereinstimmen. Dies ist ein Indikator dafür, dass die erwarteten Ergebnisse nicht unterschiedlich genug sein sollten, um Probleme mit der API-Integration zu verursachen.

Vergleich

Diese Grafik zeigt die Anzahl der Suchergebnisse, die in Blau genau der Anzahl der Ergebnisse zwischen den beiden Systemen entsprechen, und die, deren Anzahl sich in Rot unterscheidet.

Als Teil unseres Roll-Outs werden alle Standard-Suchvorgänge, dh Suchvorgänge auf der leeren Zeichenfolge, bereits seit mehreren Monaten von Elasticsearch bereitgestellt - so dass Benutzer die Ergebnisse von Elasticsearch bereits problemlos sehen und verwenden können.

Es gibt jedoch Einschränkungen, was wir aus dieser Art von Vergleich lernen können. Im besten Fall können wir nur auf die Absicht einer bestimmten Suche schließen, und Katalogdaten sind fließend.

Bekannte Unterschiede

Die nachstehenden Unterschiede sind weitgehend grundlegend oder das Ergebnis von Entscheidungen, die nach einer umfassenden Analyse der Suchergebnisse getroffen wurden - sie sind unmöglich vollständig zu beseitigen.

Stemming

Stemming ist der Prozess des Reduzierens eingebogener (oder manchmal abgeleiteter) Wörter auf ihre WortstammBasis oder Wurzel Form - im Allgemeinen eine geschriebene Wortform.

Ein Stemmer für Englisch am Stiel Katze sollte solche identifizieren Streicher as Katzen, katzenhaft und Catty. Ein Stemming-Algorithmus kann auch die Wörter reduzieren Angeln, gefischt und Fischer zum Stiel Fisch. Der Stamm muss kein Wort sein, beispielsweise reduziert der Porter-Algorithmus argumentieren, argumentierte, argumentiert,, streiten und argus zum Stiel argu.

Bei unserer bestehenden Suche wird der Lancaster (Paice / Husk) -Stemmer verwendet. Dieser Algorithmus wird im Allgemeinen als zu aggressiv angesehen - dies führt zum Beispiel zu keiner Unterscheidung Feuerzeug und ! würde unter Lancaster als derselbe Begriff angesehen.

Elasticsearch verwendet einen neueren und weniger aggressiven Algorithmus (Porter2), der in der Industrie breite Akzeptanz gefunden hat und allgemein als bedeutende Verbesserung betrachtet wird (Lancaster ist jetzt selten). Die Änderung der Stammdaten beeinflusst möglicherweise einen erheblichen (~ 35%) -Anteil der Suchanfragen: Dies bedeutet nicht, dass dies Ergebnisse sind werden unterschiedlich sein, nur dass sie könnte anders sein - aber im Allgemeinen sollte dies zum Besseren sein: einige Kunden könnten jedoch auf das alte Verhalten angewiesen sein.

Relevanz

Unsere bestehende Suche scheint eine strengere TF-Normalisierung zu haben. Dies führt zu einer unterschiedlichen Relevanzsortierung für Begriffe, die in größeren Feldern gefunden werden (dh, die Übereinstimmung hält die Übereinstimmung für weniger relevant, da der Begriff dadurch weniger gewichtet wird, da er relativ zur Länge des Dokuments kleiner ist).

Sonderzeichen

Sonderzeichen werden in unserer bestehenden Suche entfernt. Dies entspricht in etwa der Entfernung von Interpunktionszeichen und verwandten Zeichen. Anstatt sie zu entfernen, werden sie in Elasticsearch normalerweise nicht verwendet. Daher besteht die Möglichkeit, dass sie bei einer Suche berücksichtigt werden.

Terminabwicklung

Bestehende Suchanfragen führen zu "Begriffsmoosing", wohingegen in Elasticsearch missgebildete Begriffe verworfen werden tags: Begriff: q=tags: state:ACTIVE

  • Vorhanden: tags:state:ACTIVE - Suche nach Videos mit einem Tag von state:ACTIVE
  • Elasticsearch: state:ACTIVE - lassen Sie den leeren Begriff fallen

Es gibt eine Reihe subtiler Randfälle im Zusammenhang mit dem Umgang mit unzusammenhängenden Satzzeichen und Abfragen, die im Allgemeinen fehlerhaft sind. Wir versuchen, das zu liefern, was wir für die Abfrage halten, aber in diesen Fällen raten wir leider, was ein Benutzer beabsichtigt hat ( wann hätten wir eigentlich einen Fehler zurückgeben sollen, der es ihnen erlaubt, ihre Suche zu verfeinern)

Nur spielbar

Es gibt zwei Mechanismen, um eine Suche auf aktuell abspielbare Videos zu beschränken: Die Abfrage kann ein Flag enthalten, oder die Abfrage selbst kann einen Aspekt der Abspielbarkeit erfordern.

  • Vorhanden: Dies wird basierend auf dem Wert eines Felds abgefragt, das aktualisiert wird
  • Elasticsearch: Dies wird basierend auf berechneten Datumsbereichen abgefragt

Elasticsearch sollte im Allgemeinen genauer sein und bessere Ergebnisse erzielen (der bestehende Mechanismus hat eine Verzögerung, und der Flag-Wartungs-Mechanismus ist nicht völlig zuverlässig).

Indexgenauigkeit

Der Elasticsearch-Index ist "frischer" als der vorhandene Index und neigt dazu, Aktualisierungen schneller wiederzugeben. Dies ist nicht immer der Fall. Im Allgemeinen besteht die Erfahrung mit Elasticsearch jedoch darin, dass die Ergebnisse den Zustand der zugrunde liegenden Katalogdaten genauer widerspiegeln. Sowohl vorhandene als auch Elasticsearch sind verteilte Systeme und daher in den Ergebnissen, die sie zurückgeben, nicht völlig konsistent: Eine wiederholte Abfrage eines der beiden Systeme kann möglicherweise unterschiedliche Ergebnisse zurückgeben (insbesondere wenn mehrere gleichzeitig ausgeführte Löschvorgänge ausgeführt werden).

Bestehende Suchergebnisse ändern sich je nach Status des Shards, dem ein Konto zugewiesen ist. Der globale Status eines bestimmten Shards kann (und hat Auswirkungen) auf die Ergebnisse einer bestimmten Abfrage: Elasticsearch weist diesen Mangel nicht auf.

Beispiele

Beispiel 1

Nehmen wir an, es gibt zwei Videos mit folgenden Titeln:

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

Der Benutzer möchte alle Videos zurücksenden, die das Wort "Licht" haben müssen. Verwendung der CMS APIDie Abfrage würde folgendermaßen aussehen:

      q=%2Blight or q=+light

Bei der vorhandenen Suche werden beide Videos in der Reihenfolge zurückgegeben:

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

Es gibt zwei Probleme damit:

  • Relevanz: Die Reihenfolge ist falsch. "Schauen Sie nicht ins Licht" (Video # 2) sollte erscheinen vor "Mit einem Feuerzeug ein Lagerfeuer machen" (Video # 1)
  • Genauigkeit: „Ein Lagerfeuer mit Feuerzeug anzünden“ sollte nicht einmal in der Ergebnismenge erscheinen, da das Wort „Licht“ überhaupt nicht im Videotitel erscheint.

Mit Elasticsearch wird nur ein Video zurückgegeben:

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

Dies ist eine Verbesserung, weil:

  • Relevanz: Die Bestellung ist korrekt.
  • Genauigkeit: Nur Video Eins wird zurückgegeben, da es das einzige Video mit dem Wort "Licht" im Titel ist.

Beispiel 2

Wie in unserem beschrieben CMS API Dokumentation zum StemmingDas Stemming wird unterstützt, jedoch keine Teilwortsuche. Nehmen wir an, es gibt 5-Videos mit folgenden Titeln:

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

Der Benutzer möchte alle Videos zurückgeben, die das Wort enthalten müssen Verbot im Namensfeld. Verwendung der CMS APIDie Abfrage würde folgendermaßen aussehen:

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

Die Erwartung ist, dass "Verbot", "Verbot" und "Verboten" zu Ergebnissen führen würden, da "Verbot" ein Stamm aller drei ist.

Mit dem aktuellen Suchsystem werden jedoch alle fünf Videos in dieser Reihenfolge zurückgegeben:

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

Auch hier gibt es zwei Probleme:

  • Relevanz: Die Bestellung ist falsch. "Parkverbot angekündigt" sollte das erste Video sein, das das Wort "Verbot" enthält.
  • Genauigkeit: "Bank Holiday" und "Bandit Captured" sollten nicht zurückgegeben werden, da "Ban" nicht Teil des Wortes "Bank" oder "Bandit" ist.

Mit Elasticsearch sehen die Ergebnisse folgendermaßen aus:

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

Dies ist eine Verbesserung, weil:

  • Relevanz: Die Bestellung ist korrekt.
  • Genauigkeit: Es werden nur Videos mit den Stielen des Wortes "Verbot" ("Verbot", "Verbot" und "Verboten") zurückgegeben.

Seite zuletzt aktualisiert am 12. Juni 2020