무지를 아는 것이 곧 앎의 시작

db 3

커버링 인덱스와 ICP(index condition pushdown)에 대한 고민

사이드 프로젝트를 할때 특정 검색 기능의 성능이 느려 개선 백로그로 잡아두었었다. 다만, 회사와 기타 일정에 이리저리 치이고 치이다 보니 결국 그 사이드 프젝이 끝날 때까지 건드리지를 못했었는데, 추석 연휴를 맞이해서 갑자기 생각이 났고.. 쉬는 김에 한번 개선해보기로 했다. 개선 시작 검색 성능 개선이 목적이다 보니 해당 쿼리에 인덱스를 태울 생각을 먼저 했고, 기존엔 그 어떤 인덱스도 타고 있지 않던걸 확인했다. 테스트용 DB를 생성해서 다음과 같이 지저분한(..?) 프로시저를 태워 데이터를 적재했다. 테스트용 더미 데이터 insert create table place( -- 테스트 대상 테이블 id bigint auto_increment primary key, name varchar(150) not..

DB 2023.09.30

Serializable로 동시성을 잡으려 하면 데드락을 만납니다

최근 우연찮은 기회로 현업 개발자와 동시성 이슈에 대한 얘기를 할 기회를 얻었다. 동시성 이슈에 대해서 고민해보고 어떤 상황에 어떤 방식으로 해결하는 결론을 내렸는 지 정리된 걸 얘기해 보았는데, 결론은 Serializable을 쓸 일은 없었지만 내가 고민한 과정중에 있었고 지식 교정이 필요한 걸 알게 되었다. 이번 포스팅에선 그 점을 다뤄볼까 한다. DB에 데이터가 공유자원이다. 동시성을 어떻게 해결할거냐? RDBMS라면 일단 낙관락, 비관락 이런걸 해결책으로 떠올릴 수 있고, 여러 저장소와 글로벌 트랜잭션이 필요하다면 Redis로 공유 락을 잡는 방법도 있다. 이건 모범 답안이고, 이런 방법들을 알기 전에 나는 격리 레벨을 Serializable로 설정하면 데이터에 락이 걸려서 트랜잭션간 동시성이 잡..

DB 2022.12.05

DB의 락 기능을 이용해서 동시성 이슈 해결하기 (feat. 우테코 체스미션)

학습 동기 우테코 체스 미션을 하던 도중 한 게임에 대해 동시에 여러 이동 요청이 들어올 시에 발생할 문제점에 대해 피드백 받고 동시성 이슈에 대한 해결법을 찾다 학습. 문제점 상세 설명 체스 DB 구조 체스 미션의 기물 이동 명령은 이동할 기물의 위치와 목적지의 위치를 입력받고 해당 게임의 모든 체스기물을 불러와서 체스 보드를 만든 후에 이동할 수 있는지 도메인 검증을 거친 후 Piece테이블에 game_id와 위치로 조건절 걸고 update 쿼리를 사용하는 방식으로 구현되었다. 만약 동시에 같은 게임에 대해서 이동 명령이 들어온다면 트랜잭션의 독립성 속성에 의해 update 문을 사용하는 두 기물 데이터는 락이 이미 걸려서 뒤에 들어온 트랜잭션이 접근할 수 없지만, 동시에 들어온 두 트랜잭션 작업이 ..

DB 2022.05.24