[DB] 12-6. Disk-Block Access

디스크 I/O에 대한 요청은 데이터베이스 시스템에 의해서 생성되며 쿼리를 처리하는 하위 시스템이 대부분의 디스크 I/O를 처리한다. 각 요청은 디스크 식별자와 디스크의 논리적 블록 번호를 지정한다.
DB 데이터가 운영체제 파일에 저장된 경우, 요청은 파일 식별자와 파일 내의 블록 번호를 지정한다

데이터베이스 데이터가 운영 체제 파일에 저장된 경우, 요청은 파일 식별자와 파일 내의 블록 번호를 지정한다. 데이터는 디스크와 주 메모리 간에 블록 단위로 전송된다.

앞서 다뤘듯이, 디스크로 부터 블록을 요청하는 sequence는 순차 접근 패턴(sequential access pattern)과 무작위 접근 패턴(random access pattern)으로 나뉜다고 했다.

• 순차 접근 패턴 : 연속적인 요청은 연속된 블록 번호에 대한 것으로, 해당 블록 번호는 동일한 트랙이나 인접한 트랙에 위치한다.
• 무작위 접근 패턴 : 연속적인 요청은 디스크에 무작위로 위치한 블록에 대한 것이다.

각각의 요청은 seek(disk arm이 재위치하는 시간)과 적은 수의 1초당 무작위 I/O 연산을 필요로 한다.

많은 기술들이 블록에 접근하는 속도를 향상시키기 위해 발전되어 왔다.
속도 향상 방법으로는 접근 수를 최소화하거나 특히 무작위 접근 횟수를 최소화하는 방향으로 발전했다.

이를 구현하기 위한 기술들에 대해서 다뤄볼 것이다. SSD는 자기 디스크보다 무작위 접근 속도가 빠르기 때문에 무작위 접근으로 인한 영향이 상대적으로 적다. 하지만, SSD로 부터의 데이터 접근은 여전히 아래의 기술을 이용하면 이득을 가져올 수 있다.

• Buffering (13.5에서 자세히 다룸)

• Read-ahead

디스크 블록에 접근했을 때 똑같은 트랙의 연속적인 블록들을 in-memory 버퍼에서 읽어온다.

1) 순차 접근 : read-ahead 방식이 블록들이 요청받았을 때 많은 블록들이 이미 메모리에 존재한다는 걸 보장해주고 디스크 탐색(disks seeks)과 회전 지연(rotational latency)에 소요되는 시간을 최소화한다. 또한 운영체제는 규칙적으로 운영체제 파일의 연속적인 블록들에 대해 read-ahead를 수행한다.

2) 무작위 접근 : 별로 유용하지 못하다

• Scheduling

cylinder에 있는 몇몇 블록들이 디스크에서 메인 메모리로 전송되어야 한다면, 블록들이 헤더를 지날 순서가 되었을 때 블록을 요청함으로써 접근 시간을 아낄 수 있다. 만약에 원하는 블록들이 서로 다른 cylinder에 위치한다면 disk arm의 움직임을 최소화할 순서로 블록을 요청하면 이득이 된다.

Disk-arm 스케쥴링 알고리즘은 처리할 수 있는 액세스의 개수가 늘어나도록 트랙에 대한 액세스를 배치하려고 시도한다.
많이 사용되는 알고리즘은 elevator 알고리즘이다. 많은 엘리베이터가 동작하는 방식과 똑같다.

ex) arm이 가장 안쪽에서 디스크의 바깥으로 이동한다고 가정한다.

엘리베이터 알고리즘에 따라, 접근 요청이 있는 각 트랙에 대해 arm은 해당 트랙에서 멈추고 트랙에 대한 요청을 서비스하고 트랙에 대해 대기하고 있는 요청이 없을 때 까지 계속 바깥으로 이동한다.
이 지점에서 arm이 방향을 바꿔서 안쪽으로 이동하다가 트랙에 대한 요청이 있는 곳에서 다시 멈춘다. 마찬가지로 대기하고 있는 요청이 없을 때 까지 계속 안으로 이동한다.

Disk controller는 성능을 개선하기 위해 읽기 요청의 순서를 재배치하는 작업을 수행한다.
왜냐하면, 컨트롤러들이 디스크의 블록의 구성, 디스크 플래터의 회전 위치, 디스크 암의 위치를 잘 알고 있기 때문이다.

