반응형

디스크 블록

 

데이터를 순차적으로 정렬해서 저장해야 하는 이유

컴퓨터에서 영속적인 데이터를 보관하기 위해

물리적인 디스크에 정보를 저장한다.

cpu의 관점에서 디스크에서 데이터를 읽어오는 io시간은 굉장히 큰 시간이다.

디스크에서 특정 데이터를 찾는데는 물리적인 rotational delay와 seek time이 필요하기 때문이다.

그렇기 때문에 최대한 디스크에 적게 접근하는 게 중요한 문제이다.

 

데이터를 저장할 때는 메모리의 output Buffer에 있는 내용을 디스크에 쓰고,

컴퓨터에서 디스크에 있는 정보가 필요해서 불러올 때는 디스크의 블록 단위를 기준으로 메모리에 데이터를 불러온다.

 

이때 중요한 것중 하나가

컴퓨터에서 특정 데이터가 필요할 때

디스크에 access해서 디스크로부터 메모리로 블록을 읽어와야 한다.

 

이때 필요한 레코드가 block의 어디에 위치해 있는지 찾는 것이 중요하다.

만약 레코드가 10억개가 존재하는 상황에서 하나의 레코드를 찾아야 한다고 생각해보자

레코드들이 모두 무작위로 위치해 있다면 최악의 경우 레코드를 10억개를 다 찾아보아야 한다.

이 방법은 너무 오래걸린다.

 

특정 레코드 조회 빨리 하기 위해서 key값을 기준으로 binary search를 한다면

굉장히 빠르게 찾을 수 있다. binary search는 logN 만큼 조회하면 해당 레코드를 찾을 수 있기 때문이다.

log(10억)은 30에 가깝다.

위에서 데이터가 무작위로 위치해있을 땐 최악의 경우 10억번을 봐야했는데,

데이터가 정렬되어 있다면 30번만 보면 디스크에서 원하는 데이터를 찾을 수 있다!

 

즉 데이터가 일정하게 정렬되어 있는 화일을 sequential한 파일, 순차화일이라 부르는데

화일이 순차화일로 존재한다면 데이터 조회를 굉장히 빠르게 할 수 있는 것이다.

 


트랜잭션 화일과 마스터 화일 

 

위에서 처럼 화일에서 데이터를 순차적으로 저장해야 조회를 빠르게 할 수 있다.

그런데 단순히 화일을 순차적으로 저장하면 문제가 발생한다.

 

데이터에 특정 레코드가 삽입된다면

모든 데이터를 다시 써야하는 문제가 발생하기 때문이다.

 

예를 들어서

데이터 레코드가 총 10억개 정도 있다고 생각하자.

10억개 데이터는 모두 정렬되어 있다.

 

이때 화일에 데이터를 하나 삽입해야한다.

그런데 5억개 데이터와 5억개 데이터 사이에 새로운 데이터가 하나 추가되어야 된다고 생각해보자.

그렇다면 새로운 화일을 만들어

기존 5억개 데이터를 그대로 쓰고, 새로운 데이터를 하나 추가하고

다시 또 5억개 데이터를 써야한다.

 

즉, 순차적인 화일 구조를 유지하기 위해서 데이터가 갱신될 때마다 엄청난 양의 데이터를 다시 써야한다.

이런 구조는 실제로 사용할 수 없다. 데이터 조회는 빨리 할 수 있지만 조회를 빨리 하기 위해서 화일을 다시 쓰는 시간이 너무 오래걸린다.

 

이러한 문제를 개선하려면

순차 화일 구조를 유지하되, 데이터 갱신하는 횟수를 줄여야한다.

 

이를 해결하기 위한 방법이 마스터 순차화일을 하나 유지하고,

데이터 갱신 요청을 기록해주는 트랜잭션 화일을 하나 더 만들어서,

일정 간격마다 트랜잭션 화일에서 마스터화일로 데이터를 merge해주면 된다.

이전에는 데이터 갱신이 될때마다 화일을 다시 써야 했다면,

이제는 데이터 갱신 기록을 트랜잭션 화일에 쭉 저장해두었다가, 정해둔 간격마다 마스터 화일에 저장하면 된다.

 

이렇게 하면 마스터 화일에서 데이터를 빠르게 조회할 수 있고,

순차화일에서 데이터를 갱신하는 문제도 해결할 수 있다.

 

다만 이도 완벽할 수 없는게 데이터 갱신을 일정 주기마다 하기 때문에

트랜잭션 파일에 저장되었지만 마스터 파일에 저장되지 않았다면 데이터 조회를 할 수 없다.

그래서 비즈니스 로직에 따라 일정한 간격을 정하는 것이 굉장히 중요하다.

 

 

 

+ Recent posts