원자성과 트랜잭션
이 페이지의 내용
MongoDB 에서 쓰기 (write) 작업은 작업이 여러 값을 수정하더라도 단일 문서 수준에서 원자적입니다. 여러 업데이트 명령이 동시에 발생하는 경우 각 개별 명령은 쿼리 조건이 여전히 일치하는지 확인합니다.
동시 업데이트 명령이 서로 충돌하지 않도록 업데이트 필터하다 에서 필드 의 예상 현재 값을 지정할 수 있습니다.
예시
이 문서 가 포함된 컬렉션 을 생각해 보세요.
db.games.insertOne( { _id: 1, score: 80 } )
이러한 업데이트 작업은 동시에 발생합니다.
// Update A db.games.updateOne( { score: 80 }, { $set: { score: 90 } } ) // Update B db.games.updateOne( { score: 80 }, { $set: { score: 100 } } )
한 번의 업데이트 작업은 문서의 score
필드 를 90
또는 100
로 설정합니다. 이 업데이트 가 완료되면 두 번째 업데이트 작업은 더 이상 쿼리 조건자 { score: 80 }
와 일치하지 않으며 수행되지 않습니다.
경고
동시 업데이트 작업의 경우 업데이트되지 않는 필드 에 필터하다 를 지정하면 예기치 않은 결과가 발생할 수 있습니다. 예를 예시 다음과 같은 업데이트 작업이 동시에 발생하는 경우를 가정해 보겠습니다.
// Update A db.games.updateOne( { _id: 1 }, { $set: { score: 90 } } ) // Update B db.games.updateOne( { _id: 1 }, { $set: { score: 100 } } )
하나의 업데이트 작업이 완료된 후에도 나머지 작업은 여전히 쿼리 조건자 { _id: 1 }
과 일치합니다. 결과적으로 두 업데이트 작업이 모두 발생하고 저장된 score
값은 두 번째 업데이트 작업을 반영합니다. 이는 첫 번째 업데이트 를 실행한 클라이언트 가 업데이트 를 덮어썼다는 표시를 받지 못하고 score
값이 예상과 다르기 때문에 문제가 됩니다.
업데이트 필터하다 가 업데이트 중인 필드와 다른 필드 에 있을 때 쓰기 (write) 작업이 충돌하지 않도록 하려면 $inc
연산자 를 사용합니다.
예를 예시 다음과 같은 업데이트 작업이 동시에 발생하는 경우를 가정해 보겠습니다.
// Update A db.games.updateOne( { _id: 1 }, { $inc: { score: 10 } } ) // Update B db.games.updateOne( { _id: 1 }, { $inc: { score: 20 } } )
하나의 업데이트 작업이 완료된 후에도 나머지 작업은 여전히 쿼리 조건자 { _id: 1 }
과 일치합니다. 그러나 작업은 score
의 현재 값을 수정하므로 서로를 덮어쓰지 않습니다. 두 업데이트가 모두 반영되고 결과 score
은(는) 110
입니다.
팁
Store Unique Values
필드 에 고유 값만 포함되도록 하려면 고유 인덱스 를 생성할 수 있습니다. 고유 인덱스는 삽입 및 업데이트로 인해 중복 데이터가 생성되는 것을 방지합니다. 여러 필드에 고유 인덱스 를 생성하여 필드 값 조합이 고유하도록 할 수 있습니다. 예제는 고유 인덱스 생성을 참조하세요.
다중 문서 트랜잭션
단일 쓰기 작업(예: db.collection.updateMany()
)이 여러 문서를 수정하는 경우 각 문서의 수정은 원자적이지만 전체 작업은 원자적이지 않습니다.
단일 쓰기 작업이든 다중 쓰기 작업이든 다중 문서 쓰기 작업을 수행할 때 다른 작업과 겹칠 수 있습니다.
여러 문서(단일 또는 여러 컬렉션)에 대한 읽기 및 쓰기의 원자성이 필요한 상황의 경우, 복제본 세트 및 샤딩된 클러스터에서의 트랜잭션을 포함한 분산 트랜잭션을 지원합니다.
자세한 내용은 거래를참조하세요.
중요
대부분의 경우 분산 트랜잭션은 단일 문서 쓰기에 비해 더 큰 성능 비용이 발생하므로 분산 트랜잭션의 가용성이 효과적인 스키마 설계를 대체할 수는 없습니다. 대부분의 시나리오에서 비정규화된 데이터 모델 (내장된 문서 및 배열) 은 계속해서 데이터 및 사용 사례에 최적일 것입니다. 즉, 대부분의 시나리오에서 데이터를 적절하게 모델링하면 분산 트랜잭션의 필요성이 최소화됩니다.
추가 트랜잭션 사용 고려 사항(예: 런타임 제한 및 oplog 크기 제한)은 프로덕션 고려사항을 참조하세요.