[10분 테코톡] 👨‍🏫안돌의 INDEX

출처: https://www.youtube.com/watch?v=NkZ6r6z2pBg

📌 인덱스(INDEX)는 무엇이며, 왜 필요한가?

인덱스는 데이터베이스에서 원하는 데이터를 빠르게 찾아오고, 데이터가 많아질수록 느려지는 조회 성능 문제를 해결하기 위해 사용됩니다.

💡 인덱스의 주요 종류와 특징은 무엇인가?

배경지식: 데이터베이스 인덱스를 이해하기 위한 기초 개념

이 자료는 데이터베이스의 성능을 좌우하는 핵심 개념인 인덱스에 대해 설명하고 있습니다. 특히 인덱스의 종류(클러스터드, 논클러스터드)와 이로 인해 발생하는 성능상의 특징을 깊이 있게 다루죠. 자료를 100% 이해하기 위해, 발표의 배경이 되는 맥락과 함께 핵심적인 용어 및 개념을 미리 살펴봅시다.

1. MySQL과 InnoDB의 중요성

• 이 발표의 내용은 단순히 '인덱스' 일반론이 아니라, 현재 가장 널리 쓰이는 관계형 데이터베이스인 MySQL의 InnoDB 스토리지 엔진을 기준으로 설명하고 있습니다 .
• 인덱스의 작동 방식, 특히 클러스터드 인덱스의 구현 방식은 데이터베이스의 종류(예: MySQL, PostgreSQL, MSSQL)와 스토리지 엔진(예: InnoDB, MyISAM)에 따라 조금씩 차이가 있습니다.
• 따라서 자료에서 나오는 '클러스터드 인덱스는 PK와 같다'는 설명은 InnoDB 환경에서 매우 중요하게 적용되는 특징임을 알고 들으면 이해가 훨씬 쉬워집니다.

2. 인덱스 구현의 핵심 개념: B-Tree 구조

자료에서 클러스터드 인덱스는 데이터가 순서대로 정렬되어 있다고 설명합니다. 데이터가 삽입/삭제되어도 이 정렬 상태를 유지하고 빠르게 검색할 수 있게 해주는 마법 같은 구조가 바로 B-Tree(비트리)입니다.

• B-Tree란 무엇인가요?
  • B-Tree는 "Balanced Search Tree(균형 검색 트리)"의 한 종류입니다. 일반적인 트리 구조와 달리, 데이터베이스나 파일 시스템과 같이 디스크 I/O가 잦은 환경에서 최고의 성능을 내기 위해 설계되었습니다 .
  • 핵심 특징:
    • 균형 잡힌 구조 (Balanced): 트리의 모든 '잎 노드(데이터를 담는 가장 아래층)'는 루트 노드(가장 위층)에서부터 같은 거리에 있습니다. 이는 어떤 데이터를 찾든 항상 일정한 시간(O(log n))이 걸리도록 보장합니다 .
    • 넓고 낮음: B-Tree는 한 노드에 많은 수의 키(Key)를 저장할 수 있어, 트리의 높이가 매우 낮습니다. 디스크에서 데이터를 읽을 때, 트리의 높이가 낮다는 것은 디스크를 읽는 횟수가 적다는 뜻이며, 이는 곧 속도 향상으로 이어집니다.
    • 순차적 접근 용이: B-Tree의 잎 노드는 보통 순서대로 연결되어 있어, 특정 데이터를 찾은 후 범위 검색을 할 때 이어진 노드를 따라 쉽게 이동할 수 있습니다.
• 자료와의 연결점:
  • 자료에서 "클러스터드 인덱스는 순서대로 데이터가 정렬되어 있어서 범위 검색에 아주 강력합니다" 라고 설명하는 근본적인 이유가 바로 이 B-Tree의 정렬 및 순차 접근 특징 때문입니다.

3. 클러스터드 인덱스 성능의 비밀: 공간 지역성

