클러스터 테이블

호밀빵 굽는 쿼카·2023년 3월 8일

클러스터 테이블 클러스터링 인덱스

NHN Cloud

목록 보기

14/16

선임님의 질문 하나가 선량한 사원 한명을 죽일수도 살릴수도,,어쩌구,,

상황은 이렇다. 선임님의 훅 들어온 질문 하나. What is 클러스터 테이블?

약 10초간 나의 머릿속에는

어? 클러스터 테이블?
클러스터링 인덱스는 아는데,,
아니 DBA 가 되겠다면서 이것도 몰라?
서버 클러스터도 생각났다! 아 근데 이건 아님
모른다고 솔직하게 말하자!

선량한 사원의 하찮은 답변

부끄럽지만 정말 이렇게 답변함. 공개적인 곳에 올려야지 해이해질때마다 확인하고 공부할 수 있으니까,,
아,,근데 외때묺에 눈에서 땀이,,

일단 다른 업무가 급해서 후다닥 처리하고 클러스터 테이블 에 대해 찾아보았다.

클러스터란?
디스크로부터 데이터를 읽어오는 시간을 줄이기 위해서 조인이나 자주 사용되는 테이블의 데이터를 디스크의 같은 위치에 저장시키는 방법이다.

클러스터 특징
클러스터는 데이터 조회 성능을 향상 시키지만 데이터 저장, 수정, 삭제 또는 한 테이블 전체 Scan의 성능을 감소 시킨다.

클러스터 하기 좋은 테이블
- 주로 조회가 자주 발생하고 수정이 거의 발생하지 않는 테이블
- 컬럼안의 많은 중복 데이터를 가지는 테이블
- 자주 Join되는 테이블

클러스터 Key가 되기 좋은 컬럼
- 데이터 값의 범위가 큰 컬럼
- 테이블 간의 조인에 사용되는 컬럼

클러스터 key가 되기 나쁜 컬럼
- 특정 데이터 값이 적은 컬럼
- 자주 데이터 수정이 발생하는 컬럼
- LONG, LONG RAW 컬럼은 포함할 수 없다.

흠,,, 설명을 읽다보니 뭔가 익숙한데 싶더니만 역시!
과거에 스터디한 클러스터형 인덱스 와 내용이 동일한 것을 확인할 수 있었다.

Real MySQL 8.0 발췌

클러스터링 인덱스는 프라이머리 키 값에 의해 레코드의 저장 위치가 결정되므로 사실 인덱스 알고리즘이라기보다 테이블 레코드의 저장방식이라고 볼 수 있다. 그래서 "클러스터링 인덱스"와 "클러스터링 테이블"은 동의어로 사용되기도 한다

클러스터형 인덱스는 인덱스 페이지의 리프 페이지가 데이터 그 자체이므로 데이터 조회 성능을 향상 시키지만 데이터 저장, 수정, 삭제 성능은 감소시킨다

정리하자면, 클러스터링 인덱스 = 클러스터 테이블. 수정은 없고 조회를 빠르게 하고 싶을때, 클러스터링 인덱스를 사용

Real MySQL 8.0 에 나오는 클러스터링 인덱스(테이블) 내용을 더 공부해보자

클러스터링 인덱스가 나오게 된 배경

1) 비슷한 값들을 동시에 조회하는 경우가 많다
2) 효과적으로 조회하는 방법이 없을까?
3) MySQL 서버에서 클러스터링은 테이블의 레코드를 비슷한 것(primary key 기준)들끼리 묶어서 저장하는 형태로 구현된다. 
(클러스터링 인덱스는 테이블의 primary key 에 대해서만 적용됨)

클러스터링 인덱스

클러스터링 인덱스는 테이블의 레코드를 비슷한 것(primary key 기준)끼리 묶어서 저장하는 것을 의미한다. 이것은 primary key 값이 변경되면 그 레코드의 물리적인 저장위치가 바뀌어야한다는 것을 의미하기도 한다.

primary key 값으로 클러스터링 된 테이블은 키 값 자체에 대해 의존도가 높기 때문에 신중히 결정해야한다.

참고 ) 클러스터링 테이블에서의 primary key=클러스터링 키

위에 나온 그림처럼 클러스터링 인덱스의 리프 노드에는 레코드의 모든 컬럼이 같이 저장되어있다. 즉 클러스터링 테이블은 그 자체가 하나의 거대한 인덱스 구조로 관리되는 것이다.