이러한 재배치가 가능하려면 디스크 컨트롤러 인터페이스가 다수의 요청이 큐에 추가될 수 있도록 해야 한다.
결과값들은 요청 순서와 다른 순서로 반환될 것이다.

• File organization

블록 접근 시간을 줄이기 위해서 데이터에 액세스할 때 예상되는 방식과 가능한 일치하도록 디스크의 블록을 구성할 수 있습니다.

ex) 파일이 순차적으로 접근되길 기대 ⇒ 이상적으로는 인접한 cylinder에 파일의 모든 블록을 순차적으로 유지해야 한다.

요즘 디스크는 정확한 블록의 위치를 운영체제에게 감추지만 인접한 블록에 연속된 번호를 부여하는 논리적인 블록 번호를 사용한다. 파일의 인접한 블록을 연속적인 번호가 부여된 디스크 블록에 할당함으로써 운영체제는 파일들이 연속적으로 저장되어 있다고 확신하게 된다.

단일 연속 블록 시퀀스로 큰 파일을 저장하는 것은 디스크 블록 할당에 어려움을 겪을 수 있다. 대신, 운영 체제는 한 번에 여러 개의 연속된 블록(범위)을 파일에 할당한다. 이때 연속된 블록을 extent라고 한다. 파일에 할당된 다른 extent는 디스크에서 서로 인접해 있지 않을 수도 있다.

파일에 순차적으로 접근하는 건 블록이 무작위로 할당된 경우
하나의 블록당 한 번의 seek이 필요한 대신 하나의 extent 당 한 번의 seek이 필요하다.
즉, 충분히 큰 extent에서 데이터 전송 비용과 연관된 seek의 비용은 최소화될 수 있다.

그동안 여러개의 작은 요소들을 갖고 있던 연속된 파일은 쪼개졌(framented)을것이다. (디스크에 있는 블록들이 쪼개져 있을 것이다)

파편화(fragmentation)를 줄이기 위해 시스템은 디스크에 백업을 위한 데이터를 만들어서 전체 디스크를 복원할 수 있다.
복원 연산은 각각의 파일의 블록을 연속적으로 다시 쓴다.

몇몇 시스템은 디스크를 스캔하고 나서 파편화를 줄이기 위해 블록을 이동시키는 기능을 갖고 있다. 이 기술에서 성능 향상이 눈에 띄게 좋아진다.

• Non-volatile write buffers

메인 메모리의 데이터가 전원 고장으로 인해 손실되기 때문에 데이터베이스 갱신에 대한 정보는 시스템 충돌을 견딜 수 있도록 디스크에 저장되어야 한다. 이러한 이유로 트랜잭션 처리 시스템과 같은 업데이트 중심의 데이터베이스 응용프로그램의 성능은 디스크 쓰기의 지연 시간에 따라 크게 달라진다.

플래시 메모리가 현재 Non-volatile write buffers를 사용하는 주요한 기기이다.

데이터베이스 시스템(또는 운영체제)이 디스크에 블록이 작성되도록 요청할 때, 디스크 컨트롤러는 블록을 Non-volatile write buffers에 작성하고 작성이 완료되면 운영체제에게 이 사실을 알린다.
뒤이어 컨트롤러는 disk arm 이동을 최소화하는 방식으로 데이터를 목적지에 있는 디스크에 작성할 수 있다.(ex. 엘리베이터 알고리즘 같은 걸 사용해서)

만약 Non-volatile write buffers을 사용하지 않고 쓰기 재배치가 이뤄지면, 데이터베이스는 시스템 충돌이 발생할 때 일관성을 갖지 못하게 될 것이다. 왜냐하면, 복구 알고리즘이 특정 순서에 의해 작성된 데이터 쓰기에 따라 달라지기 때문이다.

데이터베이스 시스템이 블록 작성을 요청할 때, 데이터베이스 시스템은 NVRAM 버퍼가 꽉 찼을 때 delay를 알린다.
시스템 충돌로 인한 복구 과정에서 NVRAM에 대기 중인 버퍼화된 쓰기 작업은 디스크에 다시 기록된다.
NVRAM 버퍼는 RAID 컨트롤러에서 자주 발견된다.

---

솔직히 이해가 안되는 부분이 너무 많다. 계속 복습하면서 이해될 때 마다 자세하게 내용을 붙이자.