클러스터드 인덱스가 왜 범위 검색에 강력한지 설명할 때, 자료는 공간 지역성이라는 개념을 언급하며 캐시 전략과 연결 짓습니다 .

• 공간 지역성 (Spatial Locality) 이란?
  • 컴퓨터 시스템에서 특정 데이터를 접근하면, 그 데이터 주변에 있는 데이터도 곧 접근될 가능성이 높다는 원리입니다.
  • 이 원리는 CPU 캐시 메모리에서 매우 중요합니다. CPU는 메인 메모리(RAM)보다 훨씬 빠른 캐시 메모리를 사용하는데, 디스크나 메모리에서 데이터를 가져올 때 단 하나의 데이터만 가져오는 것이 아니라, '캐시 라인(Cache Line)' 또는 '페이지(Page)' 단위로 주변 데이터까지 한 번에 가져와 캐시에 저장합니다.
  • 비유: 창고에서 물건을 찾을 때, 필요한 물건 하나만 꺼내지 않고 그 물건이 있는 상자 전체를 작업대로 옮겨 놓는 것과 같습니다. 상자 안에 다른 필요한 물건들이 들어 있을 가능성이 높기 때문이죠.

• 클러스터드 인덱스와의 관계:
  • 클러스터드 인덱스는 데이터 자체를 인덱스 순서에 맞게 물리적으로 정렬합니다 .
  • 만약 인덱스를 이용해 1번부터 10번까지의 레코드를 검색할 때, 이 데이터들은 디스크 상에서 가까운 위치에 저장되어 있을 가능성이 높습니다.
  • 따라서 첫 번째 데이터를 읽을 때 주변 데이터까지 메모리(버퍼 풀)에 한 번에 올라오게 되어, 이후 데이터 접근 시 디스크 I/O가 필요 없어져 엄청난 속도 향상을 얻습니다 . 이것이 범위 검색이 강력한 이유입니다.

4. 성능 튜닝의 핵심 용어

자료의 마지막 부분에서는 인덱스 전략을 보완하고 성능을 극대화하기 위한 중요한 설정값과 용어들을 언급합니다.

4.1. Primary Key (PK)와 Auto Increment

• Primary Key (PK): 테이블의 각 행을 유일하게 식별할 수 있는 값입니다. 자료에서 클러스터드 인덱스는 PK를 기반으로 작동하며, 테이블당 하나만 존재해야 한다고 강조합니다 .
• Auto Increment (자동 증가): PK 필드에 새 레코드가 삽입될 때마다 자동으로 순차적으로 1씩 증가하는 고유 번호를 생성하도록 설정하는 옵션입니다 .
• 성능 이슈와 해결:
  • 자료는 이메일 주소를 PK로 설정했을 때 생기는 심각한 성능 저하 문제를 예로 듭니다 .
  • 이메일(문자열)은 순차적이지 않기 때문에, 새로운 이메일이 들어올 때마다 클러스터드 인덱스(데이터)의 중간에 삽입되어야 하며, 이 과정에서 수많은 데이터를 밀어내는 비효율적인 작업(참사)이 발생합니다 .
  • Auto Increment를 사용하면 ID가 항상 마지막에 추가되므로, 기존 데이터를 밀어내는 작업 없이 가장 끝에만 삽입되어 삽입(INSERT) 성능 이슈를 해소할 수 있습니다 .

4.2. 논클러스터드 인덱스의 해시 테이블

• 논클러스터드 인덱스의 특징: 데이터 자체와 분리되어 간접 참조를 통해 데이터의 위치(PK 값)를 알려주는 역할을 합니다 . 순서가 중요하지 않으며, 한 테이블에 여러 개를 만들 수 있습니다.
• 해시 테이블 (Hash Table): 논클러스터드 인덱스가 데이터를 빠르게 찾기 위해 사용하는 구조 중 하나입니다.
  • 해시 테이블은 Key(검색어)를 해시 함수를 통해 주소(Bucket)로 변환하여 데이터를 저장하고 검색합니다 .
  • 검색 대상의 위치를 바로 알 수 있어 매우 빠른 검색 속도를 자랑합니다. 자료에서 논클러스터드 인덱스가 "해시 테이블 방식을 사용해서 굉장히 것을 빨리 찾을 수 있겠죠" 라고 언급한 부분이 바로 이 원리입니다.

