: MySQL 서버에서 클러스터링은 테이블의 레코드를 비슷한 것들끼리 묶어서 저장하는 형태로 구현, 이는 주로 비슷한 값들을 동시에 조회하는 경우가 많다는 점에서 착안되었음
MySQL 클러스터링 인덱스는 InnoDB 스토리지 엔진에서만 지원하며 나머지는 지원하지 않는다.
1. 클러스터링 인덱스
: 클러스터링 인덱스는 테이블의 프라이머리 키에 대해서만 적용됨, 즉 프라이머리 키 값이 비슷한 레코드끼리 묶어서 저장하는 것, 여기서 중요한것은 프라이머리 키 값에 의해
레코드 저장 위치가 결정된다는 것, 또한 프라이머리 키 값이 변경되면 해당 레코드의 물리적인 위치가 변경되야함, 이때문에 프라이머리 키를 신중하게 결정해야 함
: 클러스터링 인덱스는 프라이머리 키 값에 의해 레코드의 저장 위치가 결정되므로 인덱스 알고리즘이라기보단 테이블 레코드의 저장 방식, 또한 클러스터링의 기준이되는 프라이머리
키는 클러스터링 키라고도 표현하며 일반적으로 InnoDB와 같이 항상 클러스터링 인덱스로 저장되는 테이블은 프라이머리 키 기반의 검색이 매우 빠르며 저장이나 변경은 상대적으로
느림
B-Tree 인덱스도 인덱스 키 값으로 이미 정렬되어 저장, 이는 어떻게 보면 인덱스의 키 값으로 클러스터링된 것으로 생각할 수 있는데, 이는 클러스터링 인덱스라고 부르지 않음
테이블의 레코드가 프라이머리 키 값으로 정렬되어 저장된 경우만 클러스터링 인덱스 또는 클러스터링 테이블이라고 한다.
: 만약 프라이머리 키가 없는 InnoDB 테이블은 어떻게 클러스터링 테이블로 구성할까
1.
프라이머리 키가 있으면 기본적으로 프라이머리 키를 클러스터링 키로 선택
2.
NOT NULL 옵션의 유니크 인덱스 중에서 첫 번째 인덱스를 클러스터링 키로 선택
3.
자동으로 유니크한 값을 가지도록 증가되는 칼럼을 내부적으로 추가한 후, 클러스터링 키로 선택
: 가급적이면 클러스터링 인덱스는 테이블 당 하나만 가질 수 있는 엄청난 혜택이므로 명시적으로 생성하는 것이 좋다.
2. 세컨더리 인덱스에 미치는 영향
: MyISAM이나 MEMORY 스토리지 엔진의 클러스터링되지 않는 테이블은 INSERT된 공간에서 절대 이동하지 않으나 InnoDB의 세컨더리 인덱스가 실제 레코드가 저장된 주소를 가지고
있다면 클러스터링 키 값이 변경될 때마다 데이터 레코드의 주소가 변경되고 해당 주솟값을 변경해주어야 한다. 이런 불필요한 오버헤드를 줄이기 위해 InnoDB 테이블은 모든
세컨더리 인덱스를 해당 레코드가 저장된 주소가 아닌 프라이머리 키 값을 저장하도록 구현되어 있음
3. 클러스터링 인덱스의 장점과 단점
장점 | - 프라이머리 키로 검색할 때 처리 성능이 매우 빠름
- 테이블의 모든 세컨더리 인덱스가 프라이머리 키를 가지고 있기 때문에 인덱스만으로 처리될 수 있는 경우가 많음 |
단점 | - 테이블의 모든 세컨더리 인덱스가 클러스터링 키를 갖기 때문에 클러스터링 키 값의 크기가 클 경우 전체적으로 인덱스의 크기가 커짐
- 세컨더리 인덱스를 통해 검색할 때 프라이머리 키로 다시 한번 검색해야 하므로 처리 성능이 느림
- INSERT할 때 프라이머리 키에 의해 레코드의 저장 위치가 결정되기 때문에 처리 성능이 느림
- 프라이머리 키를 변경할 때 레코드를 삭제하고 삽입하는 작업이 필요하기 때문에 처리 성능이 느림 |
: 대부분 클러스터링 인덱스의 장점은 빠른 읽기이며 단점은 느린 CUD이다. 일반적으로 웹 서비스와 같은 온라인 트랜잭션 환경에서는 쓰기와 읽기 비율이 1:9, 2:8이기 때문에 조금
느린 쓰기를 감수하고도 읽기를 빠르게 유지하는 것이 중요하다.
4. 클러스터링 테이블 사용 시 주의사항
: MyISAM과 같이 클러스터링되지 않은 테이블에 비해 InnoDB 테이블에서는 조금 더 주의해야할 부분이 존재
1.
클러스터링 인덱스 키의 크기
: 클러스터링 테이블의 경우 모든 세컨더리 인덱스가 프라이머리 키 값을 포함하므로 프라이머리 키의 크기가 커지면 세컨더리 인덱스도 자동으로 크기가 커진다.
: 인덱스가 커지면 커질수록 같은 성능을 내기 위해 버퍼 풀에 적재되어야 하므로 메모리 관련 이슈가 생길 수 있으니 신중하게 선택해야 한다.
2.
프라이머리 키는 AUTO-INCREMENT보다는 업무적인 칼럼으로 생성(가능하다면)
: InnoDB의 프라이머리 키는 클러스터링 키로 사용되며 이 값에 의해 레코드 위치가 결정됨, 즉 프라이머리 키로 검색하는 경우 클러스터링되지 않은 테이블에 비해 매우 빠르게
처리될 수 있음, 이는 InnoDB에서 큰 차이를 만들어내기 때문에 검색에서 빈번히 사용되곤 한다. 그러므로 설령 그 칼럼의 크기가 크더라도 업무적으로 해당 레코드를 대표할
수 있다면 해당 칼럼을 프라이머리 키로 설정하는 것이 좋다.
3.
프라이머리 키는 반드시 명시할 것
: 프라이머리 키가 없는 테이블이 존재하는데, 가능하면 AUTO_INCREMENT 칼럼을 이용해서라도 프라이머리 키를 생성하는 것을 권장, InnoDB 테이블에서 프라이머리 키를
정의하지 않으면 InnoDB 스토리지 엔진이 내부적으로 일련번호 칼럼을 추가하므로 결과적으론 AUTO_INCREMENT 칼럼을 추가하는 것과 똑같다. 다만 접근이 불가능하므로
생성하는 것을 권장한다.
4.
AUTO-INCREMENT 칼럼을 인조 식별자로 사용할 경우
: 여러 개의 칼럼의 복합으로 프라이머리 키가 만들어지는 경우 프라이머리 키의 크기가 길어질 때가 가끔 있음, 프라이머리 키의 크기가 길어도 세컨더리 인덱스가 필요치 않다면
그대로 프라이머리 키를 사용하는 것이 좋다. 세컨더리 인덱스도 필요하고 프라이머리 키의 크기도 길다면 AUTO_INCREMENT 칼럼을 추가하고 이를 프라이머리 키로 설정하면 됨
