개요
쿼리튜닝 이야기를 하기 위해서 공부를 시작했다. 하루에 한 주제씩 DB의 좀 더 세부적인 정보들에 대한 이야기를 공부하고 있다. 그래서 어제는 옵티마이저, 오늘은 인덱스다. 인덱스는 보통 조회 기능을 위해 많이 사용한다.
인덱스란
인덱스란 추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조이다. 만약 우리가 책에서 원하는 내용을 찾는다고 하면, 책의 모든 페이지를 찾아보는 것은 오랜 시간이 걸린다. 그렇기 때문에 책의 저자들은 책의 맨 앞 또는 맨 뒤에 색인을 추가하는데 데이터베이스의 index는 책의 색인과 같다.
데이터베이스에서도 테이블의 모든 데이터를 검색하면 시간이 오래 걸리기 때문에 데이터와 데이터의 위치를 포함한 자료구조를 생성하여 빠르게 조회할 수 있도록 돕고있다.
인덱스를 활용하면 데이터를 조회하는 SELECT 외에도 UPDATE나 DELETE의 성능이 함께 향상된다. 그러한 이유는 해당 연산을 수행하려면 해당 대상을 조회해야만 작업을 할 수 있기 때문이다.
인덱스의 트레이드오프
insert나 delete,update의 연산에서 인덱스를 사용함으로써 검색 속도를 높혀 원하는 실행 자체를 빠르게 할 수는 있지만, 인덱스의 존재로 인해 추가적인 연산이 필요하기도 하다. 즉, 빨리 찾아서 처리를 하는 것 자체 까지는 기존보다 빨라지지만 추가적인 작업이 필요하다는 이야기이다.
Insert : 새로운 데이터에 대한 인덱스를 추가함
Delete : 삭제하는 데이터의 인덱스를 사용하지 않는다는 작업을 진행함
Update : 기존의 인덱스를 사용하지 않음 처리하고, 갱신된 데이터에 대해 인덱스를 추가함.
- 장점
- 테이블을 조회하는 속도와 그에 따른 성능을 향상시킬 수 있다.
- 전반적인 시스템의 부하를 줄일 수 있다.
- 단점
- 인덱스를 관리하기 위해 DB의 약 10%에 해당하는 저장공간이 필요하다.
- 인덱스를 관리하기 위해 추가 작업이 필요하다.
- 인덱스를 잘못 사용할 경우 오히려 성능이 저하되는 역효과가 발생할 수 있다 .
만약 create,delete,update가 빈번한 속성에 인덱스를 걸게 되면 인덱스의 크기가 비대해져서 성능이 오히려 저하되는 역효과가 발생할 수 있다. 그러한 이유 중 하나는 Delete와 update 연산 때문에다. 앞에서 설명한대로, Update, Delete가 빈번하게 발생된다면 실제 데이터는 10만건이지만 인덱스는 훨씬 많이 존재하게 되어, SQL문 처리 시 비대해진 인덱스에 의해 오히려 성능이 떨어지게 되는 것입니다.
인덱스를 사용하면 좋은 경우
- 규모가 작지 않은 테이블
- Insert, Update, Delete가 자주 발생하지 않는 컬럼
- Join이나 Where 또는 Order by에 자주 사용되는 컬럼
- 데이터의 중복도가 낮은 컬럼
- 기타 등등
인덱스의 저장 자료구조
인덱스를 구현하기 위해서는 다양한 자료구조를 사용할 수 있는데, 가장 대표적인 해시 테이블과 B+Tree가 있다.
해시테이블
key- value 쌍으로 저장하는 자료구조로 빠른 데이터 검색이 필요할 때 유용하다. 해시 테이블은 Key값을 이용해 고유한 Index를 생성하여 그 index에 저장되는 값을 꺼내오는 구조입니다. 조회 속도가 O(1)이라는 장점이 있습니다.
하지만 DB인덱스에서 해시 테이블이 사용되는 경우는 제한적인데 그러한 이유는 해시가 등호연산에만 특화되었기 때문이다. 해시 함수는 값이 1이라도 달라지면 완전히 다른 해시 값을 생성하는데, 이러한 특성에 의해 부등호 연산(>,<)이 자주 사용되는 데이터 베이스 검색을 위해서는 해시테이블이 부적절 할 수도 있다.
B+Tree
B+Tree는 DB의 인덱스를 위해 자식 노드가 2개 이상인 B-Tree를 개선시킨 자료구조이다. B+Tree는 모든 노드에 데이터를 저장했던 BTree와 다른 특성을 가진다.
- 리프노드만 인덱스와 함께 데이터를 가지고 있고, 나머지 노드들은 데이터를 위한 인덱스만을 갖는다.
- 리프노드들은 LinkedList로 연결되어 있다.
- 데이터 노드 크기는 인덱스 노드의 크기와 같지 않아도 된다.
B+Tree 구조는 리프노드에만 데이터가 저장되고, 중간 노드에는 인덱스만 있다. 그리고 순서대로 리프노드들이 LinkedList형태로 연결되어 있는데 이런 저장 구조가 항상 무조건 리프노드까지 가야한다는 단점이 있지만 Tree구조로 이루어져 있어 순차검색을 용이하게 하는 등의 이점을 가진다.
인덱스의 분류
클러스터형 인덱스
- 클러스터형 인덱스는 데이터 행의 물리적인 순서를 인덱스 순서로 정렬하는 인덱스입니다. 즉, 인덱스 키의 순서대로 실제 데이터가 정렬됩니다.
- 하나의 테이블에는 한 개의 클러스터형 인덱스만 존재할 수 있습니다.
- 클러스터형 인덱스는 주로 검색속도를 향상시키고 범위 쿼리의 성능을 최적화 하는데 사용됩니다.
비클러스터형 인덱스
- 비클러스터형 인덱스는 데이터 행의 물리적인 순서와 독립적으로 별도의 인덱스 구조를 가집니다. 따라서 인덱스 키와 실제 데이터 행은 분리되어 있습니다.
- 하나의 테이블에는 여러 개의 비클러스터형 인덱스가 존재할 수 있습니다.
- 비클러스터형 인덱스는 주로 데이터의 검색 및 정렬에 사용됩니다.
참조