4.3. InnoDB Buffer Pool Size (버퍼 풀 크기)

• Buffer Pool의 역할:InnoDB 스토리지 엔진이 디스크 I/O를 최소화하기 위해 사용하는 메모리 캐시 영역입니다 .
  • 자주 접근하는 데이터 레코드와 인덱스 블록을 이 버퍼 풀에 저장해둡니다 .
  • 인덱스를 통해 데이터를 찾으려 할 때, 디스크 대신 버퍼 풀에 데이터가 이미 있다면 엄청난 속도 차이를 만들어냅니다 (디스크는 느리고 메모리는 빠르므로).
• 성능 튜닝의 핵심:
  • 자료에서는 이 innodb_buffer_pool_size 값을 1기가, 2기가 이상으로 조정하여 퍼포먼스를 확 다르게 만들 수 있다고 조언합니다 .
  • 이 값이 클수록 DB는 인메모리 데이터베이스처럼 동작하게 되어 디스크 접근 횟수를 줄여 전반적인 쿼리 성능을 비약적으로 향상시킬 수 있습니다.

5. 인덱스의 효율성 측정: 카디널리티 (Cardinality)

인덱스를 만들 컬럼을 결정할 때, 자료에서 카디널리티라는 개념을 사용한다고 언급합니다 .

• 카디널리티란 무엇인가요?

  • 특정 컬럼에 저장된 데이터의 중복되지 않은 값의 수를 의미합니다. 즉, 얼마나 다양한 값을 가지고 있는지를 나타냅니다.
  • 높은 카디널리티: 값이 거의 중복되지 않고 유일한 경우 (예: 주민등록번호, 이메일 주소, ID)
  • 낮은 카디널리티: 값이 많이 중복되는 경우 (예: 성별(남/여), 예/아니오)

• 인덱스와의 관계:

  • 카디널리티가 높을수록 인덱스의 효율이 좋습니다.
  • 이유: 값이 유일할수록 (예: 주민등록번호) 인덱스를 따라 한 번의 검색으로 원하는 레코드를 정확히 찾을 수 있기 때문에, 전체 테이블을 훑어보는 것(Full Scan)보다 훨씬 빠릅니다.
  • 반대로 카디널리티가 낮으면 (예: 성별) 인덱스를 사용해도 결과가 테이블의 절반을 차지하게 되므로, 인덱스를 쓰는 것보다 그냥 테이블 전체를 훑어보는 것이 더 효율적일 수 있습니다 .

  

1. 인덱스의 기본 정의 및 필요성

1. 인덱스의 정의:
   1. 인덱스는 검색을 위해 임의의 규칙대로 부여된 임의의 대상을 가리키는 무언가이다 .
   2. 자바에서 리스트 요소에 접근하기 위해 인덱스를 사용하는 것과 유사하며 , 우리 주변의 다양한 요소들도 인덱스로 볼 수 있다 .
   3. 실생활 인덱스 예시:
      1. '2학년 3반 21번'처럼 특정 대상을 명확히 특정할 수 있는 것 .
      2. '서울시 송파구 신천동'과 같은 주소나 우편번호도 인덱스의 일종이다 .
   4. 인덱스는 특정 무언가를 꼬집어 찾아내기 위한 보조 수단으로 이해할 수 있다 .
2. 데이터베이스에서의 인덱스 필요성:
   1. 인덱스는 데이터베이스가 원하는 데이터를 어떻게 찾아오는지 알려줄 수 있다 .
   2. 데이터가 많아질수록 조회 성능이 느려지는 문제를 인덱스를 통해 해결할 수 있다 (100%는 아니지만 많은 부분 해결 가능) .
   3. 느린 쿼리나 조회 문제 발생 시 인덱스를 먼저 고려해 보는 것이 좋다 .

