[database] DBMS는 어떻게 data에 접근할까 + DB와 메모리 계층구조

본 게시글은

서울대학교 데이터사이언스대학원 이상원 교수님의

데이터사이언스 응용을 위한 빅데이터 및 지식관리시스템 수업을

학습을 목적으로 재구성하였습니다

---

이번 수업 내용은

제목을 뭐라고 붙일지 약간 고민했다

뭔가 마땅한 내용이 없는 느낌

 

아무튼 전반적인 내용은

DBMS와 disk IO에 관한 내용이며

메모리 계층구조를 살펴보고

이게 DBMS에 어떤 영향을 미치는지를 살펴본다

 

 

저번 시간에 DBMS에서 데이터를 가져올 때

DRAM의 buffer cache를 사용한다고 했다

 

실제로 DBMS가 SQL을 처리하기 위해서는

디스크에 있는 데이터를 DRAM으로 가져와야하는데

이때 IO가 발생하고 이 단위는 page(=block)이고

일반적인 DBMS의 page는 8KB라고 설명했다

 

 

DBMS에서는 system catalogs를 이용해서

table 이름, column, index, IC와 같은 정보들을 저장한다

 

이런 것들을 다 DBMS에서 별도로 관리하고있고

이런걸 catalog 혹은 metadata라고 부른다

이런 구조들도 전부다 2차원의 테이블 형태로 저장된다

 

 

저번 시간과 이전 시간 모두

internalDB에서 File and Access Methods에 대해 배운다

 

이번시간에는 저번 시간에 배우고

남은 부분을 마저 배운다고 한다

 

 

위 쿼리를 잘 살펴보자

 

위 쿼리는 table 전체를 스캔하는

full table scan query이고

full table scan은 하나의 대표적인 access method이다

 

DBMS에는 query optimizer가 있는데

이 친구는 내가 해당 쿼리를 수행할 때

full table scan으로 수행한다면

이 때 비용이 얼만큼 될 것인지를 추정한다

 

그렇다면 DBMS에서 쿼리 수행 시에

측정하는 비용의 기준은 무엇일까

 

DBMS의 data들은 disk에 저장되어있다

이러한 이유로 당연히 read를 할 때 IO비용도 발생하고

컴퓨팅 비용도 발생한다

크게 생각할 수 있는 비용은

CPU가 처리하는 time, disk IO time 정도인데

CPU time은 상대적으로 disk IO time에 비해서는 약하다고

DBMS에서는 간주한다

 

따라서 DBMS에서는 disk IO를 주된 비용으로 생각하고

해당 쿼리가 disk IO를 얼만큼 유발하는지가 비용이 된다

 

이전시간에 우리는 page의 집합인 extent라는 개념을 배웠다

따라서 만약 full table scan을 수행할 때

table의 page가 총 10만개라고 한다면

page 단위로 가져오면 10만번을 access 해야하지만

extent 단위로 왕창왕창 읽어온다고 하면

access를 줄일 수가 있다

 

 

따라서 full table scan을 수행할 시에

발생하는 cost model이다

 

위에서 설명한대로 cost는 disk IO의 비용이기 때문에

cost는

전체 block(page)의 개수에서

실제 한 번의 IO에서 몇 개의 block을 읽어올 수 있는지로

나눈 값이 된다

 

위에서 actual과 adjusted가 있는데

actual은 우리가 실제로 disk IO 한 번에

읽고싶었던 block의 개수이고

adjusted는 실제 환경적인 이유로

실제로 disk IO시 한 번에 읽어온 block의 개수이다

 

그렇다면 왜 16개의 block을 한 번에 disk에서 읽어오고싶은데

그게 잘 안되는 것일까?

가장 대표적인 문제는 buffer cache 때문이다

buffer cache에 이미 데이터가 올라가있으면

disk에서 읽어올 필요가 없게 되고

그럼 연속적으로 block을 가져올 수가 없게 된다

또한 물리 디스크에 불연속적으로 저장되어있는 등

아무튼 현실적으로 actual한 값으로 읽어오지는 못한다

 

따라서 정확한 cost를 게산할 수는 없어서

disk IO 비용을 guess로 추정할 수 있는 것이다

예를 들어 page의 개수가 10만개라면

