기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

속성이 3개 이상인 복합 인덱스

개요

복합 또는 복합 인덱스는 단일 인덱스 구조 내에서 여러 필드에 대한 참조를 유지합니다. 이러한 인덱스는 여러 필드를 동시에 필터링하거나 필터링을 정렬 작업과 결합하는 쿼리의 성능을 최적화합니다. 또한 가장 왼쪽에 인덱싱된 필드의 단일 조건 쿼리에도 효과적입니다. 데이터베이스는 이러한 인덱스 항목을 활용하여 전체 컬렉션 스캔을 수행하지 않고도 일치하는 문서를 효율적으로 찾습니다.

Amazon DocumentDB는 복합 인덱스를 사용하여 인덱스 접두사라고 하는 개념인 인덱싱된 필드의 선행 하위 집합을 포함하는 쿼리를 지원할 수 있습니다. 예를 들어에 복합 인덱스가 있는 경우 {state: 1, city: 1, zipcode: 1} Amazon DocumentDB는 'state' 필드만 사용하거나, 'state' 및 'city' 필드를 함께 사용하거나, 'state', 'city' 및 'zipcode' 세 필드를 모두 사용하는 쿼리를 효율적으로 처리할 수 있습니다. 그러나 쿼리는 그 사이에 필드를 건너뛰지 않고 왼쪽에서 오른쪽으로 필드를 사용해야 합니다. 즉, 'city' 또는 'zipcode' 필드만 사용하거나 'state' 및 'zipcode'('city' 건너뛰기)와 같은 조합을 사용하는 쿼리는 인덱스를 완전히 활용할 수 없습니다.

대부분의 실제 시나리오에서 속성이 3개 이하인 복합 인덱스는 일반적으로 최적의 성능과 리소스 효율성을 달성합니다. 복합 인덱스에 속성이 3개 이상 있을 수 있지만 리소스 소비가 증가하여 이점을 능가하는 경우가 많습니다.

클러스터에 미치는 영향

이론적 성능을 극대화하기 위해 쿼리의 모든 조건을 포함하는 인덱스를 생성하려고 하지만 대부분의 데이터 필터링은 복합 인덱스의 처음 1~3개의 속성을 통해 이루어집니다. 이 임계값을 초과하는 추가 필드는 의미 있는 쿼리 최적화보다는 주로 인덱스 크기에 영향을 미칩니다.

스토리지 및 I/O 오버헤드: 속성이 많은 복합 인덱스는 더 간단한 대안보다 훨씬 더 많은 스토리지 공간을 소비합니다. 크기는 인덱싱된 속성 수와 인덱싱된 값 자체의 크기에 정비례합니다.

메모리 공간: 속성이 많은 복합 인덱스의 스토리지 공간이 크면 해당 메모리 공간이 생성되므로 작업 세트가 더 커지고 버퍼 풀에서 자주 액세스하는 다른 데이터가 대체됩니다.

쓰기 작업: 여러 인덱싱된 필드에 영향을 미치는 각 문서를 수정하려면 전체 복합 인덱스 항목을 업데이트하고 쓰기 작업을 완료하는 데 필요한 작업을 곱해야 합니다.

식별 방법

먼저 컬렉션의 모든 인덱스를 검토하여 속성이 3개 이상인 복합 인덱스를 식별합니다.

// List all indexes for the collection
db.collection.getIndexes()

// Look for indexes with 3+ fields like:

// { "userId": 1, "status": 1, "category": 1, "priority": 1, "region": 1 }
// { "orderId": 1, "customerId": 1, "productId": 1, "timestamp": 1, "warehouse": 1 }
      

문제 해결

속성이 3개 이상인 복합 인덱스를 사용하는 경우 이를 활용하는 쿼리를 식별하고 최적화 기회를 찾습니다. 이러한 인덱스를 3개 이하의 속성을 포함하는 보다 효율적인 인덱스로 대체하는 것이 좋습니다. 새 인덱스를 구현한 후 속성이 3개 이상인 이전 인덱스를 제거합니다.

복합 인덱스를 생성할 때 Equality, Sort, Range(ESR) 규칙을 따릅니다.

ESR(Equal Sort Range) 규칙:이 순서 지정은 먼저 등식 조건으로 데이터 세트를 필터링한 다음 축소된 세트에 정렬 작업을 적용하고 마지막으로 가능한 가장 작은 하위 집합에 대해 범위 스캔을 수행하여 인덱스 효율성을 극대화합니다.

// Query pattern
db.orders.find({ 
  userId: "user123",                    // Equality
  price: { $gte: 50, $lte: 200 }      // Range
}).sort({ createdAt: -1 })             // Sort

// Optimal index following ESR rule
db.orders.createIndex({ userId: 1, createdAt: -1, price: 1 })
//                      Equality   Sort         Range