2. 클러스터드 인덱스 (Clustered Index)의 이해

1. 인덱스의 두 가지 종류: 인덱스에는 클러스터드 인덱스와 논클러스터드 인덱스가 있다 .
2. 클러스터의 개념:
   1. 클러스터(Cluster)는 군집이라는 뜻이며, 반도체 클러스터, 아이클레이스터 등의 용어에서 사용된다 .
   2. 클러스터드 인덱스란 데이터와 인덱스가 합쳐져 군집화된 인덱스를 의미한다 .
   3. 특징은 인덱스가 데이터에 가까이 있어 물리적으로 정렬되어 있는 형태이다 .
3. 클러스터드 인덱스의 작동 방식 (예시):
   1. 데이터 자체가 등수(순서)대로 정렬되어 있다고 가정한다 (예: 41등, 42등 등) .
   2. 43등의 새로운 데이터 (신입)가 삽입되어야 할 경우, 데이터는 정렬 순서를 유지해야 한다 .
   3. 삽입 과정: 43등이 들어갈 위치를 확보하기 위해 기존의 43등 이하의 데이터들 (43등, 44등, 45등...)이 한 칸씩 뒤로 밀려나게 되고, 새로운 43등 데이터가 삽입된다 .
4. 클러스터드 인덱스의 장단점:
   1. 장점 (범위 검색에 강력): 데이터가 이미 순서대로 정렬되어 있으므로, 41등부터 43등까지와 같이 특정 범위를 검색할 때 매우 강력하고 유리하다 .
   2. 단점 (삽입/정렬 비용 발생):
      1. 중간에 데이터가 삽입될 경우, 정렬 상태를 유지하기 위해 많은 데이터를 밀어내는 (재정렬하는) 비용이 발생한다 .
      2. 데이터가 많을수록 (예: 1,000명 중 43등 삽입 시 900여 번 밀어내야 함) 성능에 악영향을 미친다 .

3. 논클러스터드 인덱스 (Non-Clustered Index)의 이해

1. 논클러스터드 인덱스의 정의:
   1. 클러스터화되지 않으면서 데이터와 직접 연결된 것이 아니라 어떤 인덱스를 통해 연결되어 있는 형태이다 .
   2. 이는 간접 참조를 통해 데이터를 찾아간다 .
2. 논클러스터드 인덱스의 작동 방식 (예시):
   1. 인덱스는 순서와 상관없이 저장되어 있다 (예: 41등은 123번지, 20등은 231번지, 1등은 145번지) .
   2. 인덱스 자체는 데이터를 가지고 있지 않고, 데이터를 찾을 수 있는 주소(123번지, 231번지)를 가지고 있다 .
   3. 인덱스를 찾아 그 주소에 있는 데이터를 다시 찾게 된다 (2차 검색 필요) .
3. 논클러스터드 인덱스의 특징:
   1. 데이터 순서대로 저장될 필요가 없어 굳이 순서대로 있을 필요가 없다 .
   2. 보통 해시 테이블(Hash Table) 방식으로 구성되어 데이터를 빨리 찾을 수 있다 .

4. 클러스터드 vs 논클러스터드 인덱스 비교 및 PK, 카디널리티의 중요성

4.1. 클러스터드 인덱스(PK)의 특징 및 이슈

1. PK와의 관계: 클러스터드 인덱스는 일반적인 기본 키(PK)와 유사하거나 같다고 생각해도 무방하다 .
2. 순서 및 개수 제약:
   1. 데이터가 순서대로 정렬되어 있어야 한다 .
   2. 하나의 테이블에 여러 클러스터드 인덱스가 있을 수 없다 (가나다순 정렬과 등수 정렬을 동시에 할 수 없기 때문) .
   3. 따라서 클러스터드 인덱스/PK는 테이블 당 하나만 존재할 수 있다 .
