MongoDB 및 컴포지트 프라이머리 키

MongoDB 및 컴포지트 프라이머리 키

mongo db에 있는 복합 프라이머리 키를 처리하는 최선의 방법을 찾고 있습니다.이 시스템의 데이터와 상호 작용하기 위한 주요 키는 2개의 uuid로 구성됩니다.uuid의 조합은 일의로 보증되지만, 각각의 uuid는 일치하지 않습니다.

이를 관리하는 방법에는 몇 가지가 있습니다.

1. 2개의 값으로 구성된 프라이머리 키에 오브젝트를 사용합니다(여기서 제안).

2. 기본 키로 표준 자동 생성된 mongo 객체 ID를 사용하여 내 키를 두 개의 개별 필드에 저장한 다음 두 필드에 복합 인덱스를 만듭니다.

3. 기본 키를 2개의 uuid의 해시로 만듭니다.

4. 내가 현재 알지 못하는 다른 훌륭한 솔루션

이러한 접근방식의 퍼포먼스에 미치는 영향은 무엇입니까?

옵션 1의 경우 키가 연속되지 않아 삽입 성능이 걱정됩니다.이것이 기존의 RDB를 파괴할 수 있다는 것을 알고 있습니다.MS 시스템과 저는 이것이 MongoDB에서도 사실일 수 있다는 징후를 보았습니다.

옵션 2의 경우 시스템에서 사용하지 않는 프라이머리 키가 있는 것은 조금 이상한 것 같습니다.또한 쿼리 성능이 옵션 1만큼 좋지 않을 수 있습니다.기존 RDBMS에서는 클러스터된 인덱스가 최상의 쿼리 결과를 제공합니다.이것이 MongoDB와 얼마나 관련이 있습니까?

옵션 3의 경우 단일 ID 필드가 하나 작성되지만 삽입 시 순차적으로 작성되지 않습니다.이 접근법에 대한 다른 장단점이 있습니까?

4번 옵션은...옵션 4는 무엇입니까?

또, 장래의 시점에서는, MongoDB 대신에 CouchDB 를 사용하는 것에 대해서도 몇개의 논의가 있습니다.CouchDB를 사용하면 다른 솔루션을 제안할 수 있습니까?

상세 정보: 이 문제에 대한 배경은 여기를 참조하십시오.

옵션 1로 해 주세요.

퍼포먼스가 걱정된다고 하는 주된 이유는 항상 존재하며 이미 고유한 _id 인덱스를 사용하면 두 번째 고유 인덱스를 유지할 필요가 없어지기 때문입니다.

옵션 1의 경우, 순차 키가 아닌 경우 삽입 성능에 문제가 있습니다.이것이 기존의 RDB를 파괴할 수 있다는 것을 알고 있습니다.MS 시스템과 저는 이것이 MongoDB에서도 사실일 수 있다는 징후를 보았습니다.

다른 옵션은 이 문제를 회피하지 않고 _id 인덱스에서 2차 고유 인덱스로 이행할 뿐이지만, 이제 두 개의 인덱스가 있습니다. 하나는 오른쪽 균형이고 다른 하나는 랜덤 액세스입니다.

옵션 1에 의문을 제기하는 이유는 하나뿐입니다. 즉, 하나의 UUID 값 또는 다른 UUID 값으로만 문서에 액세스하려는 경우입니다.항상 두 값을 모두 제공하는 한(이 부분은 매우 중요함) 모든 쿼리에서 항상 동일한 방법으로 값을 주문하면 _id 인덱스는 효율적으로 모든 목적을 충족합니다.

의 UUID 을 항상 같은 비교 시 2개의 UUID 값을 항상 .{ a:1, b:2 }하지 않다{ b:2, a:1 }- _id.- 2개의 에 _id가 포함되어 있는 컬렉션이 수 따라서 _id를 필드 a와 함께 먼저 저장할 경우 모든 문서 및 쿼리에서 항상 해당 순서를 유지해야 합니다.

은 른른의 _id:1할 수 .

db.collection.find({_id:{a:1,b:2}}) 

그러나 쿼리에 사용할 수 없습니다.

db.collection.find({"_id.a":1, "_id.b":2})

옵션 4가 있습니다.

" " 를 합니다._id하나의 복합 인덱스 대신 두 개의 UUID에 대해 2개의 단일 필드 인덱스를 추가합니다.

1. _id 지수의 ).MongoDB쉽게 샤딩할 수 있습니다.MongoDB관리할 수 있습니다.
2. 2개의 UUID 인덱스를 사용하면 필요한 모든 종류의 쿼리(첫 번째 쿼리, 두 번째 인덱스 또는 둘 다 임의의 순서로 사용)를 작성할 수 있습니다.이러한 인덱스는 1개의 복합 인덱스보다 적은 공간을 차지합니다.
3. 쿼리에서 다른 를MongoDB(v2.6의 새로운 기능)이 복합 인덱스를 사용하는 것처럼 교차합니다.

나는 두 가지 옵션을 택할 것이다. 그리고 거기에는 이유가 있다.

1. 첫 번째 제안과 같이 양쪽 uuid에서 연결된 필드가 아닌 두 개의 필드를 가지면 미래의 쿼리 요구를 지원하기 위해 인덱스의 다른 조합을 작성할 수 있습니다.또한 어떤 키의 카디널리티가 다른 키보다 높다는 것이 판명되었을 경우 등입니다.
2. 비순차 키가 있으면 샤드 환경에 삽입할 때 핫스팟을 피할 수 있으므로 그리 나쁘지 않은 옵션입니다.쓰기 잠금이 데이터베이스 수준(2.6 이전) 또는 수집 수준(2.6 버전)이기 때문에 샤딩은 컬렉션의 삽입 및 업데이트를 확장하는 가장 좋은 방법입니다.

저는 2번 선택지를 선택했을 거예요.두 UUID 필드를 모두 처리하는 인덱스를 만들 수 있으며 성능이 복합 프라이머리 키와 동일해야 합니다.단, 조작이 훨씬 쉬워집니다.

또, 제 경험상, 꼭 필요한 것은 아니더라도, 어떤 것에 고유 ID를 부여한 것을 후회한 적은 없습니다.아마도 그것은 인기가 없는 의견일 것이다.

언급URL : https://stackoverflow.com/questions/23164417/mongodb-and-composite-primary-keys