트랜잭션

트랜잭션 활성화 조건

• Replica Set 또는 Sharded Cluster 환경에서만 가능

  • Standalone인 경우 데이터 무결성을 보장할 수 없고 oplog가 필요 없는 상황이므로, oplog 기반으로 동작하는 트랜잭션을 제공하지 않는다.

• WiredTiger 스토리지 엔진에 한해 동작

ReadConcern / WrtieConcern

• MongoDB를 Replica Set 또는 Sharded Cluster 환경에서 사용하는 경우, 읽기/쓰기 작업에서 일관성 및 가용성 보장 수준을 조정할 수 있다.

• ReadConcern의 경우 읽기 시 Replica Set의 과반수에 데이터가 저장되어 있을 때 데이터를 반환하는 majority 옵션, 특정 인스턴스에서 읽은 즉시 바로 데이터를 반환하는 local 옵션 등이 존재한다.

• WriteConcern의 경우 과반수의 노드에서 로컬 oplog에 변경 사항을 기록했을 때 성공으로 간주하는 majority , 직접 지정한 노드 수만큼 쓰기 작업이 전파되었을 때 성공으로 간주하는 <number> 속성 등이 있다.

Snapshot Isolation

개념

• 트랜잭션 시작 시점의 데이터를 기준으로 스냅샷을 생성한 후 작업을 수행하는 격리 수준

• 트랜잭션 내의 모든 읽기는 동일한 시점의 데이터를 기준으로 수행된다. 이로 인해 REPEATABLE READ 격리 수준이 제공된다.

• 여러 트랜잭션이 동시에 특정 데이터에 접근하여 수정하는 경우, 쓰기 충돌이 발생하여 트랜잭션이 실패할 수 있다.

장점

• Non Blocking Read

  • MVCC 기능을 통해 읽기가 쓰기를 막지 않고 쓰기도 읽기를 막지 않는다.

  • 높은 트래픽이 오가는 환경에서 안정적인 성능을 보인다.

• 읽기 일관성 확보

  • 스냅샷을 생성하는 매커니즘을 통해 여러 컬렉션(ex. Order, Payment ...)을 조인처럼 읽더라도 서로 다른 시점의 데이터가 섞이지 않는다.

• 락 경쟁 감소

  • Read Lock이 거의 없다.

  • 트랜잭션 수가 늘어도 락 경합이 상대적으로 적다.

단점

• Write Skew

  • 서로 다른 Document를 기준으로 한 제약 조건이 깨질 수 있다.

  • 예를 들어 게임 캐릭터의 직업을 여러 가지 가질 수 있지만 항상 한 개 이상이어야 하는 조건이 있다고 한다. 이 때 직업을 제거하려는 두 트랜잭션이 동일하게 스냅샷을 읽었고, 두 개 이상의 직업을 갖고 있어 직업을 제거하였다면 캐릭터가 하나의 직업도 갖고 있지 않은 상태가 되어 문제가 발생하게 된다.

  • MongoDB에서 제공되지 않는 Serializable Isolation Level을 사용해야 이 문제가 해결된다.

• 트랜잭션이 길어질수록 디스크 사용량 증가

롤백

분산 트랜잭션

• WiredTiger

• Sharded Cluster 환경의 경우 트랜잭션 사용 시 2PC를 사용한다. 즉 Coordinator가 각 샤드에 prepare 요청을 보내고 모두 가능하다는 응답을 받은 경우에만 트랜잭션을 커밋한다. 만약 하나의 노드라도 실패 응답을 보내거나 응답이 없다면 롤백한다.