3. 효율성: 범위 검색에 매우 좋으며, 캐시 전략의 공간 지역성(Spatial Locality)과 유사하여 비슷한 위치의 데이터를 한 번에 가져오기 유리하다 .
4. 삽입 시 문제점:
   1. 중간에 새로운 PK 값이 삽입될 때 재정렬로 인한 문제가 발생하며, 만 권이나 백만 권의 데이터에서 중간에 삽입되면 굉장히 오래 걸리는 참사가 발생한다 .
   2. 이 문제 때문에 PK를 오토 인크리먼트 (Auto Increment, 자동으로 증가) 옵션으로 설정하여 항상 가장 뒤에 삽입되도록 하는 것이 성능상 유리하다 .

4.2. 논클러스터드 인덱스(보조 인덱스)의 특징

1. 역할: 원하는 값 (예: 45등)을 검색했을 때 해당 데이터가 나오는 것이 논클러스터드 인덱스의 역할이다 (통상적으로 인덱스라고 불림) .
2. 순서와 개수:
   1. 데이터의 순서와는 상관이 없다 (아무거나 넣어도 됨) .
   2. 해시 테이블 방식으로 빠르게 보조 인덱스를 찾고, 이 인덱스에 저장된 PK를 다시 검색하여 최종 데이터를 찾게 되기 때문에 순서에 상관이 없다 .
   3. 따라서 한 테이블에 여러 개의 인덱스를 만들 수 있다 (등수, 이름, 학번 등 여러 기준으로 인덱스 설정 가능) .
3. 추가 비용:
   1. 추가 저장 공간이 필요하다. 보조 인덱스는 클러스터드 인덱스(PK)를 찾기 위한 주소를 저장하고 있어 데이터와 분리되기 때문에 저장 공간이 낭비될 수 있으며, 통상적으로 약 10% 정도의 추가 저장 공간이 필요하다고 추정된다 .
4. 인서트 시 비용:
   1. 클러스터드 인덱스에 비해 작업이 없다고 생각하기 쉽지만, 새로운 행이 들어올 때 이 행에 대한 인덱스를 생성하여 저장하는 작업이 반드시 추가된다 .

4.3. 카디널리티 (Cardinality)의 중요성

1. 카디널리티의 정의: 인덱스의 효과를 평가할 수 있는 항목이다 .
2. 중요성: 인덱스가 있으면 모든 데이터를 훑는 것보다 훨씬 유리하지만, 중복된 값들이 많은 경우에는 효과가 낮아진다 .
3. 평가 기준:
   1. 카디널리티가 낮음: 중복된 값들이 많을수록 (예: 성별 - 남자/여자) 카디널리티는 낮아진다 .
   2. 카디널리티가 높음: 주민등록번호처럼 유일한 값일수록 카디널리티는 높아진다 .
4. 활용: 어떤 컬럼에 인덱스를 부여할지 판단할 때 카디널리티 값을 사용하게 되며, 카디널리티가 높을수록 인덱스 사용을 고려하는 것이 좋다 .

5. 인덱스 활용 사례: PK를 Auto Increment로 쓰는 이유

1. 문제 제기: 어플리케이션 서비스 개발 중, 유저 로그인 시 이메일을 ID로 사용하는 경우, 이메일을 PK로 가져갈 경우 DB 성능 이슈가 발생할 수 있다는 피드백을 받았다 .
2. PK를 이메일로 설정했을 때의 성능 이슈:
   1. 이메일은 문자열 기반이며, 이메일이 클러스터드 인덱스(PK) 역할을 한다고 가정한다 .
   2. 기존에 'Sample'이라는 이메일이 마지막에 있었다고 할 때, 새로 들어온 'AnDol'이라는 이메일은 알파벳 순서상 Sample 앞에 위치한다 .
   3. 클러스터드 인덱스의 특성상, 'AnDol'이 들어가기 위해 기존에 있던 많은 데이터들을 뒤로 밀어내야 한다 .
   4. 회원이 100만 명 정도 되었을 때 이 삽입 작업은 굉장히 오래 걸리게 되며, 이는 회원가입 기능을 못 시킬 정도의 성능 이슈를 유발할 수 있다 .
