v0o0v blog

4.4장 서브쿼리 조인 4.4.1 서브쿼리 변환이 필요한 이유 서브쿼리의 종류 인라인 뷰 : FROM 절에 사용한 서브쿼리 중첩된 서브쿼리 : 결과집합을 한정하기 위해 WHERE 절에 사용한 서브쿼리. 서브쿼리가 메인쿼리 컬럼을 참조할 때 상관관계 있는(Correlated) 서브쿼리라고 한다. 스칼라 서브쿼리 : 한 레코드당 정확히 하나의 값을 반환하는 서브쿼리. 주로 SELECT 절에 사용하지만 컬럼이 올 수 있는 대부분 위치에 사용가능. 메인쿼리도 하나의 쿼리 블록이며 옵티마이저는 쿼리 블럭 단위로 최적화 수행. 하지만, 서브쿼리별로 따로 최적화했다고 해서 전체 쿼리가 최적화 됐다고 할 수 없기 때문에 전체를 바라보는 관점에서 쿼리를 이해하려면 서브쿼리는 풀어내야 한다. 4.4.2 서브쿼리와 조인 메..

3장 인덱스 튜닝 3.3 인덱스 스캔 효율화 3.3.5 인덱스 선행 컬림이 등치(=) 조건이 아닐 때 생기는 비효율 인덱스 스캔 효율성은 인덱스 컬럼을 조건절에 모두 등치(=) 조건을 사용할 때 가장 좋다. 3.3.6 BETWEEN을 IN-List로 전환 선행 조건이 BETWEEN으로 비효율이 발생할 때 In-List로 바꿔주면 큰 효과를 얻을 수도 있다. 이때 주의 할 점은 IN-List 개수가 많지 않아야 한다.(수직적 탐색이 많아 질 수 있음) 3.3.7 Index Skip Scan 활용 BETWEEN을 IN-List로 변환하는 것 대신 Index Skip Scan을 활용하는 방법도 있다. 3.3.8 IN 조건은 '=' 인가 IN 조건은 '='이 아니다. 3.3.9 BE..

3장 인덱스 튜닝 3.1 테이블 엑세스 최소화 SQL 튜닝은 랜덤I/O를 줄이는 것. 랜던I/O를 최소화 하는 방법을 알아보자. 3.1.1 테이블 랜덤 액세스 아무리 데이터가 많아도 인덱스를 사용하면 금방 조회된다 어쩔때는 테이블 전체를 스캔하는 것보다 인덱스가 더 느릴때도 있다. 왜 그럴까? 이 질문에 대한 대답을 찾아보자. 인덱스를 사용하는 이유는 ROWID(테이블에 있는 레코드를 찾기 위한 주소값)를 얻는데에 있다. 즉 인덱스를 사용하면 데이터가 실제로 있는 물리 주소가 아닌 물리 주소를 찾을 수 있는 주소를 얻는다. 반대로 테이블 Full Scan 시에는 직접적인 물리 주소를 얻기 때문에 위와 같은 문제점들이 나타난다. ROWID 논리적 주소(즉 메모리 주소가 아니다) 디스크 상에서 테이블 레코드..

2장 인덱스 기본 인덱스 구조 및 탐색 데이터를 찾는 두 가지 방법 테이블 전체 스캔 인덱스 이용 온라인 트랜잭션 처리에서는 소량의 데이터를 찾기 때문에 인덱스를 사용하고 인덱스 튜닝이 중요하다 SQL 튜닝은 랜덤 I/O와의 전쟁 인덱스는 대부분 B-Tree 수직적 탐색 : 인덱스 스캔 지점을 찾는 과정 수평적 탐색 : 데이터를 찾는 과정 인덱스는 필터링이 아니다. 결합인덱스를 사용할 때 주의 사항. 인덱스 기본 사용법 색인이 정렬되어 있더라도(인덱스라도) 가공한 값이나 중간값으로는 스캔 시작점을 찾을 수 없다. Index Range Scan 인덱스 컬럼이 가공되면 전체를 스캔할 수 밖에 없다. Index Full Scan 인덱스를 range scan 하기 위한 가장 첫번째 조건은 인덱스 선두 컬럼이 조..

1장 SQL 처리 과정과 I/O 1.1 SQL 파싱과 최적화 SQL : Structured Query Language 구조적 질의 언어 구조적 / 집합적 / 선언적 원하는 결과집합은 구조적/집합적으로 선언 결과집합을 만드는 과정은 절차적 => 프로시저 필요 프로시저를 최적화 하는 것이 옵티마이저 또한 이 과정을 SQL 최적화라고 함 SQL 최적화 SQL 파싱 -> SQL 최적화 SQL 옵티마이저 사용자가에게 전달 받은 쿼리를 실행할 후보군 선정 후보군 중 가장 최저 비용을 나타내는 실행계획 선택 옵티마이저 힌트 자동으로 옵티마이저를 하지만 사용자가 힌트를 주어 의도적으로 다른 실행계획을 선택 할 수 있게 함 SQL 공유 및 재사용 소프트 파싱 / 하드 파싱 캐시되어 있지 않은 경우 SQL 파싱, 최적화,..