원래 16개씩 가져오고 싶었으나

10개씩만 가져오게 되었으므로

비용은 990 어쩌구.. 가 된다고 한다

 

 

아무튼 따라서 cost는 정확하게 알 수는 없고

추정만 할 수 있다

그리고 이 추정은 다 통계를 기반으로 한다

 

그래서 요즘은 머신러닝으로

이런걸 추정하려고하는 연구들도 있다고한다

 

 

 

DB에서는 query type으로는 크게

transcation과 분석이 있다

이를 OLTP와 OLAP라고 하는데

각 상황에서 어떻게 DB가 data에 접근해서 가져오는지를 살펴보자

 

우선 위 예시는 OLAP이다

TEST라는 테이블에서 b 컬럼의 전체 합을 구하는 쿼리이고

전형적인 OLAP 스타일의 쿼리이다

 

우리가 쿼리를 날리면 optimizer가

select statement

sort aggregate

table access full

이 방식처럼 쿼리를 수행한다

 

그리고 오른쪽에 Cost가 나와있는데

이 부분은 옵티마이저가 추정할 때

이 정도의 비용이 발생할 것이라고 예측한 것이다

그리고 그 아래에 있는건

실제로 측정하게 된 통계이다

 

physical reads는 실제 disk에서 몇 개를 읽어왔는지이다

 

아무튼 DBMS는 페이지를 한 개씩 접근하지 않고

10개 혹은 16개씩 왕창왕창

disk에서 읽어오게 된다

8KB의 page들을 여러 개씩 읽어오는 것이다

 

이는 OLAP의 경우이다

 

 

 

그렇다면 이제 OLTP의 경우를 살펴보자

 

위 쿼리는 특정 조건에 만족하는 tuple만 가져오는

전형적인 OLTP 쿼리이다

 

만약 전체 row가 100만개가 있다고 하면

100만개 중에서 1개만 가져와야한다

따라서 point query라고 불리기도한다

 

만약에 A column에 대해서 index가 없다면

optimizer가 할 수 있는 access method는

full table scan뿐이다

 

 

하지만 당연히 전체를 다 scanning하는 것은

너무 비효율적이라는 생각이 들 것이다

그래서 우리가 index를 생성하는 것이다

그리고 pk의 경우 index가 default로 있다

 

heap table과 별도로 index를 생성하면

tree 형태의 index가 만들어진다

그럼 만약 위의 OLTP 쿼리가 들어오면

옵티마이저는 우선 index가 있는지를 확인하고

만약 index가 있다? 그럼 검색할 때

index를 이용해서 검색하게 된다

index를 타고 검색한 다음 조건을 만족하는 record id를 반환하게 되고

그 id를 이용해서 tuple을 찾게된다

 

OLTP style 쿼리는 대부분

point query

혹은 어디서부터 어디까지의 tuple들을 찾는

range query가 대부분이기 때문에

이런 경우 대부분 index를 생성해준다

 

하지만 다음 시간에 index에 대해 자세히 배우겠지만

이 Index들도 결국 다 page단위로 구성되게 되고

tree에서 각 노드들도 다 8KB의 page단위로 구성된다

 

따라서 원래는 full table scan을 수행하면

1000000을 access해야하는데

index를 쓰면 작게는 3~4번 정도에도 가능하다고 한다

 

그래서 DBMS에서는 IO per second가 매우 중요하다고 한다

 

 

위에서 지금까지 설명한 내용은

우리가 우리의 컴퓨터(labtop 혹은 server)에서

CPU, DRAM, disk가 각각 있고

그 위에서 DBMS를 올린 경우를 말했다

 

하지만 우리가 나중에 회사에 가서 다루게 될 DB는

대부분 cloud DB이다

 

snowflake나 databricks가 전형적인 OLAP용

cloud 기반의 DB이고

OLTP도 postgres,

aurora라고 하는 amazon의 cloud형태의 DB를 사용한다

 

cloud DB를 사용하는 경우

storage 부분이 약간 달라지는데

object storage 방식을 주로 사용한다고 한다

 

object storage는 object단위로 데이터를 저장하는 storage 방식으로

amazon의 S3 방식이 대표적인데

