작성한 질문수 8

0

동연님, 안녕하세요!

강의 잘 들어주셔서 감사하네요~!

실무에서 트랜잭션 레벨을 조절하기도 합니다!

높은 레벨일수록 일관성을 보장하는 대신 성능을 희생할 수 밖에 없다보니,

트랜잭션이 딱히 중요하지 않은 서비스에서는 read uncommitted 또는 read commited로 낮춰서 운영하기도 합니다!

그 위의 레벨은 제가 직접 경험한건 아니지만, 금융처럼 일관성이 중요한 곳에서는 더 높은 레벨로 제어할 수도 있을 것 같네요. 이러한 도메인에서는 성능에서 손해를 보더라도 데이터 일관성이 깨지지 않는게 더욱 중요할 수 있습니다.

서비스 요구사항과 성능/일관성 트레이드오프 고려해서 실제로 조절하기도 합니다!

0

안녕하세요, 인프런 AI 인턴입니다. 이동연님.

트랜잭션 레벨의 조절에 관한 질문을 주셨군요. 트랜잭션 격리 수준은 데이터베이스의 동시성과 일관성에 직접적인 영향을 미치기 때문에 실무에서는 이 레벨을 전략적으로 조정하는 경우도 있습니다. 다음은 주요한 상황들입니다:

트랜잭션 격리 수준의 종류와 조절 이유

1. Read Uncommitted: 가장 낮은 수준으로, 아직 커밋되지 않은 데이터를 다른 트랜잭션이 읽을 수 있습니다. 주로 성능이 매우 중요한 경우에 사용될 수 있지만, 데이터의 정확성이 중요한 시스템에는 거의 사용되지 않습니다.

2. Read Committed: 대부분의 애플리케이션에서 기본적으로 사용되는 레벨입니다. 커밋된 데이터만 읽기 때문에 Dirty Read가 방지됩니다. 높은 성능과 적당한 데이터 일관성을 보장합니다.

3. Repeatable Read: 동일 트랜잭션 내에서 같은 데이터를 여러 번 읽더라도 동일한 결과를 보장합니다. Phantom Read를 제외한 대부분의 경우에 안전하며 MySQL의 기본값입니다.

4. Serializable: 가장 높은 격리 수준으로, 완전한 일관성을 보장하지만 성능 비용이 상당히 큽니다. 실행 흐름이 거의 직렬화되어 병렬 처리 이점을 상실합니다.

실무에서의 조절 사례

• 갭 락 회피: 만약 특정 작업이 갭 락으로 인해 병목이나 데드락을 야기한다면, Read Committed와 같은 낮은 격리 수준으로 전환하여 성능을 개선할 수 있습니다.

• 트래픽 패턴 변화: 고화된 트래픽에서 데이터 일관성보다는 성능을 중시해야 하는 경우가 있다면 트랜잭션 레벨을 조정하여 처리를 최적화할 수 있습니다.

• 데이터 보호: 민감한 데이터를 다루는 경우에는 격리 수준을 높여 무결성을 보장하는 방법도 선택할 수 있습니다.

위와 같은 실무적 배경에서 트랜잭션 레벨은 조정될 수 있으며 이는 시스템의 요구 사항과 성능 트레이드오프에 따라 결정됩니다. 추가적인 정보는 자료를 참고하시길 바랍니다: 트랜잭션 격리 수준 실무 적용 사례 (게시글 제목).

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.