RDB의 인덱스 구조
•
B-Tree
•
비트맵
•
해시
34강 - 인덱스와 B-tree
Btree류
CREATE INDEX 구문을 실행하면 암묵적으로 B-tree 인덱스가 만들어진다.
⇒ 최강은 아니지만 균형이 잘 잡혀있기 때문에 사용된다
대부분의 DB는 트리의 리프 노드에만 키값을 저장하는 B+tree 라는 B-tree의 수정버전을 채택
btree
•
트리의 깊이가 대개 3-4정도의 수준으로 일정
•
데이터가 정렬 상태를 유지 → 검색비용을 줄인다.
기타 인덱스
비트맵 인덱스
•
데이터를 비트 플래그로 변환해서 저장
•
카디널리티가 낮은 필드에 대해 효과발휘
•
갱신때 오버헤드가 크므로 BI/DWH 용도로 사용
(비지니스인텔리전스/데이터웨어하우스)
해시 인덱스
•
키를 해시 분산해서 등가 검색을 고속으로 실행
•
등가 검색 외에는 효과 거의 없음
•
범위 검색 못함
•
거의 사용 안함
35강 인덱스 활용법
•
비트리의 장점은 범용성
•
데이터양이 증가해도 검색속도가 일정
카디널리티와 선택률
인덱스의 작성고려 기준 == 필드의 카디널리티와 선택률
카디널리티
카디널리티 ⇒ 값의 균형 ⇒ 필드 값의 유일성이 높은 필드
카디널리티가 가장 높은 필드는 유일 키 필드 (유니크)
모든 레코드에 같은 값이 들어가 있다면 ⇒ 카디널리티가 낮은 필드)
선택률
특정 필드값을 지정했을 때 테이블 전체에서 몇개의 레코드가 선택되는지
ex) 100개의 레코드를 가진 테이블에서 pkey=1 등호로 찾으면 레코드 1개
⇒ 1/100 = 0.01 선택률 1%
번외 클러스터링 팩터
•
클러스터화 계수
•
저장소에 같은 값이 어느정도 물리적으로 뭉쳐 존재하는지
◦
높을수록 분산
◦
낮을수록 뭉쳐있음
•
낮을수록 접근할 데이터양이 적어져 좋다.
인덱스를 사용하는게 좋은지 알아보려면?
인덱스를 작성하는 필드 집합의 조건
1.
카디널리티가 높을 것
평균치에서 많이 흩어져 있을수록 좋다
2.
선택률이 낮을 것
한번의 선택으로 레코드가 조금만 선택되는것
선택률이 10%보다 높다면 풀스캔이 더 빠를 가능성이 높음
36강 - 인덱스로 성능 향상이 어려운 경우
인덱스 설계는 테이블 정의와 SQL만으로 판단할 수 없다.
SQL의 검색 조건과 결합 조건을 바탕으로 데이터를 효율적으로 압축할 수 있는 조건을 찾아야한다
⇒ 검색 키 필드의 카디널리티를 알아야한다.
하지만 데이터를 압축할 조건이 해당 SQL 구문에 존재하지 않는다면?
예시
37강 인덱스를 사용할 수 없는 경우 대처법
•
애플리케이션 설정으로 처리
•
인덱스 온리 스캔
1. 외부설정으로 처리
•
UI 설계로 처리
◦
앱에서 제한한다
⇒ 제일 좋은건 개발을 안하는것이다
근데 DB 구조때매 그렇게 한다는게 맞나?
현업에선 이미 굴러가는게 있는 상태에서 붙여서 만들때는 그럴 수 있을것 같다
주의점
성능과 사용성의 트레이드오프
2. 데이터 마트로 대처
•
외부 설정에 영향을 받지 않는 방법
•
개요 테이블 Summary Table
•
원래 테이블의 부분 집합(또는 서브셋)
•
테이블이 클 경우 부분을 자라서 다른 테이블을 만든다
주의점
•
원래 테이블에서 크기를 딱히 줄일 수 없다면 의미가 없다
•
모든 필드를 검색해야할 경우 개선이 불가
3. 인덱스 온리 스캔
SELECT order_id, receive_date
FROM Orders;
SQL
복사
•
커버링 인덱스 작성
CREATE INDEX CoveringIndex ON Orders (order_id, receive_date);
SQL
복사
•
order_id, receive_date 라는 2개의 필드는 일반적으로 인덱스의 필드 후보로 되지 않음
2 필드를 커버하는 인덱스가 존재한다면, 테이블이 아닌 인덱스만 스캔 대상으로 하는 검색이 가능 ⇒ Covering Index
•
Covering Index : 필드의 조합으로 인덱스를 만듦
커버링 인덱스 생성 예시
주의사항
•
DBMS 에 따라 사용 불가능한 경우도 있다 (오래된 버전)
•
한개의 인덱스에 포함 가능한 필드 수 제한
크기에 제한이 있다
여러개의 인덱스를 통합해서 인덱스 온리 스캔을 하기도 한다.
•
갱신 오버헤드가 커진다
필드의 조합이므로, 자체가 큰 인덱스가 될 확률이 높다.
갱신성능이 떨어지는 트레이드 오프
•
정기적인 인덱스 리빌드 필요
◦
검색 성능 자체가 인덱스 크기 의존
•
SQL 구문에 새로운 필드가 추가되면 사용 불가
◦
SELECT 구문에서 사용하는 필드를 모두 커버 못한다면 인덱스가 의미가 없어짐
◦
유지 보수에 약한 타입