34강. 인덱스와 B-tree
RDB에서 사용하는 인덱스
•
B-tree
•
비트맵
•
해시
1.
B-tree 인덱스
•
데이터를 트리 구조로 저장
•
가장 범용적으로 사용하는 인덱스
•
검색 성능이 뛰어남
◦
루트와 리프의 거리를 가능한 일정하게 유지
◦
트리의 깊이가 대개 3~4 정도의 수준으로 일정
◦
데이터가 정렬 상태를 유지
B+tree
2.
비트맵 인덱스
•
데이터를 비트 플래그로 변환해서 저장
•
카디널리티가 낮은 (중복도가 높은) 필드에 대해 효과적
•
갱신할 때 오버헤드가 큼
3.
해시 인덱스
•
키를 해시 분산해서 등가 검색을 빠르게 실행하기 위한 인덱스
•
범위 검색이 불가능
35강. 인덱스를 잘 활용하려면
1.
카디널리티와 선택률
•
어떤 필드에 대해 인덱스를 작성할 것인지 기준이 되는 요소
•
카디널리티 : 특정 데이터 집합의 고유한 값의 개수
•
선택률 : 특정 필드값을 지정했을 때 테이블 전체에서 선택되는 레코드의 개수를 나타내는 개념
•
클러스터링 팩터
◦
저장소에 같은 값이 물리적으로 어느 정도 뭉쳐있는지를 나타내는 지표
◦
인덱스의 성능을 결정하는 요인
◦
높을수록 분산되어 있고, 낮을수록 뭉쳐있다.
카디널리티가 높고 선택률이 낮은 필드가 좋은 인덱스의 후보다.
36강. 인덱스로 성능 향상이 어려운 경우
•
인덱스 설계는 테이블 정의와 SQL만으로 할 수 없다.
1.
압축 조건이 존재하지 않음 (where 구문이 없음)
2.
레코드를 제대로 압축하지 못하는 경우
•
검색 조건의 선택률이 너무 높은 경우
3.
인덱스를 사용하지 않는 검색 조건
•
LIKE 연산자를 사용하는 경우 인덱스는 전방 일치에만 적용할 수 있다.
•
색인 필드에 연산 혹은 함수를 사용하는 경우
◦
인덱스 내부에 존재하는 값은 col_1이라는 값이지 연산 혹은 함수를 적용한 값이 아니기 때문
•
IS NULL을 사용하는 경우 - 일반적으로 색인 필드의 데이터에 NULL이 없음
•
부정형을 사용하는 경우
37강. 인덱스를 사용할 수 없는 경우 대처법
1.
외부 설정으로 처리
•
UI 설계로 처리
인덱스를 사용할 수 없거나 압축 조건이 없는 등의 쿼리가 실행되지 않도록 애플리케이션에서 제한하는 방법
2.
데이터 마트로 대처
•
데이터 마트 : 특정한 쿼리(군)에서 필요한 데이터만을 저장하는 원본 테이블의 부분 집합
•
테이블의 크기를 작게 해 I/O 양을 줄이는 것이 목적
3.
데이터 마트 채택 시 주의점
•
데이터 신선도
◦
데이터를 동기화하는 시점에 따라 달라짐
◦
데이터 신선도가 중요한 경우라면 (= 데이터를 자주 갱신하는 경우) 사용하기 어렵다.
•
데이터 마트 크기
◦
원본 테이블에서 크기를 유효하게 줄일 수 없다면, 데이터 마트를 만드는 의미가 없을 수 있다.
•
데이터 마트 수
◦
데이터 마트는 기능 요건에 의해 만들어지는 엔티티가 아니기에 ER에 나타나지 않고, 따라서 관리하기 어렵다.
◦
수가 늘어날수록 저장소 용량을 많이 차지하고, 백업 또는 스냅샷을 찍을 때의 시간이 오래 걸린다.
◦
필요한 만큼만 만들어야 한다.
•
배치 윈도우
◦
데이터 마트를 만드는데 시간이 걸리므로 이러한 처리를 수행하기 위한 배치 윈도우를 고려해야 한다.
4.
인덱스 온리 스캔으로 대처
•
인덱스 온리 스캔 : SQL 구문에서 필요한 필드를 인덱스만으로 커버할 수 있는 경우에 테이블 접근을 생략하는 기술
•
커버링 인덱스 : 인덱스 온리 스캔을 하기 위해 필요한 필드를 커버하는 인덱스
→ 로우 지향 DBMS에서 컬럼 지향 DBMS를 유사하게 구현하는 것으로 볼 수 있다.
5.
인덱스 온리 스캔의 주의사항
•
사용가능한 DBMS가 한정적
•
포함할 수 있는 필드 수가 한정적
•
갱신 오버헤드가 커진다.
•
정기적인 인덱스 리빌드가 필요
•
SQL 구문에 새로운 필드가 추가되면 사용할 수 없다.
◦
SQL구문에서 사용하는 필드를 모두 커버할 수 없게 되면 더이상 커버링 인덱스가 아니다.