2021.08.04 기록장
ToDo
- 알고리즘 문제
- 책 읽기
- 토비의 스프링
- 7월 회고 쓰기
Done
- 책 읽기
- 토비의 스프링
Weekly goal
- 책 읽기
- 토비 스프링 코딩
관계형 데이터 베이스 실전 입문
209p.
RDB의 인덱스는 대부분 B+트리로 되어있음
기본 구조는 루트 노드가 리프 노드의 최솟값을 가지고 있는 구조.
테이블의 행의 수와 인덱스의 항목 수가 같음.
트리에서 검색 시 왼쪽에서부터 인덱스 검색을 진행함. 그렇기에 %~ 구조는 풀스캔을해서 인덱스 사용 의미가 없음.
중간 값도 마찬가지
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을 받을 수 있다.