위 책을 읽으면서 머리속에 정리한 글
(이론 서적의 경우엔 제 개인적 주관이 다분이 포함해서 작성합니다.)
1. 서두
1) 인덱스란 : 목차, 색인 but 실질적으로 DB에 저장되는 물리적 구조체
(삭제도 하고 수정도되고, 추가도됨)
※ 그렇다면 Key는 : 데이터 업무규칙을 강화시키기 위해
부여한 각종 무결설에 부합되는 논리적인 개념
2) 인덱스는 '인덱스 구성 전략' 이라는 표현을 쓴다.
- 이를 고민하기 위해서 다음 내용의 정보를 고민해야 한다.
① 엑세스 형태에 대한 정보
② 컬럼 분포도
③ 카디널러티
④ 다른 컬럼과 결합도
⑤ 중요도
3) 인덱스 유형은 아래 종류 + 가 있다
① B-Tree인덱스
② 비트맵(Bitmap) 인덱스
③ B-Tree클래스터 인덱스
④ 해뒤(Hash) 클래스터 인덱스
⑤ 리버스 키 (Reverse key) 인덱스
⑥ 비트맵 조인 인덱스 (Bitmap Join Index)
⑦ 함수기반(Function-based) 인덱스
2. B-Tree 인덱스
1) 구조 :
중간 단계의 Branch Block, 끝에 자료나 RowID가 있는 Leaf Block
2) 특징 :
자료가 많아도 2의 n승으로 나눈다면 생각보다 많지 않다.
10억건의 자료가 있어도 1건 조회시 최대 30번만 트리를 타면 끝
자료 추가시에는 좋다
자료 삭제시에는 해당 영역의 인덱스는 같이 지워지지 않는다.
(그렇다면 수시로 삭제, 추가시 문제가 될수 있다는 이야기임)
⇒ 인덱스 재생성, 자주 삭제되는 컬럼은 인덱스 자제해야함
3) 리버스 키 인덱스(Reverse Key index)
컬럼값의 각 바이트 값을 역전시키는 것(B-Tree의 부분?)
(원래 인접하게 저장해야할 내용을 일부러 멀리 떨어뜨림)
= 연산에 강하다
LIKE, IN에 취약하다 (안된다고 보면 된다)
근데 왜?
3. 비트맵 인덱스(Bitmap)
1) 비트를 이용하여 컬럼값을 저장, 이를 이용해 ROWID를 자동생성함
⇒ 비트에 대해서 연산을 수행할 수 있는 강점이 있음 일종읜 B-Tree임
1) 강점
B-Tree는 컬럼값을 인덱스에도 보관해야함, BITMAP은 이를 개선함
잘 쓰지 않는 여러 컬럼값을 빨리 조회하려면 여러 B-Tree를 생성해야함
비트 자체에 정보가 있어서 뭐
NULL, NOT 부정 조합 쓸수 없는 점 개선
저장공간이 매우 절약된다
NULL, NOT 부정 조합에는 대응되나 LIKE, BETWEEN > < 조회시
비슷한 자료가 같이 보여지기 십상이다
= 빠른데 정확하지 않다? (쓰라는건지 말라는건지)
결론 : = 많이 쓰고, 저장공간이 중요하다면 일부에 한해서 쓴다
4. 함수기반 인덱스(Function Based index)
논리적 컬럼을 인덱스로 생성한 것임
EX)
SELECT ID, PASS
FROM
(SELECT MY_ID AS ID, YOURPASS AS PASS
FROM TB_PLAY_GROUND) A
위처럼 가공된 테이블 A의 컬럼 id, pass 는 논리적 컬럼 이라고 볼 수 있다.
1) 특징
뷰나 위의 논리적 결과에 대해(함수기반 인덱스도 같다고 보고)
산술식, 사용자 지정함수, SQL 제공함수, 패키지 사용가능함
다만 그룹함수(SUM, AVG 등)은 불가함
인덱스 함수 실행(인덱스 생성)후 테이블의 자료가 바뀌면 그 즉시
값의 일관성은 깨진다.
결과가 NULL인 경우 인덱스로 엑세스 불가
사용자 지정 함수를 끌어쓸때 종속성에 주의해야함
옵티마이저 사용불가 상태인 경우 SQL은 실패하고 이를 새로 생성해
가용 상태로 만들던지 아니면 아예 쓸수 없게 조치가 필요함
스칼라 서브쿼리로 표현된 컬럼은 함수기반 인덱스를 생성할 수 없다(?)
SYSDATE, USER, ROWNUM 등의 가상컬럼을 포함한 인덱스는 생성X
2) 추가사항
함수기반 인덱스는 마치 실제뷰처럼 가공된 컬럼의 값을 저장하고 있음
인덱스에 사용된 함수가 변경되었다면 변경된 정보를 ① 재생성 또는
② 쓰지 않음 또는 기존걸 ③ 그대로 제공할 수 있다.
이게 불편한게 아니고 선택의 폭이 넓어진게 아닌가 라는
애드립이 있었음.
3) 좀 불편해보이는 이 함수기반 인덱스를 쓰는곳은
= 함수기반 인덱스를 생성해서 테이블안의 컬럼처럼 쓰겠다
테이블 설계상 발생한 문제에 대해서 고민
(1) 컬럼의 중간 부분만 검색
(SUBSTR을 CREATE 문에 넣어서 컬럼을 만들어버린다.)
(2) 조인 연결고리 컬럼이 대응하지 않은 경우에 대한 해결
(품목에 대한 대, 중, 소분류가 한 테이블에 혼재되어 있는데
이를 함수로 나눠서 다른 컬럼 처럼 보이게 할수 있다?
근데 이건 뭐 컬럼 분류만 잘 되어 있다면 아니라면 컬럼 하나만
추가해서 써도 될듯)
(3) 일자 컬럼이 분할된 경우
(이건 좀 쓰고 싶음, 자바랑 날자 타입 맞출수가 없음
JAVA8에서는 된다는데)
(4) 테이터 타입이 상이한 조인 컬럼
(같은 컬럼인데 테이블별로 다른 타입을 지닐때)
(5) 조인 테이블이 조건에 따라 달라지는 경우
(6) 부모 테이블의 컬럼과 결합
(범위를 줄일수 있는 조건들이 다른 테이블에 흩어진 경우
함수기반 인덱스를 붙여넣고 이를 이용해서 범위를 좁히는 방법)
오류 데이터 검색 문제에 대한 고민(데이터 무결성이 안지켜짐)
(1) 대, 소문자, 공백이 혼재된 컬럼 검색
(2) NULL 값 치환을 위해 미리 인덱스를 만들어 놓을까?
아니면 NVL을 신나게 쓸까?
(3) 접두사(Prefix)를 채워서 검색시
(4) 복잡한 계산 결과를 도출해 내기 위한 방법으로 선택?
(5) 말일, 단가, 율의 검색시
(6) 기간, 컬럼 길이 검색
기타 4가지가 더 있지만 좀 어려운 내용이라 다시 읽게 된다면
공부하도록 하고 PASS
~2장끝
댓글 없음:
댓글 쓰기