최근 메신저 프로젝트를 진행하면서 메시지 관련 대용량 데이터 처리를 위해 프로파일링을 통한 성능 최적화 작업을 주로 업무로 하게 되었다. 물론 그 중 단연 DB 튜닝도 작업 내역 중에 포함되었다. 그러던 중 학부 시절에 들어 본듯한 단어가 하나 있었다. '인덱싱'
뭐라도 쓰려면 알고 써야한다는 지론에 따라 '인덱싱'에 대해 구글링하고 공부한 내용을 이번 포스팅에서 정리하려고 한다. 누구나 필자처럼 DB 튜닝을 통해 성능 최적화를 하고자 한다면 이번 글을 간략하게나마 읽어 볼 필요가 있다.
먼저 이 글을 읽는 사람은 기본적인 DB의 구조와 사용법을 안다는 가정하에 시작한다. 인덱싱은 말 그대로 DB에 색인을 남기는 것이다. 왜 색인을 남길까? 책에서 원하는 항목을 찾기 위해 첫페이지에서부터 찾는 것보다 색인을 통해 검색 범위를 줄이는 것이 훨씬 효과적이기 때문이다. DB의 인덱싱도 이와 일맥상통하다. 자칫하면 인덱싱이라 하여 데이터의 값을 자동 정렬해주는 것으로 이해하기 쉽다. 그런데 정렬은 자동으로 안된다. 물론 인덱싱을 하면 sorting할 때, 성능 개선 효과를 볼 수 있을 지 모른다. 그럼 색인을 통한 성능 개선효과를 볼 수 있는 대표적인 케이스를 보자.
인덱싱을 사용하면 좋은 케이스
- 데이터의 양이 많고, 검색이 변경보다 잦은 경우
- 인덱스를 사용하고자 하는 컬럼의 값이 다양한 경우
위와 같은 경우, 인덱싱을 사용하면 효과를 볼 수 있다. 그럼 우리는 이 시점에서 궁금해질 것이다. 왜 인덱싱을 쓰면 성능 개선 효과를 볼 수 있는 것인가. 그럼 무엇보다 인덱싱이 무엇인지 알 필요가 있다. 위에서 설명한 것으로도 왜 개선되는지 정도는 짐작할 수 있다. 하지만 우리는 개발자이다. 알고 쓰도록 하자.
인덱스는 검색 속도를 높이기 위한 데이터 구조이다. 반면에 쓰기 작업을 할 때 인덱스를 재구성하기 위한 비용이 발생하고 별도의 저장공간도 발생하게 된다. 성능을 높이기 위한 trade-off로 생각하면된다. 인덱스는 일반적으로 키-필드 구조로 이루어져있고 테이블에 대한 세부 정보를 가지지 않는다. 별도의 세부 정보의 이용없이 키 값을 기초로 하기 때문에 검색과 정렬속도를 향상시킨다. 그래서 일반적으로 대부분의 DBMS는 primary key를 자동으로 인덱싱한다. 인덱스의 구조를 설명하기 위해 외부 이미지를 하나 빌려왔다.
위와 같이 인덱싱하고자 하는 컬럼을 키로 하는 index table을 만든다. 각 튜플별로 부여된 row ID로 직접 접근이 가능하도록하는 구조이다. 여기서 첨언하자면 data/index는 B-Tree 구조이다.
'Programming > Database' 카테고리의 다른 글
[Database] 데이터베이스 쿼리문 사용 시, 유의사항 (0) | 2012.10.20 |
---|