따라서 테이블 데이터의 primary 키 값이 변경되면 실제 데이터 레코드의 위치가 변경된다. 하지만, 주의해야될 점은 클러스터링 인덱스는 MySQL InnoDB 에서만 지원한다는 것!!
이외의 테이블 데이터 레코드는 데이터 레코드가 INSERT 될때 데이터 파일 끝에 저장되고 한번 결정된 위치는 절대 바뀌지 않는다. 또한 레코드가 저장된 주소는 사용자에게 노출되지 않는 MySQL 내부적으로 레코드를 식별하는 아이디로 인식된다. (클러스터링되지 않은 세컨더리(보조) 인덱스 사용 테이블과 관련됨)

primary key 가 없는 테이블을 클러스터링 테이블로 구성하기

primary key 를 대체할 칼럼(클러스터형 인덱스)을 선택하는 우선순위는 이렇다.

primary key
NOT NULL option UNIQUE index 중 첫번째 인덱스
자동으로 유니크한 값 가지도록 증가되는 컬럼을 내부적으로 추가 후 해당 컬럼을 지정

primary key, unique key 없는 테이블에서는 아무 의미 없는 숫자 값으로 클러스터링 되며 이것은 우리에게 아무짝에도 쓸모가 없다. 아무짝에도,,😱

클러스터링 테이블에서의 secondary index 사용

테이블의 secondary index(보조 인덱스) 가 실제 레코드가 저장된 주소를 가지고 있다면, 클러스터링 키 값이 변경될 때마다 레코드의 주소가 변경되고 그때마다 해당 테이블의 모든 인덱스에 저장된 주솟값을 변경해야한다. 이런 번거로움을 줄이기위해 클러스터링 테이블의 모든 secondary index는 해당 레코드가 저장된 주소가 아니라 primary key 값을 저장하도록 구현되었다.

CREATE TABLE employees (
	emp_no INT NOT NULL,
	first_name VARCHAR(20) NOT NULL,
	PRIMARY KEY (emp_no),
	INDEX ix_firstname (first_name)
);
SELECT * FROM employees WHERE first_name='seonghun';
Q) employees 테이블에서 first_name 컬럼으로 검색하는 경우 primary key 로 클러스터링 된 테이블에서는 어떻게 레코드를 찾을까?
A) ix_firstname 인덱스를 검색해 레코드의 primary key 값 확인 후 primary key 인덱스를 검색해서 최종 레코드를 찾음

클러스터링 인덱스의 장점과 단점

장점은 primary key(클러스터링 키) 로 검색시 조회 성능이 빠르다는 것, 테이블의 모든 secondary key 가 primary key 를 가지고 있기 때문에 인덱스만으로 처리되는 경우가 많다는 것(커버링인덱스)
단점은 모든 secondary key 가 primary key 를 가지고 있기 때문에 클러스터링 키 값의 크기가 크면 전체적인 인덱스 크기가 커진다는 것, secondary key 통해 검색할때 primary key 로 다시 한번 검색해야하므로 성능이 느리다는 것, 삽입/수정 시 레코드 저장 위치가 결정/변경 되기 때문에 성능이 느리다는 것

여기서 궁금한 것 💡

클러스터형 인덱스 vs 세컨더리(보조) 인덱스
2가지가 정반대 선상에 놓여있는 서로 다른 인덱스 종류라고 생각했는데, 그게 아닌것 같다! 같이 쓰는 것 같고,, 목적별로 다르게 사용되는,,

정답! 해당 블로그 를 참고
"사실 대부분의 경우 클러스터 인덱스와 보조 인덱스를 같이 사용합니다. 데이터 테이블에 테이터를 넣어야 검색할 수 있기 때문에 무조건 검색만 하는 데이터, 무조건 삽입,수정,삭제만 하는 데이터는 절대 존재하지 않겠죠. 그렇기 때문에 대부분의 경우 하나의 테이블에 클러스터형 인덱스, 보조 인덱스를 같이 사용하며,,"

++

"클러스터 테이블로 저장된다" 의 구조

테이블이 처음 생성될 때 행은 일반적으로 세그먼트의 첫 익스텐트의 첫 블록부터 삽입된다. 정규 테이블로 저장될 경우 서로 다른 테이블들은 서로 다른 세그먼트에 위치하게 된다. 이 말은 테이블이 자신들 고유의 블록을 사용한다는 뜻이다.
(다중테이블 클러스터링) 테이블 클러스터로 저장되면 동일 클러스터 세그먼트를 공유하게 된다. 테이블이 클러스터로 저장되면 클러스터는 물리적 저장 단위가 되고 테이블은 논리적 엔티티 즉, 클러스터의 일부분이 된다.