전체 텍스트 검색

스코치 인덱스 유형 - 왜 중요한가요?

인덱스 유형 전체 텍스트 검색(FTS)에서 반전 인덱스 형식의 총체적인 사양과 저장소 측면을 의미합니다. 스코치는 발전하고 진화하는 고급 인덱스 유형입니다. 하지만 스코치에 대해 자세히 알아보기 전에 업사이드 다운으로 알려진 이전 인덱싱 유형에 대해 간략히 살펴볼 필요가 있습니다.

업사이드 다운 인덱싱 형식에서는 백업 인덱스의 스토리지 측면이 키 값 저장소로 오프로드됩니다. 본질적으로 이것이 의미하는 바는 용어 사전, 게시글 목록 등과 같은 모든 기초적인 정보 검색 데이터 구조가 모두 일반 키 값 저장소에 키와 값의 형태로 저장된다는 것입니다. 많은 유사한 시스템과 마찬가지로 키는 값이 무엇을 나타내는지 식별하기 위해 더 많은 세부 사항으로 장식되어 있습니다. 여기서 논의 중인 주요 주제는 스코치이므로 자세한 설명은 생략하겠습니다. 업사이드_down은 Couchbase 서버 5.5.0 릴리스까지 기본 인덱스 유형이었습니다.

세심하게 설계된 bleve(인덱싱 라이브러리) 인터페이스를 통해 다양한 키-값 시스템(예: levelDB, RockDB, mossStore 등)에서 역 인덱스 표현을 실험하고 성능을 벤치마킹할 수 있었습니다. 하지만 곧 키 값 표현이 역 인덱스 확장에 병목 현상을 일으킨다는 사실이 드러났습니다.

관찰된 몇 가지 주요 문제는 다음과 같습니다,

  • 주로 KV 형식의 순진한 데이터 표현으로 인해 인덱스 크기가 크게 증폭됩니다.
  • 데이터 중복 제거 잠재력을 활용하지 못했습니다.
  • 퍼지/편집 거리와 같은 자연어 쿼리를 처리하기에는 덜 친숙한 표현입니다.

이러한 결함은 대규모 데이터 세트의 확장성 문제로 눈덩이처럼 커졌고, 결국 역 인덱스 표현과 디스크 스토리지를 재설계하기로 결정하게 되었습니다.  그리고 이러한 노력으로 다음과 같은 새로운 인덱스 유형이 탄생했습니다. scorch.

Scorch

스코치의 많은 기본 디자인 개념은 다음과 같은 것에서 영감을 받았습니다. Lucene.

Scorch는 세그먼트 기반 인덱스 아키텍처를 따릅니다. 각 인덱스는 세그먼트의 모음이며 각 세그먼트는 쿼리를 처리할 수 있는 자족적인 불변의 하위 인덱스입니다.

스코치에서는 내부적으로 숫자 식별자를 사용해 문서를 표현하기로 결정했습니다. 이로써 역 인덱스 표현에서 엄청난 최적화 기회가 열렸습니다.

이제 세그먼트 아키텍처에 대해 자세히 살펴보겠습니다. 각 세그먼트는 이러한 주요 빌딩 블록으로 구성됩니다.

용어 사전 - 반전 인덱스에서 가장 중요한 부분입니다. 색인된 모든 용어와 문서 빈도 및 필드별 글 목록에 대한 포인터를 저장합니다.

Scorch는 유한 상태 변환기(FST)를 사용하여 이 용어 사전을 구현할 수 있습니다. FST 기반 구현은 거리 편집 또는 정규식 기반 쿼리와 같은 고급 쿼리에 대한 메모리 절약 및 쿼리 최적화에 도움이 됩니다. DFA 속성입니다.

글 목록 - 검색어가 발생한 문서 목록을 제공합니다. 내부적으로 문서를 표현하기 위해 숫자 ID를 부여했으므로 이를 비트맵으로 가장 잘 표현할 수 있습니다. 비트맵 표현은 공간 절약, 빠른 조회 및 SSE에 최적화된 코드에 도움이 됩니다.

주파수 규범/위치 세부 정보 - 색인된 용어의 빈도 및 표준 세부 정보는 채점 시 사용됩니다. 구문 쿼리를 수행하거나 결과를 강조 표시하는 등의 작업에는 위치 또는 위치 세부 정보가 필요합니다. 따라서 이러한 정렬되지 않은 숫자 값은 다음과 같습니다. varint 독점 청킹 로직을 사용하여 인코딩 및 저장됩니다.

저장된 필드 - 사용자가 분석되지 않은 필드 값을 인덱스에 저장하고 검색 결과의 일부로 검색할 수 있도록 도와줍니다. 이렇게 하면 KV에 대한 추가 데이터 조회를 피할 수 있습니다.  Scorch는 독점적인 청킹 로직에 압축 기술을 사용하여 이 데이터를 표현합니다.

DocValues - 는 인덱스에서 역방향 조회를 수행합니다(예: 특정 문서에 대해 인덱싱된 모든 값 찾기). 이는 패싯이나 사용자 정의 필드에 대한 정렬 등과 같은 쿼리를 강화하는 데 도움이 됩니다. Scorch는 독점적인 압축 청킹 로직 위에 컬럼형 표현을 사용해 인덱스의 이 부분을 표현합니다.

Scorch는 디스크에서 이러한 바이트 평탄화 세그먼트 콘텐츠를 표현하기 위해 "zap"이라는 새로운 바이너리 형식을 사용합니다. 그리고 이러한 디스크 세그먼트 바이트는 매핑됩니다.

TLDR; - 위의 스코치 최적화는 내부 벤치마킹에서 많은 쿼리에서 최대 4배의 인덱스 크기 감소와 최대 20배의 쿼리 성능(지연 시간 및 처리량 기준) 향상을 가져왔습니다.

Couchbase 서버 릴리스 6.0.0부터 기본 인덱스 유형은 Scorch이며, 향후 FTS 릴리스에서 더 많은 기능이 추가되고 Scorch를 위한 로드맵이 만들어질 예정입니다.

따라서 진정한 FTS 사용 사례가 있는 경우 인덱스를 스코치 인덱스 형식으로 업그레이드할 것을 적극 권장합니다.

이 문서 공유하기
받은 편지함에서 카우치베이스 블로그 업데이트 받기
이 필드는 필수 입력 사항입니다.

작성자

게시자 스리칸트 시바산카란

스리칸트 시바산카란은 Couchbase R&D의 수석 엔지니어/시니어 엔지니어링 매니저입니다. 그는 분산형 고성능 검색 기능의 설계 및 개발을 이끌고 있습니다. 또한 통신, 핸드셋, 엔터프라이즈 소프트웨어, 빅 데이터 기술, 분산 시스템 등 다양한 분야에서 17년 이상의 제품 개발 경력을 보유하고 있습니다.

댓글 남기기

카우치베이스 카펠라를 시작할 준비가 되셨나요?

구축 시작

개발자 포털에서 NoSQL을 살펴보고, 리소스를 찾아보고, 튜토리얼을 시작하세요.

카펠라 무료 사용

클릭 몇 번으로 Couchbase를 직접 체험해 보세요. Capella DBaaS는 가장 쉽고 빠르게 시작할 수 있는 방법입니다.

연락하기

카우치베이스 제품에 대해 자세히 알고 싶으신가요? 저희가 도와드리겠습니다.