전체 글

회사에서 개발을 진행하면서 옵티마이저가 최적이라고 생각하는 실행 계획과 실제 최적의 실행 계획은 종종 차이가 있다는 것을 알게 되었다.이때, 내가 진행했던 개선 방향은 해당 테이블에 대해 이미 존재하는 다른 인덱스로 변경하여 개선 가능한가?인덱스를 수정하거나 새로 추가하여 개선 가능한가? 1번으로 해결 가능한 부분은 SQL에 액세스 방식이나 조인 순서, 조인 방식 대한 Hint를 추가하여 개선을 진행했고,1번으로 해결이 불가능한 경우 즉, 2번의 경우에는 인덱스의 순서를 변경하거나 구성 컬럼을 변경하는 작업을 진행했다. 해당 글에서는 1번의 케이스에 적용한 옵티마이저 힌트에 대해서 간단하게 정리하고자 한다. 옵티마이저 Hint오브젝트 통계와 시스템 통계 정보를 바탕으로 최적의 프로시저를 만드는 옵티마이저..

프로젝트를 진행하던 중, 속도가 느린 쿼리들을 실행계획을 분석하여 추출한 경험이 있다.실행계획에서 중요한 것은 올바른 인덱스를 타고 있는지, Cost가 비정상적으로 높은지 등을 확인했다. 해당 작업을 진행하면서  Cost는 어떤 방식으로 계산되는지 궁금하여 찾아본 것을 여기에 정리하고자 한다.옵티마이저의 통계 정보의 경우 각각을 외우기보다는 실행계획에서의 Cost가 어떠한 값을 기반으로 계산된 것인지 참고하는 정도로 러프하게 생각해야 할 것 같다. 선택도와 카디널리티우선, 옵티마이저가 처음으로 계산하는 카디널리티가 무엇인지 선택도와 함께 알아보자. 1.  선택도 (Selectivity)데이터에서 특정 값을 얼마나 잘 선택할 수 있는지에 대한 지표이다.선택도는 낮을수록 인덱스 설정에 좋은 컬럼이다.선택도 ..

해당 글을 작성하게 된 계기는 발급할 수 있는 쿠폰의 개수가 한정되어 있고, 현재까지 발급된 쿠폰의 수에 따라 선착순으로 쿠폰을 발급해야 하는 경우 어떻게 동시성을 처리할 수 있을까에 대한 호기심이었다.우선 상황은 이러하다.서버가 여러 개로 싱글 스레드로 해결 불가능하다.서버가 1대인 상황이더라도, 선착순 쿠폰 생성 전체 로직을 싱글 스레드로 처리하는 것은 매우 비효율적이다.Redisson의 RLock과 같은 방법은 현재 상황에 비효율적이다. 먼저 2번, 3번이 비효율적인 이유는 아래와 같다. (RLock에 대해서는 다음 포스팅을 참고해 주세요!)  쿠폰의 재고를 파악하고 재고가 남아있으면 신규 쿠폰을 생성한다라는 관점에서 굳이  재고조회부터 저장까지의 로직을 Lock 과정을 통해 처리한다면 Lock이 ..

최근 프로젝트에서 분리되어 있는 여러 DB에 대해 2 Phase Commit을 적용해야 하는 일이 생겨 정리하게 되었다.설명을 시작하기에 앞서, 간단하게 분산 트랜잭션에 대해 얘기하고 넘어가겠다.분산 트랜잭션은 글로벌 트랜잭션이라고도 하며, 통합되어 관리되는 여러 개의 트랜잭션 묶음을 의미한다.이때, 1️⃣ 분산 트랜잭션에 포함되는 트랜잭션은 서로 동일한 DB에 존재할 수도 있고, 2️⃣ 서로 다른 DB에 존재할 수도 있다.XA Datasource와 2 Phase Commit 이란?XA는 2 Phase Commit을 통한 분산 트랜잭션 처리를 위해 X/Open에서 정의한 표준이다.분산 트랜잭션에서 사용되는 각각의 DB에는 하나의 XA Datasource가 존재하고, 이 XA Datasource가 XA C..

CQRSCQRS는 Command Query Responsibility Segregation 의 약자이며,Command(명령)과 Query(쿼리)의 책임 분리라는 의미를 가지고 있다. Query는 SQL Query를 의미하는 게 아니다. 그럼, Command와 Query는 각각 무엇을 의미할까?Command (명령)애플리케이션의 데이터를 변경 ( 예약, 예약취소)Query (쿼리)애플리케이션의 데이터를 조회 (예약내역 조회) 따라서, CQRS를 다시 설명하자면애플리케이션 데이터를 변경하는 명령 역할을 수행하는 구성 요소애플리케이션 데이터를 조회하는 쿼리 역할을 수행하는 구성 요소이 두 가지를 분리하는 것을 의미한다. 다루는 코드 영역의 차이Command와 Query는 다루는 데이터의 영역의 크기가 다르다...

이전에 진행했었던 데브톡이라는 상담 애플리케이션 예제와 함께 Micro Service 내부 구성에 대해 간략하게 애기해보겠다. 1. 상담 Aggregate 예시로 가져온 상담 애플리케이션에 대해 간단하게 설명하겠다. 액터는 상담사, 내담자로 구성되며 현재 가져온 예시는 상담 매칭 Micro Service를 대상으로 한다. Consultation이라는 도메인 Entity는 아래와 같이 구성되어 있다. 상담이라는 Aggregate는 상담 등록, 수정, 취소, 리뷰 작성에 대한 책임을 갖고 있으며, 여러 Entity와 관계를 가지고 있다. 헥사고날 아키텍처를 엄격하게 따르자면 JPA Entity와 POJO Entity를 구분하는게 맞지만, JPA는 어노테이션 기반으로 그렇게 도메인에 대한 이해를 방해한다고 생..