3가지의 객체를 저장하는 방식이다

 

 

 

지금까지 배운 내용의 요약인데

한 번 읽어보라고 하셨다

 

 

다음 내용은 disk와 파일이다

 

이걸 잘 이해하려면

메모리 계층구조에 대해서 잘 알아야한다

DBMS에서 쉽게 설명하는 메모리 계층구조는

CPU -> CPU cache -> DRAM -> Disk의 구조이다

CPU cache는 CPU 안에 있는 on chip이다

아래로 내려갈수록 크고 느리고 싸진다

그리고 위 부분들이 SQL을 처리하기 위해서

필요한 부분들이다

 

 

volatile하지 않은 disk는 크게

SSD와 HDD가 있다

요즘은 SSD의 시대인데

두가지 종류의 disk에 대해서 잠깐만 살펴보자

 

 

메모리가 가질수 있는 최대 속력이다

DRAM의 경우 위는 100GB/s라고 했지만

초당 TB까지도 갈 수 있다고 한다

SSD의 경우 초당 10GB정도는 된다고 한다

아무튼 HHD는 초당 130MB/s (...) 정도라고 한다

 

좋은 메모리일수록 속도가 빨라지지만

당연하게도 가격 차이가 굉장히 많이 난다

 

작년 기준 만약 내가 1000달러가 있다고 한다면

DRAM은 250기가

SSD는 9TB

HHD는 50TB를 살 수 있다고 한다

 

아무튼 그래서 이러한 메모리들은 계속 발전하고 있다

 

 

storage를 평가할 수 있는 요소들로는

실제 용량인 capacity

속도인 bandwidth

응답시간은 latency가 있다

 

하드디스크와 SSD의 경우

각 부분에서 위와같이 정리된다고 한다

 

 

 

storage device의 경우 중요한 점은

무게와 그리고 shock에 얼마나 잘 견디는지였다고 한다

HDD는 10년전만해도 인기있는 storage였다

하지만 이제 FlashSSD가 시장을 장악하게 되었다고한다

모바일 디바이스에 FlashSSD 장착하는 것을 시작해서

노트북, 서버까지 FlashSSD를 장착하고 있다고 한다

 

왜냐하면 SSD는 하드디스크의 여러 문제들을

해결할 수 있기 때문이다

 

 

 

아까 설명했던 메모리 계층구조이다

 

cache위에 있는 부분은

사이즈가 MB단위가 최대라고한다

DRAM은 GB에서 요즘은 TB까지도 가고있고

storage는 최소 100GB에서 TB까지 간다고한다

 

교수님께선 이러한 메모리 계층구조는

교수님 은퇴는 물론이고

우리가 은퇴할 때까지(...)

사라지지 않을 것 같다고 하셨다

 

 

좀 더 자세한 내용인데

관심있으면 읽어보라고 하셨다

 

 

 

아무튼 요즘은 SSD의 세상인 것은 맞지만

교과서에 하드디스크에 관한 내용이 나와있어서

일단은 설명해주겠다고 하셨다

 

그냥 역사공부한다고 생각하라고 하셨..ㅋ

 

아무튼 위 ppt에 있는 사진이 하드디스크이고

1950년대에 IBM에서 개발한 모델이다

 

예전에 음악을 들을 때 필요했던 tape와 같은 구조는

정보에 접근할 수 있는 access pattern자체가

처음부터 순차적으로 읽을 수밖에 없는 구조였다

 

하지만 IBM에서 개발한 하드디스크는

주소만 알고있으면 random access가 가능하였다

따라서 storage를 할 때

어떤 순서로 데이터를 저장하고

어떤 순서로 접근하느냐와 같은 부분에서

하드디스크는 장점을 갖고 있었다

 

 

옛날의 하드디스크를 조금 더 확대해서 살펴보자

 

원 형태에 데이터가 저장되어 있는데

저 track안에 Page 단위의 데이터가 저장되어있다고한다

 

중간에 회전축인 spindle이 있고

앞부분에 데이터를 sensing해서 읽고 쓰는 부분인 head가 있다

그리고 팔인 disk arm이 있다

 

그래서 spindle을 기준으로 계속 5400rmp으로 돌아가며

데이터를 읽는 방식인데

