v0o0v blog

엔티티 매니저는 트랜잭션 별로 생성된다(스프링 기본). 엔티티 매니저는 영속성 컨텍스트를 가지고 있고 1차 캐시의 역할을 하게 된다. 이로 인해 애플리케이션 수준의 반복 가능한 읽기가 가능하다(DBMS의 Repeatable Read와 별개로). 이를 위해 엔티티매니저를 통해 읽기를 할 때 1차 캐시에 이미 해당 영속성 객체가 있다면 DB에서 조회하지 않고 이를 반환한다. 또한, JPQL을 통해 쿼리를 하면 영속성 컨텍스트를 확인하지 않고 바로 DB에서 가져오는데 가져온후에 영속성 컨텍스트에 이미 해당 객체가 있다면 DB에서 가져온 객체를 버리고 영속성 컨텍스트에 있는 값을 반환한다. 영속성 컨텍스트에는 1차 캐시와 쓰기 지연 SQL 저장소가 있다. flush를 할 때 쓰기 지연 SQL에 있는 쿼리가 발생..

Vaadin - Component Vaadin은 40개 이상의 컴포넌트를 지원한다. https://vaadin.com/docs/latest/components 각 컴포넌트는 custom element로 만들어지기 때문에 자바 코드가 아닌 클라이언트 사이드의 HTML로 컴포넌트를 추가 할 수 있다. Vaadin에서 제공하는 컴포넌트 외에 커스텀 컴포넌트를 만들어 사용할 수도 있다. 예를 들어 네이버맵 같은 라이브러리를 컴포넌트화 해서 사용할 수 있다.(이건 다음에 다른 꼭지로..) https://vaadin.com/docs/latest/create-ui/web-components Vaadin에서 제공하는 컴포넌트는 Vaadin의 테마 기능을 사용할 수 있다. 이 말은 내가 만든 테마를 추가해서 웹화면 전체..

