저는 쿼리를 작성할 때 인덱스가 있는지 먼저 확인하는데요. 그만큼 인덱스는 쿼리 속도에 큰 영향을 줍니다. "이거 인덱스 설계가 잘 못된 거 아냐?"라는 말을 현장에서 많이 하게 되죠.
인덱스가 잘 설계되지 않으면 없는니만 못합니다. 그렇다면 인덱스 설계는 어떤 방법으로 진행하는 걸까요? 이 글은 인덱스 설계 전략에 대해 심도 있게 이야기해 보겠습니다.
인덱스 설계 오너쉽 필요성
시스템별로 수천개부터 수백 개까지 많은 테이블을 기업들은 관리합니다. 보통 인덱스는 테이블의 몇 배로 관리되어야 하는데요. 소수의 DBA(데이터베이스 관리자) 혹은 성능 전문가가 모든 인덱스 설계를 책임질 수 없는 현실입니다.
관리해야 할 테이블 및 인덱스 수가 적은 중소기업에서는 DBA라는 전담인력조차 둘 수 없는 현실이죠. 결국 대부분의 경우, 인덱스 설계의 오너쉽은 해당 업무 개발자가 하는 경우가 많습니다.
하지만 개발자는 해당 업무 지식, 프로그래밍 언어에 대한 지식 등 학습해야 할 분야가 다양합니다. 그래서 보통의 경우에는 인덱스 오너쉽을 가진 개발자가 인덱스에 대해서 잘 알지 못하는 것이 현실입니다.
특별한 경험을 통해 개발자가 인덱스에 대해 잘 알게 되더라도, 개발 년차가 지남에 따라 더 이상 개발 업무만 집중할 수 없는 실정입니다. 그렇기 때문에 인덱스 설계의 기본 지식을 갖추는 것이 개발자의 경쟁력이 됩니다.
인덱스 설계의 중요성
작은 시스템에서는 인덱스 삭제 및 변경을 수시로 하는 경우가 있습니다. 하지만 인덱스 한 개를 잘 못 삭제하여 시스템이 마비가 되는 경우를 종종 보게 됩니다. 인덱스를 변경하는 작업에는 리스크는 따르는데요. 그만큼 인덱스 설계는 처음부터 제대로 설계하는 것이 포인트입니다.
만약 인덱스를 갑자기 삭제했다고 생각해 볼까요? 해당 인덱스가 어떤 화면에서 사용하고 있는지, 어떤 개발자에 의해 생성된 것인지 확신할 수 없습니다. 이런 이유로 인덱스는 신규 추가하기 보다는 삭제하는 것이 더 어렵습니다.
결론은 인덱스가 제대로 설계하고 관리되지 않으면 인덱스가 계속 추가되는 현상이 일어납니다. 이렇게 인덱스 무한정 추가하는 것이 과연 옳을까요? 공간 낭비와 성능의 비효율이 생기는 원인입니다.
인덱스 설계 고려사항
인덱스는 시스템 전체적인 관점에서 관리되어야 합니다. 처음부터 아래 힝목들을 고려해서 설계해야 합니다. 각 항목을 모두 기록해서 정리해서 인덱스 디자인 차트를 만듭니다.
고려요소 | 내용 | 고려 사항들 |
Access Pattern |
•해당 테이블을 사용하는 SQL문 패턴
•특히 WHERE 조건절 이하가 중요
|
•패턴에 따라 인덱스가 필요한 칼럼들이 나오게 됨
|
SQL 수행빈도 |
•해당 테이블을 사용하는 SQL문 패턴별 수행빈도 (얼마나 많이 사용하느냐)
|
•자주 사용하는 SQL에 최적화된 인덱스 설계가 필요함
|
Update/Delete/Insert 빈도 |
•해당 테이블의 Update/Delete/Insert 빈도
|
•자주 Update/Delete/Insert하는 테이블의 경우, 인덱스 관리비용이 증가할 수 있으므로, 적정한 인덱스 개수 관리가 필요함
|
업무상중요도 |
•자주 사용하지는 않지만, 업무상 중요도가 높은 경우
|
•고객만족 차원에서 성능이 최적화 되도록 인덱스 설계가 필요함
|
칼럼분포도 |
•대상이 되는 칼럼의 분포도( 칼럼별 평균값, 최대값, 최소값)
|
•인덱스 생성시 효율성 측면이 고려 대상임
|
클러스터링 팩터 |
•CF가 좋은 인덱스 선정
|
•모든 인덱스의 CF를 다 높게 할 수 없다
|
인덱스 손익분기점 |
•인덱스를 경유한 테이블 액세스 비용이 Table Full Scan 비용과 일치하는 지점이 인덱스 손익분기점임
|
•인덱스 손익분기점을 만족하는 인덱스인가 점검
|
데이터건수 |
•데이터 건수와 인덱스의 관계 점검
|
•데이터 건수가 아주 적으면 굳이 인덱스가 필요 없고, 데이터 건수가 너무 많으면 인덱스 유지 비용도 고려해야 됨
|
IOT 활용여부 |
•통계성 테이블 같이 PK 칼럼이 많고, 추가 칼럼은 적은 경우 유리
|
•PK이외 칼럼이 많다면 데이터 입력시 성능 저하 발생 가능 고려
|
인덱스 설계의 고려사항을 살펴보았습니다. 그러면 실제 어떻게 인덱스는 설계해야 할까요? 인덱스를 구성하기 위한 가이드와 생각해야 할 부분은 아래 링크에 정리해 보았습니다.
'데이터베이스' 카테고리의 다른 글
Oracle 인덱스 스캔 방식1: Index Range Scan, Unique Scan (0) | 2024.05.27 |
---|---|
ROWID와 클리스터링 팩터(CF)의 관계는? (0) | 2024.05.21 |
결합(복합) 인덱스 어떻게 구성할까? (0) | 2024.05.16 |
인덱스가 왜 필요했을까? (0) | 2024.05.13 |
In-memory DB Redis의 특징, 어떻게 사용할까? (1) | 2024.04.26 |