지원 고객 지원 문의 | 시스템 상태 시스템 상태
페이지 내용

    카탈로그 검색 아키텍처

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

    개요

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

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

    검색 결과 차이 및 영향

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

    비교

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

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

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

    알려진 차이점

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

    형태소 분석

    형태소 분석은굴절 된 (또는 때로는 파생 된) 단어를단어 줄기 , 기본 또는루트형식 (일반적으로 서면 단어 형식) 으로 줄이는 과정입니다.

    스템에서 작동하는 영어 용 형태소 분석기고양이그러한 것을 식별해야문자열같이고양이 , 고양이 같은캐티 . 형태소 분석 알고리즘은 단어를 줄일 수도 있습니다. 어업 , 낚시어부줄기에물고기 . 어간은 단어 일 필요가 없습니다. 예를 들어 Porter 알고리즘은논하다 , 논쟁 , 주장하다 , 논쟁아르고스줄기에아르 구 .

    우리의 기존 검색은 랭커스터 (Paice/Husk) 형태소 분석기를 사용합니다. 이 알고리즘은 일반적으로 지나치게 공격적인 것으로 간주됩니다. 예를 들어가볍고가벼운것은 랭커스터에서 동일한 용어로 간주됩니다.

    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"

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

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