Non Repeatable Read는 진짜 문제인가?

Question

안녕하세요. 신입 백엔드 개발자 준비 중인 취준생입니다. 트랜잭션 격리 수준을 공부하는 도중, 트랜잭션 격리 수준이 Read Committed 일 때 발생하는 문제인 Non Repeatable Read 문제가 정말 문제인가? 하는 생각이 들었습니다.이에 대한 고찰을 적어보고 최대한 많은 분들의 의견과 피드백을 받아 보고 싶어 작성을 해보았습니다.일단 제가 이해한 Non Repeatable Read는 하나의 트랜잭션 안에서 서로 다른 시점에 동일한 조회의 결과가 달라지는 경우입니다. 위 문제가 발생하기 위한 전제 조건이 '하나의 트랜잭션 안에서 동일한 조회를 2번 날려야 한다'라고 생각합니다.그런데 실제로 서비스를 개발하면서 이런 상황이 존재하나요? 대부분 한번 조회하고 그 결과를 가지고 다른 처리를 하는 것이 일반적이지 않나요? 아직 경험이 부족해서 그런지 어떤 상황에서 문제가 될지 잘 그려지지 않습니다..아니면 단순히 트랜잭션의 성질 중 하나인 Consistency를 지키지 못하게 되어서 문제로 삼는 것인가요?이것저것 찾아보다가 &#34;조회를 2번 해서 값이 달라져야만 문제가 되는 것은 아니다. 트랜잭션 중간에 다른 트랜잭션에 의해 결과가 달라져 정합성이 일치하지 상황이 생기는 것이 문제다.&#34;라는 댓글을 봤습니다. 그런데 위에서 언급한 문제는 값을 수정할 때는 충분히 문제가 될 수 있다고 생각합니다. 하지만 중간에 다른 트랜잭션에 의해 정합성이 일치하지 않게 되어도, 현재 진행 중인 트랜잭션의 최종 연산까지 해당 내용을 모르고 있으면 문제가 안되지 않나요? 아니면 제가 놓치고 있는 부분이 있을까요? (추가로 위에서 값을 수정할 때의 문제는 트랜잭션 격리 수준과는 별개로 LOCK을 통한 동시성 제어의 개념으로 넘어가야 한다고 생각합니다.)그래서 Non Repeatale Read가 문제가 될만한 다양한 상황을 생각해 봤는데요. 은행에서 대출 심사를 위해 잔액 조회를 하는 경우입니다. 만약 잔액 조회를 하는 도중에 다른 곳에서 입금이 되었다면? 그런데 그 결과가 대출 심사에 영향이 끼쳐야 한다면? 이러한 상황에서는 오히려 Non Repeatable Read는 문제가 되보이지 않습니다. 어쩌면 당연하게도 타 트랜잭션의 결과를 함께 조회해야 한다고 생각합니다. 그런데 만약, 조회 중간에 다른 곳에서 입금한 결과가 대출 심사에 영향을 끼치지 않아야 한다면? 이때는 충분히 Non Repeatable Read가 문제가 될 수 있다고 생각이 됩니다.지금까지 제 생각을쭉 적어보았습니다. 공부 중인 학생이라 모르는 것도 많고 경험도 많이 부족합니다. 남겨주신 댓글을 토대로 많이 배우고 성장하겠습니다.감사합니다.

집킨 · Answer

많은 개발 공부 정리하는 블로그에서 DBMS의 격리 수준에 따른 특성을 문제점이라고 설명하기 때문에 발생하는 흔한 오해죠격리 수준은 하나의 테이블에 대해서 여러 트랜잭션이 동시다발적으로 실행될때 데이터 정합성 vs 성능 사이에서 선택해야하는 일종의 기준입니다각 격리 수준의 특성을 이해하고 현재 내 상황에 적합한 격리 수준을 선택하면 됩니다말씀하신것처럼 Non Repeatable Read 이 어떤 경우엔 문제가 될 수 있지만, 어떤 경우엔 문제가 전혀 되지 않거든요즉, Non Repeatable Read 는 문제점이 아니라 read committed 의 특징입니다오라클은 기본적으로 read committed 입니다mysql은 repeatable read 구요repeatable read 은 상대적으로 read committed 보다 성능이 안좋습니다A트랜잭션에서 데이터를 변경하기 이전의 내용을 undo 영역에 트랜잭션 번호를 부여해서 기록하고 있어야 하고,A트랜잭션에서 커밋이 일어나더라도 undo 영역에 기록한 내용은 A트랜잭션 번호보다 낮은 트랜잭션이 살아 있다면 삭제도 못하거든요하지만 이 모든 이야기도 오라클, mysql 에 한정해서 말씀드린거고 다른 dbms 종류에 따라 또 이야기는 달라질 수 있습니다그래서 이런 궁금증을 완벽히 해결하려면 다양한 DBMS를 좀 더 깊게 공부해볼 필요가 있죠

MungGaeDev · Answer

아주 아주 아주 많이 일어나지 않나요..? 물론 이걸 막기 위해 수 많은 서비스 로직이 짜여있습니다. 은행에서 대출 심사를 위해 잔액 조회를 하는 경우1차적으로 조회를 하기 위해 조회해오고 트랜잭션을 종료합니다.이후 다시 요청을 보낼 때 다시 한번 조회 + 검증을 한 후 나머지 처리를 합니다. 비슷한 예시가 쇼핑몰에서 주문할 때 입니다.사용자가 상품 화면에서 재고를 확인 한 후 주문할 때 다시 재고가 있는지 조회하고 주문 처리 합니다.

Non Repeatable Read는 진짜 문제인가?

2개의 답변

#non-repeatable-read 목록