해시 인덱스와 오름차순 인덱스 간의 Mongodb 성능 차이(순서가 없는 필드에서 해시를 사용하지 않는 이유)

해시 인덱스와 오름차순 인덱스 간의 Mongodb 성능 차이(순서가 없는 필드에서 해시를 사용하지 않는 이유)

mongodb에는 여러 종류의 색인이 있습니다.이 질문에 대해 저는 정렬에 사용할 수 있는 오름차순(또는 내림차순) 색인과 문서에 따르면 "해쉬된 해시 키(소스)를 지원하기 위해 주로 샤드 클러스터와 함께 사용"되는 해시 색인에 관심이 있습니다.

다음과 같은 인덱스는 만들 수 없습니다.db.test.ensureIndex( { "key": "hashed", "sortOrder": 1 } )당신이 실수를 하기 때문에.

{
    "createdCollectionAutomatically" : true,
    "numIndexesBefore" : 1,
    "errmsg" : "exception: Currently only single field hashed index supported.",
    "code" : 16763,
    "ok" : 0
}

내 질문:

인덱스 사이:

1. db.test.ensureIndex( { "key": 1 } )

2. db.test.ensureIndex( { "key": "hashed" } )

조회용db.products.find( { key: "a" } )어떤 것이 더 성능이 좋습니까? 그것은?hashed열쇠O(1)

---

제가 질문에 도달한 방법:

이전에는 여러 개의 키 인덱스를 사용할 수 없었습니다.hashed양식의 색인을 작성했습니다.db.test.ensureIndex( { "key": 1, "sortOrder": 1 } )그리고 그것을 만드는 동안 나는 해시 인덱스가 오름차순 인덱스보다 더 성능이 좋은지 궁금했습니다(해시는 보통.O(1). (위에서 언급한 바와 같이) 때문에 키를 지금 그대로 두었습니다.db.test.ensureIndex( { "key": "hashed", "sortOrder": 1 } )허용되지 않았습니다.하지만 문제는 해시된 색인이 제 마음속에 남아 있는 키에 의한 검색 속도를 빠르게 한다는 것입니다.

제가 지수를 작성한 상황은 다음과 같습니다.

키별로 분류된 문서 목록이 들어 있는 컬렉션이 있었습니다.

예.{key: a, sortOrder: 1, ...},{key: a, sortOrder: 2, ...},{key: a, sortOrder: 3, ...},{key: b, sortOrder: 1, ...},{key: b, sortOrder: 2, ...}, ...

제가 사용한 이후로key페이지화를 분류하고 정렬 순서를 지정하기 위해, 저는 항상 하나의 값을 쿼리했습니다.key그리고 사용.sortOrder서류의 순서대로

즉, 두 가지 질문이 있을 수 있습니다.

• 첫 페이지용db.products.find( { key: "a" } ).limit(10).sort({"sortOrder", 1})
• 그리고 다른 페이지들은db.products.find( { key: "a" , sortOrder: { $gt: 10 } } ).limit(10).sort({"sortOrder", 1})

이 특정 시나리오에서는 다음을 사용하여 검색합니다.O(1)중요한 것을 위하여.O(log(n))sortOrder가 이상적이었지만, 그것은 허용되지 않았습니다.

조회용db.products.find( { key: "a" } )어떤 것이 더 성능이 좋습니까?

그 분야를 고려할 때key두 경우 모두에서 색인화되므로 복잡성 색인 검색 자체가 매우 유사합니다.의 가치로서a해시되고 인덱스 트리에 저장됩니다.

전체적인 성능 비용을 고려할 경우 해시된 버전의 가치를 해시하는 데 필요한 추가 비용(미소)이 발생할 수 있습니다.a인덱스 트리의 값을 일치시키기 전에.mongo/db/index/hash_access_method.h도 참조하십시오.

또한 해시된 인덱스는 인덱스 접두사 압축(WiredTiger)을 사용할 수 없습니다.인덱스 접두사 압축은 카디널리티가 낮은 데이터 세트(예: 국가) 또는 전화 번호, 사회 보장 코드 및 지역 좌표와 같은 반복 값을 가진 데이터 세트에 특히 효과적입니다.특히 첫 번째 필드가 두 번째 필드의 모든 고유 값으로 반복되는 복합 인덱스에 효과적입니다.

순서가 지정되지 않은 필드에서 해시를 사용하지 않을 이유가 있습니까?

일반적으로 비범위 값을 해시할 이유가 없습니다.샤드 키를 선택하려면 값의 카디널리티, 빈도 및 변화율을 고려합니다.

해시된 인덱스는 일반적으로 특정 셰이딩 사례에 사용됩니다.샤드 키 값이 단조롭게 증가/감소하는 값인 경우 데이터 분포는 한 샤드에만 들어갈 수 있습니다.여기서 해시된 샤드 키를 사용하여 쓰기 분산을 개선할 수 있습니다.이는 샤딩 클러스터를 크게 개선하기 위한 작은 절충안입니다.해시드 대 원거리 샤딩을 참조하십시오.

문서와 함께 임의의 해시나 값을 삽입하고 _id에서 생성된 해시 대신 샤딩에 사용할 가치가 있습니까?

가치가 있는지 여부는 사용 사례에 따라 다릅니다.사용자 지정 해시 값은 해시 값에 대한 모든 쿼리가 사용자 지정 해시 코드(예: 응용 프로그램)를 거쳐야 함을 의미합니다.

내장 해시함수를 활용하는 장점은 MongoDB가 해시 인덱스를 사용하여 쿼리를 해결할 때 해시를 자동으로 계산한다는 것입니다.따라서 애플리케이션은 해시를 계산할 필요가 없습니다.

특정 유형의 사용에서는 인덱스가 더 작아집니다!

네! 다음 세 가지 조건이 모두 충족되는 매우 구체적인 시나리오입니다.

• 액세스 패턴(검색 방법)은 색인 필드에 대한 특정 값을 가진 문서(예: SKU에서 제품 찾기 또는 ID로 사용자 찾기 등)만 찾아야 합니다.
• 인덱싱된 필드에 대해 범위 기반 쿼리나 정렬이 필요하지 않습니다.
• 필드가 매우 큰 문자열이고 Mongo의 필드 숫자 해시가 원래 필드보다 작습니다.

예를 들어 인덱스를 두 개 만들었는데 해시된 버전의 경우 인덱스 크기가 더 작았습니다.따라서 메모리 및 디스크 사용률이 향상될 수 있습니다.

// The type of data in the collection. Each document is a random string with 65 characters.
{
  "myLargeRandomString": "40a9da87c3e22fe5c47392b0209f296529c01cea3fa35dc3ba2f3d04f1613f8e"
}

이 지수는 일반 버전의 약 1/4입니다!

mongos> use MyDb
mongos> db.myCollection.stats()["indexSizes"]
{
    // A regular index. This one is sorted by the value of myLargeRandomString
    "myLargeRandomString_-1"     : 23074062336,

    // The hashed version of the index for the same field. It is around 1/4 of the original size.
    "myLargeRandomString_hashed" : 6557511680,
}

참고:

이사용중경우를 사용하고 _id당신의 문서에 대한 외부 키로서, 컬렉션이 있을 것이기 때문에 이것은 관련이 없습니다._id기본 인덱스입니다.항상 그렇듯이 데이터를 직접 테스트하여 이러한 변경이 실제로 도움이 되는지 확인하십시오.이러한 유형의 인덱스에 대한 검색 기능 측면에서 상당한 절충이 있습니다.

언급URL : https://stackoverflow.com/questions/28330170/mongodb-performance-difference-between-hash-and-ascending-indices-any-reason-no