저장소와 검색 (2)

꿀꿀

 

3장 저장소와 검색 (2)

 

랜덤 I/O 와 순차 I/O

랜덤 I/O :

디스크에서 데이터가 임의의 위치에 저장되고 그 위치에서 데이터를 읽거나 쓰는 방식 복불복

순차 I/O :

데이터가 디스크 상의 연속된 위치에 저장되어 순차적으로 읽거나 쓰는 방식 디스크 이동이 최소화 되서 빠른 성능 보장 

 

 

이전에서 계속해서 보겠다 

 

B Tree 

BTree(이하 비트리) 비트리 알고리즘은 인덱싱 알고리즘 중에서 가장 일반적으로 사용하고 있고 

범용적인 목적으로 사용되는 알고리즘이다 비트리 에서 시작해서 변형 알고리즘이 존재한다 B+Tree 등등 

 

Btree 알고리즘은 원래 값을 변형 시키지 않고 인덱스 구조체 에서 항상 정렬된상태로 유지한다 비트리는 이렇게 생겻다 

 

최상위 노드를 루트노드 

중간 노드를 브런치 노드 

가장 하위 노드를 리프 노드 

 

DB 에서는 인덱스와 실제 데이터가 저장된 데이터는 따로 보관하는데 인덱스의

리프 노드는 항상 실제 데이터 레코드를 찾아가기 위한 주소값이 있다 

 

데이터 파일의 레코드는 정렬돼 있지 않고 임의의 순서로 저장되어 있음 비트리 알고리즘은 완전 이진 트리를 고안해서 만듬 

 

MySQL 에서는 InnoDB 에서 테이블 인덱스의 데이터 파일 관계를 다음과 같이 보여준다 

InnoDB 에서 BTREE

 

 

리프노드에  프라이머리 키 값이 나타나고 있고 이걸 데이터 파일 안에 리프 노드의 페이지의 키값을 따라서 쭉 이어진다 

즉  apple 1234  라고 라는 key value가 있으면 -> 타고타고 가서 데이터를 가지고 올 수 있다 이거다 

하지만
InnoDB에서는 
리프노드에서 레코드의 물리적인 주소값이 아닌 PK를 가지기 때문에
바로 접근할 수 없다 

 

 

이유는 PK가 기본적으로 클러스터링 인덱스로 관리되기 때문이다  따라서 

 

PK로 접근 시 PK인덱스를 한번 더 검색하게 되고 PK 인덱스의 리프노드에 있는 레코드를 최종적으로 읽는다.. 

 

 

번외 클러스터링 인덱스 

MySQL 서버에서 클러스터링은 테이블의 레코드를 비슷한 것(프라이머리 키 기준)들 끼리 묶어서 저장하는 형태로 구현하는데 

이는 주로 비슷한 값들을 동시에 조회하는경우가 많다는점을 착안한것이다 

 

말이 복잡한데 PK가 비슷한 레코드끼리 묶어서 인덱스로 저장한 것 이라고 보면 될꺼같다 

 

따라서 클러스터링 인덱스는 기본키에만 적용되는 내용이라고 보면 된다 이것도 인덱스이기에

PK 기반의 검색이 매우 빠르지만 저장이나 변경이 상대적으로 느리다 

 

여기서 중요한건 프라이머리 키 값에 의해 레코드의 저장 위치가 결정된다는점  또한 변경한다면 

레코드 물리적인 저장 위치가 바뀌어야한다는것을 의미 

 

BTree 랑 유사해보이는데 
잘 보면 리프노드에 모든 레코드들이 저장되어 있는걸 확인할 수 있음 
즉 클러스터링 테이블(인덱스)은 하나의 거대한 인덱스로 움직임 
하나가 바뀌면 전체가 동기화를 해야하니 상대적으로 느릴 수 밖에 없음 

 

 

다시 BTree 구조를 살펴보자 

 

 

다음과 같은 그림은 InnoDB 테이블에서 데이터 파일의 관계를 보여주는데 InnoDB 에서는 테이블에서 RoWID 역할을 한다 

ROWID는 데이터베이스에서 각 행(row)에 대해 고유한 식별자를 제공하는 특수한 컬럼
주로 Oracle과 같은 RDBMS에서 사용되며, 해당 데이터가 저장된 물리적 위치를 나타낸다 

 

 

결국 세컨더리 엔덱스를 통해 데이터 파일의 레코드를 찾아가는 방법 그림을 보여주는게 윗 그림인데 

세컨더리 인덱스 -> 클러스터링 인덱스(PK 인덱스) 를 제외한 모든 인덱스

 

위에서 언급하였지만
리프노드에서 레코드의 물리적인 주소값이 아닌 PK를 가지기 때문에
바로 접근할 수 없다 이건 결국 세컨더리 인덱스를 말하는 말이였다

 

 

즉, 프라미머리 키 값을 이용해서 프라이머리 키 인덱스를 한 번 더 검색하고 

프라이머리 키 인덱스의 리프 페이지에 저장돼 있는 레코드를 읽는다 

 

 

그렇다는건 InnoDB 에서는 모든 세컨더리 인덱스 검색에서 레코드를 읽기 위해서는

반드시 프라이머리 키를 저장하고 있는 BTree를 다시 검색해야함