Concurrency Behavior: MongoDB vs. Couchbase

다중 사용자 테스트

의 데이비드 글래서 Meteor 쓴 몽고DB 쿼리에서 일치하는 문서가 누락된 블로그 문제 문제가 발생했습니다. MongoDB MMAPv1과 MongoDB WiredTiger 엔진 모두에서 이 문제를 재현하는 것은 간단합니다. 그의 글에서 얻은 결론은 다음과 같습니다(강조는 제 의견입니다).

간단히 말해서...

이 문제는 ID로 문서를 조회하는 쿼리와 같이 인덱스를 사용하지 않는 쿼리에는 영향을 미치지 않습니다.
인덱스 키에 사용된 모든 필드에 대해 명시적으로 단일 값 동일성 일치를 수행하는 쿼리에는 영향을 미치지 않습니다.
문서가 처음 삽입된 후 필드가 수정되지 않는 인덱스를 사용하는 쿼리에는 영향을 미치지 않습니다.
하지만 다른 종류의 몽고DB 쿼리는 일치하는 모든 문서를 포함하지 못할 수 있습니다!

이를 바라보는 또 다른 방법이 있습니다. 몽고DB에서 동시 작업이 진행 중일 때 쿼리가 보조 인덱스(_id가 아닌 다른 인덱스)를 사용하여 두 개의 문서를 검색할 수 있다면 결과가 잘못될 수 있습니다. 이는 많은 데이터베이스 애플리케이션에서 흔히 볼 수 있는 시나리오입니다.

테스트는 다음과 같습니다:

컨테이너를 만듭니다: 버킷, 테이블 또는 컬렉션.
30만 개의 문서와 같은 작은 데이터 집합으로 데이터를 로드합니다.
필터링하려는 필드(술어)에 인덱스를 만듭니다.
한 세션에서 인덱싱된 필드를 업데이트하고 다른 세션에서 쿼리합니다.

MongoDB 테스트

MongoDB에서 문제를 재현하는 단계:

MongoDB 3.2를 설치합니다.
MMAPv1 또는 WiredTiger로 몽고드를 불러옵니다.
tpcc.py를 사용하여 데이터 로드
python tpcc.py -warehouses 1 -no-execute mongodb
카운트 가져오기

> tpcc 사용

> db.ORDER_LINE.find().count();

299890

db.ORDER_LINE.ensureIndex({state:1});

MongoDB 실험 1: 더 높은 값으로 업데이트하기

상태 필드를 aaaaaa 값으로 설정한 다음 이 값을 zzzzzz로 동시에 업데이트하고 필드와 일치하는 두 개의 값['aaaaaa','zzzzzz']을 가진 총 문서 수를 쿼리합니다. 인덱싱된 필드의 값이 낮은 값(aaaaaa)에서 높은 값(zzzzzz)으로 이동하면 이러한 항목은 B-트리의 한쪽에서 다른 쪽으로 이동합니다. 이제 스캔이 중복된 값을 반환하는지, 더 높은 count() 값으로 변환되는지 확인하려고 합니다.

> db.ORDER_LINE.update({OL_DIST_INFO:{$gt:""}}, {$set: {state:"aaaaaa"}}, {multi:true});

WriteResult({ "nMatched" : 299890, "nUpserted" : 0, "nModified" : 299890 })

> db.ORDER_LINE.find({state:{$in:['aaaaaa','zzzzzz']}}).count();

299890

> db.ORDER_LINE.find({state:{$in:['aaaaaa','zzzzzz']}}).explain();

