컴퓨터에서 데이터베이스 인덱스는 왜 필요할까?

컴퓨터 세계의 색인 카드 데이터베이스 인덱스 이야기

우리가 수천 페이지에 달하는 두꺼운 요리책에서 김치찌개 레시피를 찾는다고 상상해 보겠습니다. 책의 맨 뒤에 있는 찾아보기 페이지를 보지 않고 첫 페이지부터 한 장씩 넘기면서 김치찌개라는 단어를 찾는다면 얼마나 오랜 시간이 걸릴까요? 아마 식사 시간이 다 지나고도 찾지 못할 수 있습니다. 반면에 책 뒤편의 색인에서 김치찌개가 있는 페이지 번호를 확인하고 곧바로 그 페이지로 펼친다면 몇 초 만에 원하는 정보를 얻을 수 있을 것입니다.

컴퓨터 세상에서 데이터를 다룰 때도 이와 정확히 똑같은 상황이 벌어집니다. 데이터베이스는 수백만, 수천만 개의 데이터를 저장하고 관리하는 거대한 창고입니다. 사용자가 특정 데이터를 요청했을 때, 컴퓨터가 이 거대한 창고를 처음부터 끝까지 전부 뒤져서 찾는다면 시스템은 금방 느려지고 멈춰버릴 것입니다. 여기서 등장하는 것이 바로 데이터베이스 인덱스입니다. 요리책의 찾아보기 페이지처럼 데이터의 위치를 빠르게 찾아낼 수 있도록 미리 길을 만들어 두는 것입니다.

데이터베이스 인덱스가 왜 반드시 필요한지 그 이유를 알아봅니다

데이터베이스 인덱스의 가장 큰 존재 이유는 단연 속도입니다. 데이터의 양이 적을 때는 인덱스가 있거나 없거나 큰 차이가 느껴지지 않습니다. 스마트폰 주소록에 친구가 10명밖에 없다면 누굴 찾든 1초도 걸리지 않는 것과 같습니다. 하지만 친구가 10만 명으로 늘어나고, 이름뿐만 아니라 전화번호, 주소, 생일 등 다양한 정보가 함께 저장된다면 이야기는 완전히 달라집니다.

인덱스가 없는 데이터베이스에서 특정 조건을 만족하는 데이터를 찾는 과정을 풀스캔이라고 부릅니다. 이는 책의 모든 페이지를 처음부터 끝까지 읽는 것과 같습니다. 반면 인덱스가 존재하면 데이터베이스는 정렬된 목차를 먼저 참고하여 찾고자 하는 데이터가 정확히 어디에 있는지 곧바로 찾아갑니다. 이를 통해 검색 속도를 수십 배에서 수백 배까지 단속적으로 끌어올릴 수 있으며, 이는 곧 사용자에게 쾌적한 서비스 경험을 제공하는 핵심 요소가 됩니다.

데이터베이스 인덱스의 대표적인 종류와 그 특성을 살펴봅니다

인덱스라고 해서 모두 똑같은 방식으로 작동하지는 않습니다. 데이터의 특성과 조회하는 방식에 따라 다양한 종류의 인덱스가 존재하며, 각각의 장단점이 뚜렷합니다. 현업에서 가장 많이 사용되는 대표적인 인덱스 유형들을 살펴보겠습니다.

B트리 인덱스는 가장 널리 쓰이는 기본입니다

B트리 인덱스는 데이터베이스 세계의 스테디셀러입니다. 나무가 가지를 뻗어 나가듯 데이터를 계층 구조로 정리하여 저장하는 방식입니다. 데이터가 추가되거나 삭제되어도 스스로 균형을 유지하며 정렬된 상태를 유지하기 때문에 범위 검색이나 일치 검색 모두에서 뛰어난 성능을 발휘합니다. 대부분의 관계형 데이터베이스에서 기본적으로 생성하는 인덱스가 바로 이 B트리 계열입니다.

해시 인덱스는 정확한 일치 검색에 강합니다

해시 인덱스는 키와 값의 쌍으로 데이터를 관리하는 방식입니다. 특정 값을 입력하면 고유한 주소값이 즉시 계산되어 나오는 구조를 가집니다. 특정 데이터가 존재하는지 정확하게 일치하는지 확인할 때는 세상에서 가장 빠른 속도를 자랑합니다. 다만 데이터가 정렬되어 있지 않기 때문에 크다 작다와 같은 범위 검색에는 사용할 수 없다는 제약이 있습니다.

전문 검색 인덱스는 긴 글을 빠르게 찾습니다

일반적인 인덱스는 단어의 앞부분이나 전체 일치 검색에 유리하지만 블로그 글 내용이나 상품 설명처럼 긴 텍스트 안에서 특정 단어를 찾기에는 역부족입니다. 전문 검색 인덱스는 문장 속의 모든 단어를 쪼개어 사전처럼 등록해 두기 때문에 사용자가 긴 문서 안에서 특정 키워드를 검색할 때 매우 유용하게 활용됩니다.

