카우치베이스 기본 인덱스의 주요 용도

쿼리 서비스용 N1QL에 대해 자주 묻는 몇 가지 질문입니다:

1. 실제로 기본 인덱스는 언제 사용하나요?
2. 왜 인덱스 어드바이저는 권장하지 않습니다. 유일한 선택지가 될 수 있는 경우 기본 인덱스를 사용하시겠습니까?

계속 읽기...

카우치베이스는 분산형 데이터베이스입니다. JSON을 사용해 유연한 데이터 모델을 지원합니다. 버킷의 각 문서에는 사용자가 생성한 고유 문서 키가 있습니다. 이 고유성은 데이터를 삽입하거나 업데이트하는 동안 적용됩니다. 다음은 문서 예시입니다.

각 Couchbase 버킷에는 고객, 주문, 카탈로그 등 여러 유형의 데이터를 저장할 수 있습니다. "여행 샘플" 데이터 집합을 로드하면 항공사, 공항, 호텔, 경로, 랜드마크 등 다섯 가지 유형의 문서를 로드하게 됩니다.

그러나 기본적으로 Couchbase에는 모든 문서를 처음부터 끝까지 스캔하는 "전체 테이블 스캔"과 같은 기능이 없습니다. 기본 인덱스 스캔은 "전체 테이블 스캔"에 해당하는 기능을 제공합니다.

고객에 기본 인덱스 ix_customer_primary를 생성합니다;

기본 색인이란 무엇인가요?

• • 버킷 고객 내 모든 문서 유형의 모든 문서 키가 정렬된 목록입니다.
  • 다른 보조 인덱스와 마찬가지로 비동기적으로 유지됩니다.
  • 문서 키만 보관하고 다른 것은 보관하지 않습니다.
  • 는 모든 스캔 일관성을 지원합니다:
    • 무제한
    • AT_PLUS
    • REQUEST_PLUS

기본 인덱스를 사용하면 쿼리 엔진이 모든 문서에 액세스한 다음 필터링, 조인, 집계 등의 작업을 수행할 수 있습니다.

고객에서 SELECT * WHERE zip = 94040 이름 이름 = "joe" 및 유형 = "cx"를 설명합니다;

느립니다. 매우 느립니다. 불필요한 문서 가져오기, 불필요한 필터링. 메모리와 CPU 낭비. 기본 스캔은 쿼리가 결국 사용자에게 문서를 반환하는지 여부와 관계없이 버킷에 있는 모든 유형의 문서를 모두 검색합니다. 기본 스캔은 테이블 스캔과 비슷하다고 말씀드렸지만, 모든 유형의 문서를 모두 스캔해야 하므로 테이블 스캔보다 훨씬 느립니다.

기본 인덱스를 사용해서는 안 됩니다. 사용하지 마세요. 특히 프로덕션 환경에서는 더욱 그렇습니다.

 그렇다면 왜 기본 인덱스가 있을까요?

1. 새로운 샘플 데이터를 가지고 놀기 시작할 때는 특정 인덱스 생성에 대해 걱정할 필요 없이 대부분의 쿼리를 실행할 수 있습니다. 이 시점에서는 처리량을 조정하는 것보다 데이터를 이해하는 것이 우선입니다.
2. 스캔하려는 기본 키의 범위를 알고 있는 경우.
   1. 어디 META().id 사이 "cx:123" 그리고 "cx:458"
3. 다음과 같은 경우 후행 아래와 같이 META().id 패턴을 사용합니다.
   1. 어디 META().id 좋아요 "cx:1%"
   2. 사용하지 마십시오: "%:123"과 같이. 이렇게 하면 전체 스캔이 수행됩니다.
4. 전체 메타().id 또는 메타().id 목록을 알고 있는 경우 USE KEY를 사용하여 기본 인덱스를 참조하지 않고 문서를 직접 가져올 수 있습니다.
   1. FROM 고객 사용 키 ["cx:123"]
   2. FROM 고객 사용 키 ["cx:123", "cx:359", "cx:948"]
   3. FROM 고객 사용 키 (선택 raw docid FROM 내 목록 어디 zip = 94501)

기본 색인

'travel-sample'에 기본 인덱스를 생성합니다;

기본 인덱스는 단순히 전체 버킷의 문서 키에 대한 인덱스입니다. Couchbase 데이터 계층은 문서 키에 고유성 제약 조건을 적용합니다. 기본 인덱스는 Couchbase의 다른 모든 인덱스와 마찬가지로 비동기적으로 유지됩니다. 데이터의 최신성을 설정하는 방법은 일관성 수준 를 입력하세요.

이 인덱스의 메타데이터는 다음과 같습니다:

