MySQL/MariaDB Cluster Index

MySQL/MariaDB Cluster Index

 

·      Version : MySQL / MariaDB

 

인덱스에서 클러스터링은 값이 비슷한 것을 묶어서 저장하는 형태로 구현된다. 이 방법은 주로 비슷한 값들을 동시에 조회하는 경우가 많다는 점에 착안한 것이다. MySQL에서는 InnoDB 스토리지엔진에서 클러스터링 인덱스를 지원한다. (인덱스는 MySQL엔진이 아닌 스토리지 엔진이 담당한다)

클러스터링 인덱스(키 클러스터)는 테이블의Primary  key(이하 PK로 표시)에 대해서만 적용되는 내용이다. 즉 PK 값이 비슷한 레코드끼리 묶어서 저장하는 것을 클러스터링 인덱스라고 표현한다. 중요한 포인트는 PK 값에 따라 레코드의 저장 위치가 변경되는데 이 뜻한 해당 레코드의 물리적인 저장 위치가 바뀌어야 한다는 것이다. 따라서 PK 값으로 클러스터링된 테이블은 PK 값 자체에 대한 의존도가 높기 때문에 PK를 결정할때 데이터의 특정 등을 신중히 판단해야 한다. 일반적으로 InnoDB 처럼 클러스터링 인덱스로 저장되는 테이블은 PK 기반 검색이 빠르며, 대신 레코드 저장이나 PK 변경(데이터 위치가 변경될 수 있으므로)은 상대적으로 느릴수 밖에 없다.

 

클러스터링 인덱스 구조는 일반 B-Tree 인덱스 비슷하게 닮아 있다.

 

하지만 B-Tree의 리프노드와는 달리 클러스터링의 인덱스의 리프노드에는 레코드의 모든 칼럼이 같이 저장되어 있다.

즉 클러스터링 테이블은 그 자체가 하나의 거대한 인덱스 구조로 관리되는 것이다. InnoDB에서 PK가 없는 테이블에 대해서는 아래 순서대로 PK를 대체할 컬럼을 선택한다.

1.     프라이머리 키가 있으면 기본적으로 PK를 클러스터 키로 선택

2.     NOT NULL 옵션의 유니크 인덱스 (unique index)중에서 첫 번째 인덱스를 클러스터 키로 선택

3.     자동으로 유니크한 값을 가지도록 증가되는 컬럼을 내부적으로 추가한 후 클러스터 키로 선택.

InnoDB  스토리지 엔진이 적절한 키를 찾지 못하여 내부적으로 자동 증가 컬럼을 추가한 경우 이는 사용자에게 노출되지 않으며 쿼리에서 명시적으로 사용할 수 없다. 이는 사용자에게 아무런 혜택이 없으므로 가능한 PK를 명시 할 수 있도록 한다.

 

[클러스터 인덱스 장점]

1.     PK(클러스터 키)로 검색할때 처리 성능이 매우 빠름

2.     테이블의 모든 보조 인덱스가 PK를 가지고 있기 때문에 인덱스만으로 처리 될 수 있는 경우가 많음(커버링 인덱스)

 

[클러스터 인덱스 단점]

1.     테이블의 모든 보조 인덱스가 클러스터 키를 갖기 때문에 키 값의 크기가 클 경우 전체적으로 인덱스의 크기가 커짐

2.     보조 인덱스를 통해 검색 할때 PK 값을 한번 더 확인해야하기 때문에 성능이 조금 느림

3.     INSERT 할 때 PK로 인해 저장위치가 결정되기 때문에 처리 성능이 느림

4.     PK를 변경할때 DELETE 및 INSERT 작업이 필요하기 때문에 처리 성능이 느림.

 

[클러스터 테이블 사용시 주의사항]

1.     PK 크기가 커지면 보조 인덱스도 자동으로 커지므로 키 크기에 주의

2.     PK가 커지더라도 비즈니스적으로 빈번하게 사용되는 대표적인 값이면 PK로 설정하여 사용

3.     PK는 반드시 명시할 것. (명시하지 않을 경우 내부적으로 자동 증가값 사용)

 

 

2017-11-09 / 강성욱 / http://sqlmvp.kr / http://sqlangeles.com

 

MySQL, MariaDB, Clustering Table, 클러스터 테이블, 클러스터 키, Index, 인덱스, InnoDB, 스토리지 엔진