3. 해결 방안:
   1. 이메일처럼 고유해야 하는 값은 유니크 제약조건만 부여하고, 클러스터드 인덱스(PK)는 별도의 시퀀스 값 (예: 자동 증가하는 숫자)으로 주는 것이 성능상 유리하다 .

6. 인덱스 미적용 및 적용 시 성능 비교

6.1. 인덱스가 없을 때의 문제점

1. PK를 알고 있는 경우: 개발자들은 유저 ID나 아티클 ID(PK)를 알고 검색하기 때문에 인덱스 개념 없이도 데이터를 찾을 수 있다 .
2. 일반 사용자의 검색: 일반 사용자는 PK를 모르며, 타이틀이나 이메일 등 비(非)PK 컬럼을 기준으로 검색한다 .
3. 성능 측정 환경 설정:
   1. 유저 검색: find by email
   2. 아티클 검색: find by title
   3. 테스트 데이터: 유저 10만 명, 각 유저가 아티클 5개씩 작성 (총 50만 개 아티클) .
4. 인덱스 미적용 시 결과:
   1. find by email 검색 시: 0.6초가 소요되었다 .
   2. 문제점: 0.6초는 다음 작업을 위한 준비 시간으로, 해당 작업 이후의 모든 작업은 0.6초를 기다려야 하며, 이는 사용자 경험(Latency) 저하로 이어진다 .
   3. 여러 사용자가 필요한 작업에서는 대기 시간이 길어져 서버가 멈추거나 타임아웃이 걸리는 문제가 발생할 수 있다 .
   4. find by title 검색 시: 5초가 소요되었다 .
   5. 이는 CPU가 초당 4.5GHz 정도로 연산을 처리할 수 있음에도 불구하고, 연산 횟수가 초과되어 발생한 매우 오래 걸리는 경우이다 .

6.2. 인덱스 적용 시 성능 개선 및 유의점

1. 인덱스 적용 후 결과: 0.001초 내로 압도적으로 빨라졌다 .
2. 인덱스 사용 유의점:
   1. 인덱스는 무조건 좋거나 모든 컬럼에 거는 것이 아니다 .
   2. 모든 컬럼에 인덱스를 걸 경우, 인덱스를 생성할 때마다 추가적인 비용 (데이터 삽입 시 인덱스 생성 작업)이 발생하여 오히려 성능 이슈가 생길 수 있다 .
   3. 따라서 어떤 상황에 인덱스가 필요한지 그 특징을 이해하고 적용해야 한다 .

7. 인덱스 성능 개선을 위한 심화 개념 및 DB 설정 팁

1. 실행 계획 (EXPLAIN):
   1. 쿼리 실행 시 MySQL이 어떻게 실행할 것인지 알려주는 키워드 (EXPLAIN)를 활용하여 분석할 수 있다 .
   2. 이를 분석하여 쿼리를 튜닝할 수 있다 .
   3. PK(클러스터드 인덱스)가 내부적으로 B-Tree 방식으로 구현되어 있다는 점을 이해하면 실행 계획 분석에 도움이 된다 .
2. 데이터베이스 내부 개념:
   1. DB에서 데이터를 저장하는 방식인 페이지(Page) 또는 블록(Block) 개념은 운영체제에서 말하는 메모리 기반 페이지와 유사하다 .
   2. 이외에도 카디널리티, 복합 키(Composite Key) 등의 개념을 이해해야 한다 .
3. DB 설정 팁 (성능 최적화):
   1. innodb_buffer_pool_size 설정값을 조정하면 퍼포먼스가 달라질 수 있다 .
   2. 기본값 대신 1기가, 2기가 등으로 설정하여 퍼포먼스를 향상시킬 수 있다 .
   3. 오래 걸리는 쿼리를 로깅하여 분석하기 위해 slow query log 설정을 활용할 수 있다 .