Vaadin - Layout Layout Vaadin의 화면을 구성하기 위해서는 기본적으로 Layout을 알아야 한다. Layout 위에 컴포넌트가 구성되어 컴포넌트는 그 레이아웃의 특성에 맞게 배치된다. 또한 레이아웃 자체도 컴포넌트이기 때문에 레이아웃 안에 레이아웃을 추가할 수 있다. 그렇기 때문에 Vaadin에서 제공하는 여러 레이아웃의 조합을 통해 다양한 화면 구성이 가능하다. 기본 Layout DIV : HTML DIV 태그를 그대로 표현 Vertical : 내부 Component를 수직적으로 나열 @Route("basic-layouts/vertical-layout") public class BasicLayoutsVerticalLayout extends Div { public BasicLayou..

Vaadin - Intro Site : https://vaadin.com/ Overview 자바만으로 웹 앱을 제작 할 수 있다. 스프링 부트와 좋은 궁합을 보여준다. 개인이 쓰기에는 조금 비싼 가격이지만 Core Plan은 무료이고 Vaadin의 핵심 프레임워크라고 할 수 있는 Flow는 오픈소스이다. 또한 무수히 무료 Add-On들이 제공된다. 백엔드 개발자가 간단하게 관리자툴을 제작할 때 적절하다. 국내 자료가 거의 없다. 단 한권의 국내 서적. 그나마도 2017년에 나온 8버전. 현재 23버전. Get Started Vaadin 홈페이지에서 제공하는 퀵스타트 프로젝트를 통해서 간단하게 알아보자. https://vaadin.com/docs/latest/guide/quick-start Vaadin은 ..

9장 ItemWriter -2 그밖의 출력 방식을 위한 ItemWriter ItemWriterAdaptor 기존 서비스를 ItemWriter로 사용하고자 할 때 사용. Write 대상이 기존 서비스이고 메소드 인자 타입이 아이템 타입을 그대로 사용할 수 있는 경우. 따라서, 처리중인 아이템 타입 하나의 인수만 받을 수 있다. 다른 인수 추가할 경우 아래와 같은 예외 발생 java.lang.IllegalArgumentException: No matching arguments found for method: logCustomer @Service public class CustomerService { public void logCustomer(Customer customer) { System.out.print..

7장 ItemReader - 1부 (~json) 청크 기반 스텝은 ItemReader - ItemProcessor - ItemWriter 로 구성. 스프링 배치는 거의 모든 유형의 입력 데이터를 읽을 수 있는 기반 코드를 제공함과 동시에 커스터마이징 할 수 있는 기능도 지원함. 7장에서는 ItemReader가 제공하는 다양한 기능을 알아본다. ItemReader 인터페이스 public interface ItemReader { @Nullable T read() throws Exception, UnexpectedInputException, ParseException, NonTransientResourceException; } 스프링 배치는 처리할 입력 유형에 맞는 ItemReader의 여러 구현체 제공 스텝..

5장 JobRepository와 메타데이터 Job Repository 상태관리 : 잡의 상태를 Repository에 저장 배치 잡 실행 중 오류 발생 시 복구 실행 중 오류 발생 시 처리 유무 잡이 다시 실행되면 상태 트랙킹 잡의 재시작 및 아이템 재처리 시 동작 수행 결정 모니터링 실행 중 값 파악 잡 처리 시간/ 오류로 재시작 된 아이템 수 등 잡의 실행 진행 파악 JobRepository 란? JobRepository Interface Source public interface JobRepository { /** * Check if an instance of this job already exists with the parameters * provided. * * @param jobName the ..

7.1 통계정보와 비용 계산 원리 7.1.1 선택도와 카디널리티 선택도 : 전체 레코드 중 조건절에 의해 선택되는 레코드 비율 '=' 조건으로 검색 할 때 경우 선택도 = 1 / NDV NDV : 컬럼값 종류 개수(성별이라면 남/여 2) 카디널리티 : 전체 레코드 중에서 조건절에 의해 선택되는 레코드 개수 카디널리티 = 총 로우 수 * 선택도 = 총 로우 수 / NDV *옵티마이저는 카디널리티 값을 통하여 비용을 산출하고 비용을 통하여 옵티마이징 방식을 결정한다. 따라서 카디널리티값의 기초가 되는 선택도 값의 계산이 매우 중요하다. 7.1.2 통계정보 오브젝트 통계 테이블 통계 테이블 통계 조회 select num_rows -- 총 레코드 계수 ,blocks -- 테이블 블록 수 = &#3..

6장 소트 튜닝 6.1 기본 DML 튜닝 DML 성능에 영향을 미치는 요소 인덱스 인덱스가 늘어나면 Insert / Delete / Update 시 부하가 늘어난다. 특히 Update 시에는 변경과 인덱스 수조 내에서 정렬을 다시해야 하는 이중적인 부하가 발생한다. 무결성 제약 무결성 제약 중 PK/FK 제약은 Check / Not Null 보다 성능에 더 큰 영향이 있다. 실제 데이터를 조회하기 때문이다. 조건절 2/3장에서 학습한 인덱스 튜닝 원리 참고. 서브쿼리 4장에서 학습한 조인 튜닝 원리 참고. Redo 로깅 DML 수행 시마다 Redo 로그 생성하기 때문에 DML에 성능에 영향을 끼친다. Undo 로깅 DML 수행 시마다 Undo 로그 생성하기 때문에 DML에 성능에 영향을 끼친다. Lock..

5장 소트 튜닝 5.1 소트 연산에 대한 이해 소트 수행 과정 소트 연산은 메모리와 CPU를 많이 쓴다. 처리할 양이 많을 때는 디스크 I/O를 사용하기도 한다. 부분범위 처리가 불가해서 OLTP 환경에서 앱 성능을 저하시킨다. 따라서, 되도록 소트를 안하도록 SQL를 작성하고 불가피할경우 메모리내에서 수행이 완료되도록 한다. 소트 오퍼레이션 Sort Aggregate 실제 데이터를 정렬하진 않고 Sort Area 사용 SUM / MAX / MIN / COUNT Sort Order By 실제 소트 실행 Sort Group By 소팅 알고리즘을 사용해 그룹별 집계 수행 Sort Unique Unnesting된 서브쿼리가 M쪽 집합이면 메인 쿼리와 조인하기 전에 중복 레코드 제거 Sort Join 소트 머지..

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 파싱, 최적화,..