{

"queryPlanner" : {

"plannerVersion" : 1,

"네임스페이스" : "tpcc.ORDER_LINE",

"indexFilterSet" : false,

"parsedQuery" : {

"state" : {

"$in" : [

"아아아아아",

"zzzzzz"

]

}

"winningPlan" : {

"stage" : "FETCH",

"inputStage" : {

"stage" : "IXSCAN",

"keyPattern" : {

"state" : 1

"indexName" : "state_1",

"isMultiKey" : false,

"방향" : "앞으로",

"indexBounds" : {

"state" : [

"["아아아아아", "아아아아아"]",

"["쯔쯔", "쯔쯔"]"

]

}

"rejectedPlans" : [ ]

"serverInfo" : {

"호스트" : "케샤브-맥북-프로-로컬",

"port" : 27017,

"version" : "3.0.2",

"gitVersion" : "6201872043ecbbc0a4cc169b5482dcf385fc464f"

"OK" : 1

}

업데이트 문 1: 모든 문서를 상태 = "zzzzzz"로 설정하도록 업데이트합니다.

db.ORDER_LINE.update({OL_DIST_INFO:{$gt:""}}),

{$set: {상태: "zzzzzz"}}, {multi:true});

업데이트 문 2: 모든 문서를 상태 = "aaaaaa"로 설정하도록 업데이트합니다.

db.ORDER_LINE.update({OL_DIST_INFO:{$gt:""}}),

{$set: {상태: "aaaaaa"}}, {multi:true});

3. 카운트 문: Count documents:(state in ["aaaaaa", "zzzzzz"])

db.ORDER_LINE.find({state:{$in:['aaaaaa','zzzzzz']}}).count();

시간	세션 1: 이슈 업데이트 성명서1 (업데이트 상태 = "zzzzz")	세션 2: 이슈 카운트 명세서를 계속 발행합니다.
T0	업데이트 문 시작	Count = 299890
T1	업데이트 성명 계속	Count = 312736
T2	업데이트 성명 계속	Count = 312730
T3	업데이트 성명 계속	Count = 312778
T4	업데이트 성명 계속	Count = 312656
T4	업데이트 성명 계속	Count = 313514
T4	업데이트 성명 계속	Count = 303116
T4	업데이트 내역 완료	Count = 299890

결과: 이 시나리오에서는 인덱스가 많은 문서를 이중으로 계산하여 실제보다 더 많은 문서를 보고합니다.

원인: B-Tree의 리프 레벨에 있는 데이터가 정렬됩니다. B-Tree가 aaaaaa에서 zzzzz로 업데이트되면 아래쪽 끝에 있는 키가 위쪽 끝으로 이동합니다. 동시 스캔은 이 이동을 인식하지 못합니다. MongoDB는 안정적인 스캔을 구현하지 않고 항목이 들어오는 대로 계산합니다. 따라서 많은 업데이트가 진행되는 프로덕션 시스템에서는 동일한 문서를 두 번, 세 번 또는 그 이상으로 계산할 수 있습니다. 이는 동시 작업에 따라 달라집니다.

몽고DB 실험 2: 낮은 값으로 업데이트하기

역방향 작업을 수행하여 데이터를 'zzzzzz'에서 'aaaaaa'로 업데이트해 보겠습니다. 이 경우 인덱스 항목이 더 높은 값에서 더 낮은 값으로 이동하므로 스캔에서 일부 적격 문서가 누락되어 과소 계수된 것으로 표시됩니다.

시간	세션 1: 이슈 업데이트 성명서2 (업데이트 상태 = "아아아아아")	세션 2: 이슈 카운트 명세서를 계속 발행합니다.
T0	업데이트 문 시작	Count = 299890
T1	업데이트 성명 계속	Count = 299728
T2	업데이트 성명 계속	Count = 299750
T3	업데이트 성명 계속	Count = 299780
T4	업데이트 성명 계속	Count = 299761
T4	업데이트 성명 계속	Count = 299777
T4	업데이트 성명 계속	Count = 299815
T4	업데이트 내역 완료	Count = 299890

결과: 이 시나리오에서는 인덱스가 많은 문서를 누락하고 실제보다 적은 수의 문서를 보고합니다.

원인: 역효과가 발생합니다. 값이 zzzzzz인 키가 aaaaaa로 수정되면 항목이 B-Tree의 상위 끝에서 하위 끝으로 이동합니다. 다시 말하지만, 스캔의 안정성이 없기 때문에 상위 끝에서 하위 끝으로 이동한 키를 놓칠 수 있습니다.

MongoDB 실험 3: 동시 업데이트

두 세션이 인덱싱된 필드를 동시에 지속적으로 업데이트합니다. 이 경우, 이전 관찰에 따르면 각 세션에서 오버카운트 및 언더카운트 문제가 모두 발생합니다. MongoDB는 값을 변경한 업데이트만 보고하기 때문에 nModified 결과가 달라집니다.

그러나 수정된 문서의 총 개수는 299980개를 넘지 않습니다. 따라서 MongoDB는 동일한 문서를 두 번 업데이트하는 것을 방지하여 고전적인 할로윈 문제. 안정적인 스캔이 없기 때문에 이 다중 업데이트 문에서 업데이트된 objectID 목록을 유지 관리하고 동일한 객체가 적격 문서로 나타나면 업데이트를 피하는 방식으로 이 문제를 처리하는 것으로 추정됩니다.

세션 1

> db.ORDER_LINE.update({state:{$gt:""}}, {$set: {state:"aaaaaa"}}, {multi:true});

WriteResult({ "nMatched" : 299890, "nUpserted" : 0, "nModified" : 299890 })