카탈로그 검색 아키텍처

이 항목에서는 CMS 및 재생 API 모두에 사용되는 카탈로그 검색 기술의 아키텍처에 대해 학습합니다.

개요

2019년 4월부터 카탈로그 검색 기능이 Elasticsearch로 업그레이드되었습니다. 이 업그레이드는 여러 가지 이점을 제공합니다. 그 중에서도 가장 중요한 것은 관련성 및 정확성 향상, 성능이 크게 향상되었습니다. 응답 시간은 훨씬 더 일관되고 일반적으로 두 배 빠릅니다. 이 새로운 기능은 CMS API, 재생 API, 스튜디오 대화형 검색 및 카탈로그 검색 방법에 영향을 미칩니다.

브라이트코브는 Elasticsearch 결과를 일관되게 만들기 위해 상당한 노력을 기울였지만 차이점이 있습니다. 검색 결과에 대한 특정 종속성을 코딩한 경우 통합이 예상대로 작동하지 않을 수도 있습니다.

검색 결과 차이 및 영향

브라이트코브는 잠재적인 영향력을 연구하면서 검색의 90% 이상이 반환된 결과 수와 일치하는 결과를 반환한다는 사실을 발견했습니다. 이는 예상 결과가 API 통합에 문제를 일으킬 만큼 충분히 달라서는 안된다는 지표입니다.

비교

이 그래프는 두 시스템 간의 결과 수와 정확히 일치하는 검색 결과 수와 빨간색이 다른 검색 결과 수를 보여줍니다.

롤아웃의 일부로 모든 기본 검색, 즉 빈 문자열에 대한 검색은 이미 Elasticsearch에서 몇 달 동안 제공되었으므로 사용자는 이미 Elasticsearch 결과를 문제없이 보고 사용하고 있습니다.

그러나 이런 종류의 비교에서 배울 수 있는 것에는 한계가 있습니다. 기껏해야 특정 검색의 의도 만 추론 할 수 있으며 카탈로그 데이터는 유동적입니다.

알려진 차이점

아래의 차이점은 대부분 근본적이거나 검색 결과를 광범위하게 분석 한 후 결정의 결과입니다. 완전히 제거하는 것은 불가능합니다.

형태소 분석

스테밍굴절된(또는 때때로 파생된) 단어를 그들의 단어로 줄이는 과정입니다. 단어 줄기 , 베이스 또는뿌리형태 — 일반적으로 쓰여진 단어 형태.

어간에서 작동하는 영어용 스테머고양이그러한 식별해야문자열 ~처럼고양이 , 고양이 같은그리고캐티 . 어간법을 사용하면낚시 , 낚시, 낚시꾼이라는 단어를줄기어족으로 줄일 수도있습니다. 어간은 단어일 필요가 없습니다. 예를 들어 Porter 알고리즘은다투다 , 논쟁 , 주장하다 , 논쟁그리고아르고스줄기에논쟁하다 .

기존 검색에서는 Lancaster (Paice/Husk) 줄기법을 사용하는데, 이 알고리즘은 일반적으로 지나치게 공격적인 것으로 간주됩니다. 따라서 Lancaster에서는 Lighter와 Light를 같은 용어로 간주하기 때문에 구분이 부족합니다.

Elasticsearch는 업계에서 광범위한 채택을 얻었으며 일반적으로 상당한 개선으로 간주되는 최신 훨씬 덜 공격적인 알고리즘 (Porter2) 을 사용합니다 (랭커스터는 이제 드뭅니다). 형태소 분석기의 변경은 잠재적으로 상당한(~35%) 검색 비율에 영향을 미칩니다. ~ 할 것이다다르다, 다만 그들이 ~할 것 같다다를 수 있지만 일반적으로 이것은 더 나은 방향이어야 합니다. 즉, 일부 고객 하위 집합은 이전 동작에 의존할 수 있습니다.

관련성

기존 검색은보다 엄격한 TF 정규화가있는 것 같습니다. 이로 인해 더 큰 필드에서 발견되는 용어에 대해 다른 관련성 정렬이 발생합니다 (즉, 기존은 문서의 길이에 비해 작기 때문에 용어에 가중치가 적기 때문에 일치가 덜 관련성이 있다고 간주합니다).

특수 문자

특수 문자는 기존 검색 내에서 제거되며, 이는 구두점 및 관련 문자를 제거하는 것과 같습니다. 스트립하는 대신 일반적으로 Elasticsearch에서 이스케이프하므로 검색이 대신 고려할 가능성이 있습니다.

용어 처리

기존 검색 쿼리는 '용어 다듬기'를 수행하는 반면 Elasticsearch에서는 형식이 잘못된 용어를 삭제하므로 이tags:검색어를 빈 용어로 간주합니다. q=tags: state:ACTIVE

  • 기존 : tags:state:ACTIVE— 태그가 지정된 동영상 검색state:ACTIVE
  • 엘라스틱서치 : state:ACTIVE— 빈 용어 삭제

매달린 구두점 및 일반적으로 잘못된 형식의 쿼리를 처리하는 것과 관련된 여러 가지 미묘한 경우가 있습니다. 쿼리가 의도 된 것으로 생각되는 것을 생성하려고 시도하지만 이러한 경우 불행히도 사용자가 의도 한 것을 추측하고 있습니다 (실제로 오류를 반환해야 할 때검색 범위를 좁힐 수 있음)

플레이만 가능

현재 재생 가능한 동영상으로 검색을 제한하는 두 가지 메커니즘이 있습니다. 쿼리에 플래그가 포함되거나 쿼리 자체에 재생성의 일부 측면이 필요할 수 있습니다.

  • 기존: 업데이트되는 필드의 값을 기반으로 쿼리됩니다.
  • 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)
  • 정확도 : 동영상 제목에 '빛'이라는 단어가 전혀 나타나지 않기 때문에 “라이터를 사용하여 캠프파이어 만들기”는 결과 집합에 나타나지 않아야 합니다.

Elasticsearch를 사용하면 비디오 하나만 반환됩니다.

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

이것은 다음과 같은 이유로 개선 된 것입니다.

  • 관련성: 순서가 정확합니다.
  • 정확도: 제목에 “light”라는 단어가 있는 유일한 동영상이므로 동영상 1개만 반환됩니다.

예제 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

“금지”가 세 가지 모두의 줄기이기 때문에 “금지”, “금지” 및 “금지”가 검색 결과를 산출한다는 기대가 있습니다.

하지만 현재 검색 시스템에서는 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"

다시 말하지만, 다음과 같은 두 가지 문제가 있습니다.

  • 관련성: 주문이 올바르지 않습니다. “주차 금지 발표”는 “금지”라는 단어가 있는 첫 번째 동영상이어야 합니다.
  • 정확도: “금지”는 단어 “은행”또는 “산적”의 일부가 아니기 때문에 “은행 휴일”과 “산적 캡처”는 전혀 반환해서는 안됩니다.

Elasticsearch를 사용하면 결과는 다음과 같습니다.

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

이것은 다음과 같은 이유로 개선 된 것입니다.

  • 관련성: 순서가 정확합니다.
  • 정확도: “금지” (“금지”, “금지”, “금지”) 라는 단어의 줄기가 있는 동영상만 반환됩니다.