12 아키텍처 스타일 결정하기 지금까지 육각형 아키텍처를 사용해서 웹 어플리케이션을 만드는 방법을 살펴봤다. 그렇다면 언제 육각형 아키텍처 스타일을 사용해야 할까? 도메인이 왕이다 육각형 아키텍처 스타일을 사용할지 첫번째 지표 : 도메인 코드가 애플리케이션에서 가장 중요한 것인가? 육각형 아키텍처 스타일은 결국 영속성 관심사나 외부 시스템에 대한 의존성 등의 변화로부터 자유롭게 도메인 코드를 개발 할 수 있다는 것 외부의 영향을 받지 않고 도메인 코드를 자유롭게 발전시킬 수 있다는 것은 육각형 아키텍처 스타일이 내세우는 가장 중요한 가치 이것이 육각형 아키텍처 스타일이 도메인 주도 설계 방식과 정말 잘 어울리는 이유 DDD에서는 도메인이 개발을 주도하고 도메인 외 다른 기술들을 생각할 필요가 없게 되면 ..

06 영속성 어댑터 구현하기 데이터베이스 주도 설계를 피하기 위해 영속성 계층을 앱 계층의 플러그인으로 만들어보자. 의존성 역전 앱은 영속성 기능 사용하기 위해 포트 호출. 이 포트는 영속성 어댑터에 의해 구현.(DIP) 육각형 아키텍처에서 영속성 어댑터는 앱에서 호출하기 때문에 아웃고잉 어댑터 포트는 앱과 영속성 사이의 간접적 계층 영속성 문제에 신경쓰지 않고 도메인 코드 개발 영속성 계층에 코드 의존성을 없앤다 영속성 코드를 변경하더라도 코어 코드에 영향이 없다 DIP로 인해 정적인 상황에서는 의존성이 역전되었지만 동적인 타임에는 여전히 앱이 영속성 코드에 의존하고 있다. 하지만 인터페이스 계약을 만족하는 한 영속성 코드 수정은 문제가 없다. 영속성 어댑터의 책임 영속성 어댑터가 일반적으로 하는 일...

02 의존성 역전하기 2장에서는 1장의 계층형 아키텍처의 문제점에 대한 대안에 대해 얘기한다. 단일 책임 원칙 Single Responsibility Principle(SRP) 하나의 컴포넌트는 오로의 한가지 일만 해야 하고, 그것을 올바르게 수행해야 한다. 라고 알고있지만 사실 실제 정의는 컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다. http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod 아키텍처에서 가지는 의미 : 다른 이유로 변경된다면 이 컴포넌트는 안 변한다. 그런데... SRP를 따르다보니 변경할 이유가 컴포넌트 간의 의존성을 통해 너무 쉽게 전파된다. E에 비해 A는 의존성 때문에 변경할 확률이 높다. 시간이 갈수록 바꿀건 많아지는데..

ArchUnit을 이용한 패키지 의존성 테스트하기 최근 클린아키텍처 스터디를 하면서 헥사코날 아키텍처를 테스트 하는 것에 대한 논의가 있었다. 여러 논의가 오갔고 이상적인 것은 테스트를 자동화하는 것이었다. 책에 나온 ArchUnit 으로 해당 테스트를 자동화 하는 것을 찾아보았다. ArchUnit https://www.archunit.org/ ArchUnit is a free, simple and extensible library for checking the architecture of your Java code using any plain Java unit test framework. Maven & JUnit5 com.tngtech.archunit archunit-junit5 0.23.1 test ..

DSM(Dependency Structure Matrix) 프로젝트를 진행 할 때 정적으로 아키텍처를 점검해야 하는 경우가 종종 있다. 이때 여러 툴을 사용하는데 DSM을 사용하면 모듈간의 의존성을 한눈에 확인할 수 있다. DSM 이란? DSM은 모듈간의 관계를 2차원 매트릭에 나타낸 테이블. 테이블을 통해서 모듈간의 의존관계 / 의존강도 / 순환사이클 등을 확인할 수 있다. DSM 보는 방법 위 모듈에서 왼쪽 모듈에 X번 의존한다 A는 C에 의존한다. C는 A/B에 의존한다. 열과 행을 포개었을때 둘 다 값이 있으면 순환의존이다 C -> A -> C 포개었을 때 둘다 값이 있다는 뜻은 서로 간에 의존이 있다는 뜻이기 때문에 순환 의존관계이다. 의존 숫자가 유독 높다면 의존이 너무 많이 몰려있다는 뜻이다..