2021.08.04 기록장

ToDo

• 알고리즘 문제
• 책 읽기
• 토비의 스프링
• 7월 회고 쓰기

Done

• 책 읽기
• 토비의 스프링

Weekly goal

• 책 읽기
• 토비 스프링 코딩

 

관계형 데이터 베이스 실전 입문

209p.

RDB의 인덱스는 대부분 B+트리로 되어있음

기본 구조는 루트 노드가 리프 노드의 최솟값을 가지고 있는 구조.

테이블의 행의 수와 인덱스의 항목 수가 같음.

트리에서 검색 시 왼쪽에서부터 인덱스 검색을 진행함. 그렇기에 %~ 구조는 풀스캔을해서 인덱스 사용 의미가 없음.

중간 값도 마찬가지

https://www.sunny-son.space/MySQL/RDBMstart11/

212p.

인덱스의 종류

DB설계 시 B+인덱스가 대부분을 차지하지만 특성에 따라 다른 인덱스를 사용할 수 있다. ex) R트리

 

해시 인덱스 :  해시 테이블을 이용한 인덱스, 범위 검색 x, 등가 비교 빠름

전문 검색 인덱스 : 전문 검색 시 사용 가능(근데 이거 쓸 바에 일라스틱 서치가 낫지 않을까?), 검색 방법은 한 단어씩 잘라서 검색하는 N그램, 단어별로 분석하는 형태 분석법

 

R트리 인덱스 : 공간 검색 시 사용됨, 지도 검색

 

함수 인덱스 : where절에 함수를 사용하면 인덱스를 못 탐, 그걸 타기 위한 인덱스

 

인덱스와는 개념이 다른 파티셔닝 : 임의의 키 값으로 그룹을 나눔 ex) 날짜 범위로 파티션을 나눠서 검색에 사용함. 파티션 내부적으로 인덱스가 필요함->로컬 인덱스

 

226p.

인덱스보다 풀스캔이 더 나은 경우는?

인텍스 실행 쿼리의 사용 빈도가 낮은 경우

테이블의 사이즈가 작을 때 (100 이하 등..)

검색 결과가 매우 많은 행을 가져올 때

 

토비의 스프링

 

83p.

컨테이너는 어떻게 자신이 만들 오브젝트가 무엇인지 알고 있을까?

전에도 말했듯이 메타정보를 통해 알 수 있다. 메타 정보는 전용 Reader를 통해 BeanDefinition타입의 오브젝트로 변환된다.

 

90p.

Annotation~Context는 빈 스캐너를 내장하고 있다. 그래서 생성 시 아규먼트로 package 경로 적어주면 빈들을 찾아서 등록함

 

124p.

생성자 DI? 수정자 DI?

뭐가 더 좋을까? 둘 다 장단이 있다. 수정자 DI는 사용자가 몇 개 빼먹을 수 있다. 생성자는 빼먹을 수 없다. 빼먹을 수 없기에 항상 모든 부분을 DI 해줘야 하는 문제가 있다. 테스트를 위해서는 수정자 DI는 남겨두는 것이 좋다.

 

이 둘의 문제를 해결하기 위해 등장한 것이 일반 메서드 DI이다.

생성자와 비슷한 구조의 메서드에 @Autowired를 붙여 사용한다. 생성자와 달리 여러 개의 메서드에 @Autowired를 붙일 수 있다.

오브젝트 생성 후 차례로 호출된다.

 

126p.

list에 DI를 할 수 있다. 같은 타입의 빈을 사용할 때가 있다. 대부분 기능적인 빈인데 이들은 맵이나 배열, 리스트에 @Autowired를 통해 담을 수 있다.

 

@Qualifier는 DI시에 세밀하게 조정이 가능하다 ex) 같은 타입의 빈들이 존재할 때 @Qualifier("main")등을 통해

@Autowired시 알맞게 가져올 수 있다. 새로운 인터페이스에 @Qualifier를 붙여서 사용 가능

 

@Target~~
@Retention~~
@Qualifier
public @interface MainDB{
	String value();
}


@Autowired
@MainDB
DataSource dataSource;

 

135p.

@Configuration에서 @Bean으로 등록한 bean들을 메서드 형태로 선언을 하는데, bean을 서로 사용할 때 메서드를 이용했었는데, 바로 메서드 시그니쳐에 파라미터로 적어서 사용하면 된다.

 

153p.

ApplicationContextAware라는 인터페이스를 구현하면 ApplicationContext을 받을 수 있다.