기본 격리 수준이 repeatable read인데, 새로운 프로젝트를 진행한다고 가정했을 때, 해당 격리수준이 필요한가요?
찾아보니까 예전에나 데이터 정합성 맞출때 sbr 방식으로 정합성 맞춰야해서 rr이 기본값이라는데, 요즘 흐름이 어떤지 궁금해졌어요.
이렇게 생각하게 된 이유: 애초에 단일 트랜잭션에서 조회 두 번 할 일이 있나?? 싶어서
돈, 정산 관련된 거 아니면 rr 보다 read committed가 더 좋지 않나 싶은데, 현대 기업들의 방향성이 어떻게 되나요??
무지함에서 나오는 궁금증인 것 같은데, ai는 요즘 자꾸 rr 지향한다고 해서 의심스러워서 글 올립니다...!
+ 또 오라클은 rr이 기본값인것도 궁금해요. 보통 은행권에서 oracle을 많이 쓰는걸로 알고있는데, 그러면 rr 대신 serealize가 기본값이어야하는거 아닌가?? 라는 궁금증도 있슴다. 또, oracle이 rc이면 어느정도 문제를 해결할 수 있다는거 아닌가?? mysql은 왜 rr이지?? 라는 궁금증에서 시작됐어요
오라클은 구조적으로 rr이 불가합니다 mysql은 내부에 추가적인 장치가 존재해서 rr을 구현한걸로압미다
read committed만 쓰는데 아직 이로 인한 동시성 문제를 겪진 못해봤습니다. 클래스가 쪼개져있고 한곳에서 여러곳을 호출하면 단일 트랜잭션에서 같은 데이터를 조회할 일이 생각보다 없진 않더라고요. ex. 같은 회원 아이디로 쿠폰차감 주문생성 등 다양한 회사 및 dbms를 경험한 시니어 레벨에서 답변 가능한 질문이라 제 경험만으론 답변드리기 어렵네요 - dc App
답변 감사합니다! 추가로 궁금한 게 있는데 혹 딘퐁님이 업무 시 사용하는 DB가 MySQL인가요??
@백갤러1(117.110) ㅇㅇ - dc App
@딘퐁 read committed도 실제로 현업에서 쓰이는군요. 답변 감사합니다~~
조회두번하는건 대충 예약 관련 시스템 생각하시면됨. 시간이 빈것을 확인하고 예약을 했더니 누군가 이미 그자리에 예약을 해버린경우 충돌이 생기잖아. RR은 그걸 해결하기위해서 나오는거지
오라클같은대서는 그걸 CAS로 해결하는거고
@밀우 아 얼추 이해했습니다 감사합니다! 말씀해주신 문제는 RR + Gap Lock으로 해결이 될 것 같은데, RC + Unique 조건으로 빠르게 처리하는게 더 좋아보이긴 하네요.
@밀우 밀우님 씻으면서 생각을 해봤는데 이해 한 척을 한 것 같네요ㅎ,,, 답변주신게 어떻게 RR로 해결되는지 이해가 잘 안 되었어요. 해당 문제를 격리 수준으로 해결하려면 serializable 수준이 되어야하지 않나요?? 읽기에서 락을 계속 가지고 있어야 해당 문제가 해결되는 것 같은데, RR로 어떻게 해결이 가능한 지 궁금합니다..!
@백갤러1(117.110) 갭락은 mysql에 있는 특이한 기능이니깐 다른 DB 에선 적용하긴 어렵지. postgresql은 MVCC 버전으로 파악하는데 오라클은 전통적인 방식에 의존할수밖에
@백갤러1(117.110) 뭐 여튼 일반적으로는 시간을 미리 쪼개서 놓는 '충돌 구체화'방식(예를들어 회의실 예약을 10분 단위로 1시간에 6개로 미리 쪼개놓는식으로)으로 해결하는게 전통적인 방식이고, MYSQL처럼 미리 읽을때부터 넥스트키 락을 통해서 존재하지 않지만 해당하는 키를 사용못하게 락걸던건가 JPA나 POSTGRESQL처럼 MVCC 버전으로 비교해서 최종 입력시에 어보트하는 낙관적 동시성 제어방식 사용 등이 있지..
@밀우 정리해보자면, MySQL에서 밀우님이 말해주신 상황을 해결하려면 1) RR + 넥스트 키 락을 통해 미리 락을 걸어놓기 2) 낙관적락 3) Unique 제약 조건 등등의 여러 방법이 있는데, 1번이 그렇게 매력적인 선택지는 아닌 것 같다고 느껴지네요... 점점 Repeatable Read의 장점을 모르겠네요;;
@백갤러1(117.110) 암튼 RR 읽깃수준이 현업에서 필요한건 맞는데 모든 로직에서 필요한건 아니니 어플리케이션에서 각 로직마다 독자적으로 구현하는 방식으로 가는듯. 반복 읽기시마다 맨날 락을 걸어둘 순 없잖음. 성능상의 문제도 있으니..
@밀우 얘기 나눠보니 어느정도 생각 정리가 된 것 같네요. 윗글은 이동 중에 작성해서 두서가 없는데, 답변 해주셔서 감사했습니다!