메타데이터는 인덱스에 대한 추가 정보를 제공합니다: 인덱스가 있는 위치(datastore_id), 인덱스의 상태(state), 인덱싱 방법(사용) 등입니다.
기본 인덱스는 쿼리에 필터(술어)가 없거나 다른 인덱스나 액세스 경로를 사용할 수 없는 경우 전체 버킷 스캔(기본 스캔)에 사용됩니다. Couchbase에서는 여러 키 공간(서로 다른 유형의 문서, 고객, 주문, 재고 등)을 하나의 버킷에 저장합니다. 따라서 기본 스캔을 수행할 때 쿼리는 색인을 사용하여 문서 키를 가져오고 버킷에 있는 모든 문서를 가져온 다음 필터를 적용합니다. 따라서 이것은 매우 비쌉니다.

문서 키 디자인은 여러 부분으로 구성된 기본 키 디자인과 다소 유사합니다.

성:이름:고객ID

예: smith:john:X1A1849

Couchbase에서는 키 앞에 문서 유형이 포함된 접두사를 붙이는 것이 좋습니다. 이 문서는 고객 문서이므로 접두사 앞에 CX를 붙이겠습니다. 이제 키는 다음과 같습니다:

따라서 같은 버킷에 다른 유형의 문서가 있을 수 있습니다.

이는 모범 사례일 뿐입니다. 버킷 내에서 고유해야 한다는 점을 제외하면 Couchbase에서 문서 키의 형식이나 구조에는 제한이 없습니다.

이제 다양한 키가 있는 문서가 있고 기본 인덱스가 있는 경우 다음 쿼리를 사용하여 효율적으로 작업할 수 있습니다.

예 1: 특정 문서 키를 찾고 있습니다.

전체 문서 키를 알고 있는 경우 다음 문을 사용하여 인덱스 액세스를 완전히 피할 수 있습니다.

선택 * FROM 판매 사용 키 ["CX:smith:john:X1A1849"]

명세서에 두 개 이상의 문서를 넣을 수 있습니다.

예 2:  패턴을 찾습니다. 모든 고객 문서를 가져옵니다.

예 3:  성이 스미스인 모든 고객을 확보하세요.

다음 쿼리는 기본 인덱스를 효율적으로 사용하여 특정 범위의 고객만 가져옵니다.  참고: 이 스캔은 대소문자를 구분합니다. 대소문자를 구분하지 않는 스캔을 수행하려면 문서 키의 UPPER() 또는 LOWER()를 사용하여 보조 인덱스를 생성합니다.

예 4:  일부 애플리케이션은 이메일 주소가 고유하기 때문에 문서 키의 일부로 이메일 주소를 사용하는 것이 일반적입니다. 이 경우 gmail.com을 사용하는 모든 고객을 찾아야 합니다. 이것이 일반적인 요구 사항이라면 이메일 주소의 역방향을 키로 저장하고 선행 문자열 패턴을 스캔하기만 하면 됩니다.

이메일:johnsmith@gmail.com;   키: 역방향("johnsmith@gmail.com") => moc.liamg@시간 

이메일: janesnow@야후.com  키: 역방향("janesnow@yahoo.com") => moc.oohay@원세나즈

명명된 기본 색인

Couchbase 5.0에서는 간단한 매개변수 CREATE INDEX를 사용하여 인덱스의 복제본을 여러 개 생성할 수 있습니다. 다음은 인덱스의 복사본 3개를 생성하며 클러스터에 최소 3개의 인덱스 노드가 있어야 합니다.

기본 인덱스의 이름을 지정할 수도 있습니다. 기본 인덱스의 나머지 기능은 인덱스 이름을 제외하고는 동일합니다. 이 기능의 좋은 점은 5.0 이전 Couchbase 버전에서 서로 다른 이름을 사용하여 여러 개의 기본 인덱스를 가질 수 있다는 것입니다. 중복 인덱스는 고가용성뿐만 아니라 인덱스 전체에 쿼리 부하를 분산하는 데 도움이 됩니다. 이는 기본 인덱스와 보조 인덱스 모두에 해당됩니다.

마지막으로, Couchbase 6.5에서는 인덱스 어드바이저를 도입했습니다. 이 기능은 단일 N1QL 문 또는 워크로드를 분석할 수 있습니다. 자세한 내용은 여기에서 확인하세요:

1. N1QL 인덱스 어드바이저: 쿼리 성능 및 생산성 향상
2. N1QL 쿼리 문용 인덱스 어드바이저
3. 쿼리 워크로드를 위한 인덱스 어드바이저

이 인덱스 어드바이저는 적절한 보조 인덱스만 추천하고 주 인덱스는 추천하지 않습니다. 지금까지 글을 읽어보셨다면 그 이유를 아실 것입니다! Couchbase 6.5 다운로드 새로운 기능을 모두 사용해 보세요!