인덱스란?
인덱스란 추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조입니다.
DBMS는 index를 항상 최신의 정렬된 상태로 유지해야 원하는 값을 빠르게 탐색할 수 있습니다. 그렇기 때문에 인덱스가 적용된 컬럼에 INSERT, UPDATE, DELETE가 수행된다면 아래와 같은 추가적인 작업이 필요해 오버헤드가 발생합니다.
-
INSERT: 새로운 데이터에 대한 인덱스를 추가합니다.
-
DELETE: 삭제하는 데이터의 인덱스를 사용하지 않는다는 작업을 진행합니다.
-
UPDATE: 기존의 인덱스를 사용하지 않음 처리하고, 갱신된 데이터에 대한 인덱스를 추가합니다.
인덱스의 장단점
장점
-
테이블을 조회하는 속도와 그에 따른 성능을 향상시킬 수 있습니다.
-
전반적인 시스템의 부하를 줄일 수 있스니다.
단점
-
인덱스를 관리하기 위해 DB의 약 10%에 해당하는 저장 공간이 필요합니다.
-
인덱스를 관리하기 위해 추가 작업이 필요합니다.
-
인덱스를 잘못 사용할 경우 오히려 성능이 저하되는 역효과가 발생할 수 있습니다.
인덱스를 사용하면 좋은 경우
-
규모가 작지 않은 테이블
-
INSERT, UPDATE, DELETE가 자주 발생하지 않는 컬럼
-
JOIN, WHRER, ORDER BY 등이 자주 사용되는 컬럼
-
데이터 중복도가 낮은 컬럼
인덱스의 종류
클러스터드 인덱스
-
인덱스와 데이터가 군집해서 저장됩니다.
-
인덱스를 기준으로 데이터를 재배열 합니다.
-
테이블당 1개만 존재 가능합니다.
-
제약조건 시 자동 생성됩니다.
-
primary key (1순위)
-
unique + not null
❗ 클러스터드 인덱스를 학습하며
인덱스와 데이터가 군집하고 순서를 보장하며 저장하는 것까지 배우면서 어떻게 검색을 할지 궁금했습니다.
순서를 보장했기 때문에 Binary-Search처럼 찾지 않을까 했지만 아니었습니다.
B-Tree 형태로 데이터를 저장하는 페이지, 즉 리프 페이지에 순서를 보장하며 군집하게 데이터를 저장하고 리프 페이지 데이터 중 최상단 데이터를 가지고 있는 루트 페이지를 통해 검색을 합니다.
페이지의 크기는 DB마다 다르고 페이지에 공간이 없다면 페이지 분할이 이루어진다. -> DB 성능에 영향
논-클러스터드 인덱스
-
별도의 인덱스 페이지 생성이 필요합니다.
-
테이블당 여러 개 존재가 가능합니다.
-
리프 페이지에 실제 데이터 페이지 주소를 담고 있습니다.
-
실제 데이터는 인덱스로 재정렬 되지 않습니다.
-
unique 제약조건 or 직접 index 적용 시 생성됩니다.
해시 테이블
해시 테이블은 Key, Value 로 데이터를 저장하는 자료구조 중 하나로 빠른 데이터를 검색이 필요할 때 유용합니다.
해시 테이블의 시간복잡도는 O(1)로 매우 빠르지만 사용되는 경우는 제한적인데, 이유는 등호(=) 연산에만 특화되었기 때문에 부등호 연선이 자주 사용되는 DB를 검색하기 위해서는 해시 테이블이 적합하지 않습니다.
클러스터드 + 논 클러스터드
클러스터드와 논 클러스터드 인덱스를 함께 사용하면 아래와 같은 구조가 될까요?
출처 https://www.youtube.com/watch?v=edpYzFgHbqs
논 클러스터드 인덱스만 있었다면, 논 클러스터드 인덱스에서 리프페이지에는 실제 데이터가 저장된 페이지의 주소와 순서를 가지고 있으면 된다. 실제 데이터가 저장된 페이지에서 순서가 변하지 않기 때문입니다.
클러스터드와 함께 적용된다면, 실제 데이터가 저장된 페이지에는 클러스터드 index를 기준으로 실제 데이터의 순서가 변할 수 있습니다. 따라서 아래와 같이 주소를 저장하지 않고 index를 직접 저장합니다.
출처 https://www.youtube.com/watch?v=edpYzFgHbqs
마무리
@Id
private String email;
내용을 입력하세요.
위 코드와 같이 email을 primary key로 설정하면 안 되는 이유를 확실하게 알았습니다.
기본키로 설정된다면 email을 기준으로 클러스터드 인덱스가 적용됩니다.
실제 데이터가 email을 기준으로 순서대로 저장되기 때문에 데이터가 많은 상황에서, email을 앞 혹은 중간에 INSERT 해야 한다면 성능상 이슈가 발생할 수 있기 때문입니다.
참조
https://joosjuliet.github.io/index_structure/