회전을 해야하기 때문에 기계공학적인 요소가 들어간다

아무튼 그래서 아무리 성능을 끌어올려도

초당 IO가 100회 정도라고 한다

 

우리가 지금도 DBMS에서

extent단위로 연속적으로 할당하는 이유가

같은 track에 연속해서 디스크가 와서

쭈욱 읽어들이기만하면 상대적으로 빨랐기 때문에

그런 방식을 채택한 것인데

아무튼 이러한 하드디스크의 특성 때문에

DBMS의 extent 단위의 space allocation이 나오게 된 것이라고 한다

 

또 중간에 데이터를 쓰다가 전원이 꺼졌을 때

데이터를 쓰다가 중간에 멈춰버리면 절대 안된다

그래서 atomic write를 보장해야하는데

하드디스크는 이게 어려웠다고한다

DBMS에서는 이러한 원자성이 굉장히 중요한 문제이기 때문에

이런 부분들도 고려를 해야한다고 한다

 

 

 

하드디스크가 데이터를 접근하는 방식이다

 

seek time이라는 개념이 있는데

이는 arm이 disk head를 track에 닿게 하는 시간이고

mechanical time이다

rotational time이 있는데

이는 원판이 회전하는 시간이고

이것도 mechanical time이다

transfer time은 데이터가 왔을 때

이걸 읽어들이는 시간을 말한다

 

아무튼 하드디스크는 위의 시간들때문에

초당 IO가 100회를 넘기 힘들다고 한다

 

따라서 그 당시에는 최첨단 기술이었지만

이제는 많이 밀리게 되었다고한다

 

 

아무튼 이러한 하드디스크의 구조 때문에

지금도 데이터를 인접하게 저장한다고 한다

 

 

 

위 그림은 Jim Gray란 분이 그린 그림이라는데

register, cache, memory, disk까지 데이터를 찾아가는 과정을

우리 머리..에 비유해서 그린 그림이라고 한다

 

실제 register는 정보가 우리의 머리에 있는거고

(바로 알 수 있으니까)

cache는 hotel 방 정도 에 있는 수준

 

그러고 disk로 갈수록 Pluto.. (명왕성..?)에

있는것과 유사하다고..한다

 

 

 

세월이 흐르면서 CPU와 Main Memory 쪽은

발전이 굉장히 빨랐다고 한다

그래서 윗계층들은 발전이 굉장히 많이 되었지만

disk쪽은 mechanical한 issue 때문에

발전이 굉장히 느렸다

 

안그래도 메모리 사이에 간극이 컸는데

이러한 발전 속도가 더 간극을 키웠다고한다

 

따라서 그 간극을 조금이라도 줄이기위해서 나온게

FlashSSD였다

 

 

 

DRAM, HDD, SDD의

가격, 용량 측면에서의 발전 과정이라고 한다

 

 

 

 

그렇다면 Disk IO는 이렇게 비용도 크고한데

모든 데이터를 main memory에 저장할 수는 없는 것인가?

 

main memory를 통해서 disk에 와서 읽는 부분은 있지만

결국은 DB의 데이터들은 disk에 써야하기때문에 

main memory에 모든 데이터를 가져온다고해도

그렇게 DB측면에서는 크게 기여하지 않는다고한다

 

따라서 DBMS는 95%정도가

flash memory를 기반으로 이루어진다고한다

(그런데 in memory DB도 있지않나?)

 

 

 

마지막으로 DBMS가 storage 특성을 제대로 이해하고

어떻게 DBMS를 Design 할 수 있을까에 대한 내용이다

DBMS는 데이터를 어디에, 어떻게, 언제

접근할 수 있을지를 효율적으로 제어해야한다

 

가장 처음은 disk space management이다

disk에 데이터를 어디에 저장할 것인지에 대한 내용이다

 

그 다음은 buffer management 내용이다

어느 시점에 데이터를 디스크에서 읽어오고

어느 시점에 디스크에 다시 쓸 것인지에 대한 내용이다

 

query optimization과 execution은 

쿼리를 실행할 때 어떻게 데이터에 접근할지에 대한 내용이다

 

아무튼 위 3가지 요소들이

DBMS를 설계할 때 고려되어야하는 요소들이라고한다

---