인덱스가 많을수록 무조건 좋을 것이라는 착각을 바로잡습니다

인덱스가 검색을 빠르게 만들어준다는 사실을 알게 되면 모든 컬럼에 인덱스를 걸어버리고 싶은 유혹에 빠지기 쉽습니다. 하지만 이는 데이터베이스 성능을 오히려 망치는 지름길이 될 수 있습니다. 인덱스는 만능 해결사가 아니며 명확한 대가를 치러야 하는 시스템 자원입니다.

새로운 데이터가 입력되거나 기존 데이터가 수정 또는 삭제될 때 어떤 일이 벌어질까요. 데이터만 변경되는 것이 아니라 그 데이터를 가리키고 있는 인덱스도 전부 갱신되어야 합니다. 책의 내용이 바뀌면 찾아보기 페이지도 다시 작성해야 하는 것과 같습니다. 따라서 인덱스가 너무 많으면 데이터를 쓸 때마다 엄청난 부하가 걸리며, 전체적인 시스템 성능 저하로 이어집니다.

디스크 공간을 차지한다는 점도 무시할 수 없습니다. 인덱스 역시 컴퓨터의 저장 공간에 파일 형태로 저장되는 데이터의 일종입니다. 불필요하고 사용 빈도가 낮은 인덱스를 무분별하게 만들어두면 소중한 저장 공간을 낭비하게 됩니다. 따라서 읽기 작업이 압도적으로 많은지, 쓰기 작업이 빈번하게 일어나는지 꼼꼼하게 따져보고 꼭 필요한 곳에만 최소한으로 적용하는 지혜가 필요합니다.

비용 효율적으로 인덱스를 설계하고 활용하는 실전 요령을 알아봅니다

인덱스를 잘 활용하면 서버 비용을 획기적으로 줄일 수 있습니다. 데이터베이스 서버는 성능이 좋을수록 비용이 급격히 상승합니다. 비효율적인 쿼리와 인덱스 부재로 인해 서버 사양을 계속 업그레이드하는 기업들이 많지만, 사실은 인덱스 설계만 바꿨어도 해결될 문제인 경우가 허다합니다. 실전에서 비용을 아끼고 성능을 높일 수 있는 요령들을 정리해 보았습니다.

• 자주 조회되는 컬럼을 우선적으로 선정합니다. 조건절에 자주 등장하는 아이디, 회원번호, 날짜 등의 컬럼이 주 대상이 됩니다.
• 선택도가 높은 컬럼에 집중합니다. 중복된 값이 너무 많은 컬럼 예를 들어 성별이나 동의 여부 같은 데이터는 인덱스의 효과가 매우 떨어집니다.
• 조합 인덱스를 만들 때는 순서가 중요합니다. WHERE 절에서 자주 함께 사용되는 컬럼들을 묶어서 인덱스로 만들 때, 조건으로 자주 쓰이는 컬럼을 앞쪽에 배치해야 효율적입니다.
• 사용하지 않는 유령 인덱스를 주기적으로 청소합니다. 시간이 지나면서 서비스 패턴이 바뀌어 더 이상 쓰이지 않는 인덱스들이 방치되는 경우가 많으므로 정기적인 점검이 필요합니다.

데이터베이스 인덱스와 관련해 자주 묻는 질문들을 확인합니다

인덱스가 있으면 모든 검색이 무조건 빨라지나요

그렇지 않습니다. 검색 결과가 전체 데이터의 상당 부분을 차지할 때는 인덱스를 타는 것보다 테이블 전체를 읽는 것이 오히려 더 빠를 수 있습니다. 이 경우 데이터베이스 옵티마이저는 인덱스를 무시하고 풀스캔을 선택하기도 합니다.

데이터가 적을 때도 인덱스를 만들어야 하나요

데이터가 수천 건 이하로 매우 적다면 굳이 인덱스를 만들 필요가 없습니다. 오히려 인덱스를 유지 관리하는 부하 때문에 성능이 미세하게 떨어질 수도 있습니다. 데이터가 늘어나는 속도와 시스템 부하를 모니터링하며 적절한 시점에 도입하는 것이 좋습니다.

하나의 테이블에 인덱스는 몇 개까지 만드는 것이 적당한가요

정해진 법감정은 없지만 보통 하나의 테이블당 3개에서 5개 내외의 인덱스를 유지하는 것이 권장됩니다. 물론 테이블의 성격과 데이터 수정 빈도에 따라 달라질 수 있으므로 절대적인 수치보다는 실제 성능 테스트 결과를 믿어야 합니다.