[우아한테크캠프] 14일차

AWS EC2 와 IAM & Database

오늘은 AWS 가 제공하는 서버인 EC2를 생성하는 방법과 mySQL 를 사용해 Database 쿼리를 연습하는 과정을 공부했습니다. 그 중 가장 어려웠던 개념인 데이터베이스의 인덱스에 대해 정리하겠습니다.

Index?

'기본키로 unique 한 숫자를 설정하면 검색할 때 빠르대~' 라는 말을 얼핏 들었었는데요. 그냥 기본키를 숫자로 설정하면 검색에 도움되는 줄 알았는데 오늘에서야 잘못된 지식이였다는 걸 알게 되었습니다 T^T😭😰

우선 인덱스는 레코드를 검색할 때 좀 더 빠르게 검색하기 위해 사용하는 것은 맞습니다. 

만약 [ '스프링부트 코딩공작소' 책에서 MVC 에 대한 내용을 찾아보시오 ] 했을 때 앞에서부터 쭉 읽어보면서 찾는다면 시간이 많이 걸리겠죠? 그러나 책 뒤에 인덱스를 보고 MVC가 300 페이지에 있다는 것을 알면 해당 페이지를 찾는데에는 얼마 걸리지 않을 것입니다.

이런 원리를 이용하는게 데이터베이스에서의 인덱스입니다. 인덱스 트리에 key-value 값으로 해당 레코드의 위치 정보를 저장해두고, 조회할 때 인덱스 트리를 참고해 해당 레코드를 찾아가는 것입니다. 

'인덱스를 쭉 찾아보는거나, 레코드를 쭉 찾아보는거나 똑같은거 아니야?' 라는 의문이 들 수도 있는데요. 인덱스는 데이터베이스마다 다를 수는 있겠지만, 기본적으로 B+ 트리를 이용합니다. 따라서 search 하는 과정이 처음부터 끝까지 읽으며 찾는 것보다 훨씬 빠를 수밖에 없습니다.

인덱스를 사용하는 것의 장단점은 아래와 같습니다.

장점
- Full Scan 을 하지 않아도 됩니다. 풀 스캔이란 한 데이터를 찾기 위해 전체 테이블의 레코드를 모두 비교해야 하는 작업을 말합니다. 인덱스를 사용한다면 트리를 통해 검색 성능을 개선할 수 있기 때문에 훨씬 빠른 속도로 데이터를 찾을 수 있습니다.

- 범위 검색이 가능합니다. B+ tree 를 사용하기 때문에 특정 범위의 데이터를 구하기 쉽습니다.

단점
- 과도한 인덱스의 사용은 저장공간이 낭비됩니다.

- 인덱스를 많이 생성한다면 데이터를 삽입, 수정, 삭제할 때 시간이 오래 걸립니다. 테이블의 레코드를 생성하거나 수정, 삭제하려고 하면 인덱스를 관리하는 B+ tree 또한 수정해야 합니다. B+ tree 도 디스크에 저장되기 때문에 트리를 수정하고 디스크에 다시 기록해야 합니다. 따라서 여러 인덱스라면 여러 트리를 수정해 기록해야 하기 때문에 시간이 오래 걸립니다.

- 인덱스 생성의 시간이 소요됩니다.

Index를 이용해 레코드 찾기

대체적으로 데이터베이스에서 인덱스 테이블은 B+ tree 로 구현된 경우가 많다고 합니다. 

예를 들어 User 테이블이 있다고 생각해봅시다. 그러면 기본적으로 기본키에 대한 인덱스가 생성될 것이고 그 트리를 위의 이미지에 나와있는 트리라고 하겠습니다.

이 상황에서 'select * from User where id = 3' 와 같은 쿼리를 실행하면 위의 이미지와 같은 상황이 발생합니다.

먼저 인덱스 트리에서 3에 해당하는 노드를 찾아 RID 를 확인합니다. RID 에는 데이터가 존재하는 페이지 번호와 페이지 내에 데이터가 존재하는 위치에 대한 정보가 있습니다. 위의 예시는 3번 페이지의 2번째 칸 ( 데이터) 이기 때문에 3번 페이지에서 2번 데이터의 위치를 찾습니다. 페이지 내의 offset 정보를 보면 두 번째 데이터의 offset 이 10 이므로 10byte 를 찾아가보면 name 값이 hyeona 인 레코드를 찾을 수 있습니다.

Clustered Index VS Non-clustered Index

우선 잘 설명되어 있는 이 블로그 를 한 번 읽어보시길 추천드립니다. 

각 테이블 또는 뷰 당 클러스터드 인덱스는 한 개만 생성할 수 있으며, 넌클러스터드 인덱스는 다수를 생성할 수 있습니다.

Clustered Index
- 테이블 또는 뷰 당 한 개만 생성할 수 있습니다.
- 물리적으로 행을 재배열합니다.
- 정렬되어 있기 때문에 넌클러스터드 인덱스보다 필요한 용량이 적습니다.

Non-clustered Index
- 테이블 또는 뷰 당 여러 개의 인덱스를 생성할 수 있습니다.
- 물리적으로 행을 재배열하지 않습니다.
- 추가적인 인덱스 테이블이 필요하기 때문에 클러스터드 인덱스보다 필요한 용량이 큽니다.

참고사이트

http://asfirstalways.tistory.com/333

https://m.blog.naver.com/PostView.nhn?blogId=eng_jisikin&logNo=220889188747&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F