[ADV_db]Chap 12-14. 연습문제

---

# Chap 12 . Physical storage system

---

12.1 SSD를 저장장치로 사용할 수도 있고, 아니면 저장장치와 메모리간의 버퍼로 사용할 수도 있다. 이 중 만약 real-time에 사용되는 SSD라면 어떤 용도로 쓰는게 적합할까?그리고 만약 엄청 큰 릴레이션이 있는데 이 중 일부만 자주 이용되는 경우라면 SSD를 어떻게 활용하는게 좋을지 설명하시오

• Real-time의 경우 저장장치의 용도로 쓰는 게 더 성능을 보장할 수 있다.
• 큰 릴레이션의 경우에는 자주 이용하는 부분을 캐시나 버퍼의 형태로 SSD를 사용하는 것이 좋다.

12.2 어떤 데이터베이스는 디스크에서 안쪽 Track은 사용하지 않고 바깥쪽 Track만 사용하는데 이런 경우의 장점에 대해 설명하시오.

• 어차피 안쪽이나 바깥쪽이나 같은 속도로 돌기 때문에 바깥쪽을 사용할 수록 단위시간당 읽을 수 있는 데이터의 양이 더 많다.또한, 바깥쪽만 사용하면 disk arm을 움직일 필요가 없기 때문에 훨씬 빠르다.

12.3(a) Flash translation table은 메모리에 어떤 형태로 있는지 설명하시오.

• Flash translation table은 물리적인 페이지 주소를 배열의 형태로 가지고 있고, 이를 논리적 페이지와 연결해두고 있다. 따라서 각 페이지의 주소와 같은 용량을 차지한다.

12.3(c) 6연속적인 논리적 페이지에 연속적인 물리적 주소가 입력되는 경우 어떻게 Flash translation table의 크기를 줄이겠는지 설명하시오.

• 이런한 경우 맨 첫 페이지의 주소만 저장하고 나머지 주소는 저장하지 않는다면 테이블의 크기를 줄일 수 있다.

12.4 아래의 그림처럼 패리티 블록이 위치해 있는경우 어떤 문제가 발생하는지 설명하시오.

• 위와 같은 경우 Pi와 B(4i-3)이 같은 디스크에 저장되기 때문에 데이터를 복구하지 못할 수도 있다.

12.7 모든 블록이 디스크 블록에도 연속적으로 있게 된다면 연속적인 파일을 읽어오는 시간이 아주 짧을 텐데 왜 그게 실용적이지 않은지 설명하시오. 그리고 그 대신 운영체제가 연속적인 read 작업에 걸리는 시간을 최소화하기 위해 어떤일을 하는지 설명하시오.

• 만약 큰 파일이 연속적인 디스크에 연속적으로 저장되어 있다면 딱 한번의 seek 과정을 통해 이루어 질 수 있지만, 현실적으로 삭제와생성 과정으로 인해 파일들이 분산되어 있다. 그렇기 때문에 운영체제는 크기가 고정되어 있지만 사이즈는 어느정도 큰 블록을 할당하여 어느정도의 사이즈만큼씩은 한번만 seek할 수 있도록 해준다.

---

# Chap 13. Data Storage Structures

---

13.1 아래의 그림에서 record5를 지운다고 할 때 어떤 방법이 좋을지 설명하시오

• 5를 지우고 6이후의 레코드를 앞으로 한칸씩 당기는 것은 너무 많은 File I/O를 필요로 한다.
• 다른 레코드로 그 부분을 채우는 것은 I/O는 적지만 순서가 망가진다.
• 그 부분을 표시를 해두고 그 이어나가는 것은 I/O도 적고 순서도 망가지지 않지만, 점점 그런게 많아지면 구멍이 많이 생겨 퍼포먼스에 영향을 줄 수 있다.

13.4(a) Free-space Map의 한 비트 사이즈를 3bit로 할 때, 8bit일 때보다 좋은 점과 나쁜 점에 대해 설명하시오.

 

• 좋은 점은 8비트일 때보다 삽입이나 삭제가 일어나더라도 갱신을 해야하는 경우가 줄어들기 때문에 좋긴 하지만, 그만큼 빈 공간을 찾기 위해 더 많이 찾아야 하거나 아니면 더 많은 공간이 낭비될 수 있다.

13.4(b) 레코드의 삽입과 삭제 시 비트맵을 어떻게 갱신할지 설명하시오.

•  삽입이나 삭제가 일어날 때마다 비트맵에서의 수준이 바뀌었는지를 확인해보고 바뀌었다면 변경해준다. 하지만, 해당 수준을 넘기 전까지는 비트맵에 접근할 일이 없다.

13.4(c) 비어있는 레코드들을 연결리스트로 만들었던 Free list보다 비트맵방식이 더 편한 점을 설명하시오.

• free list의 경우 레코드가 들어오면 맞는 사이즈의 레코드가 나올 때까지 탐색이 이루어지는데 여기서 많은 Overhead가 일어난다. 하지만 비트맵은 큰 블록이나 페이지들에 대해서도 업데이트나 빈 공간을 찾기가 훨씬 쉽다.

13.5 버퍼에 블록이 있는지와 어디에 있는지를 빨리 찾는 것은 매우 중요한데, 데이터베이스의 버퍼 사이즈가 아주 크다고 가정할 때 어떤 자료구조를 사용하는 게 좋을지 설명하시오.

• 큰 데이터베이스에서는 해시 테이블을 사용하는 것이 일반적이다. 해시  함수는 선형 탐색이 이루어질 버켓을 찾는 것을 도와준다.

13.6 대학교에서 큰 레코드를 가지고 있다고 할 때 이를 어떻게 partition할 건지 그리고 이럴 경우의 장점과 단점에 대해 설명하시오.

• 년도나 학기로 나누어 저장하면 오래된 부분은 더 싼 저장장치에 저장하고 최근 레코드는 좋은 저장장치에 나누어 저장할 수 있고, 년도나 학기를 포함한 쿼리를 실행 시 전체를 뒤지는 거보다는 더 빠르게 작동한다.
• 하지만, 여러 년도에 걸친 레코드를 검색하는 경우에는 여러 저장장치에 접근해야 하기 때문에 매우 느리다.

13.8 Postgre SQL은 보통 운영체제에게 대부분의 메인 메모리를 주고 작은 버퍼만을 사용하는데, 이럴 때의 장점과 한계에 대해 설명하시오.

• 장점은 일단 다른 프로세스를 위해 많은 메모리를 남겨둘 수 있다. 그리고 파일 시스템 버퍼가 블록을 가지고 있을 수도 있다.
• 단점은, 파일 시스템의 버퍼 관리에는 손 쓸 수 없다는 점이다. 따라서 ,운영체제가 최적의 결정을 하지 않더라고 간섭할 수 없다.

---

# Chap 14. Indexing

---

14.1 인덱스를 사용하면 쿼리 처리 속도가 훨씬 빠른데 왜 모든 속성에 대해서 인덱스를 두는 것이 안좋은 아이디어인지 설명하시오

• 인덱스조차 디스크나 CPU 그리고 저장장치에 추가적인 작업을 요구하기 때문에 작으면 작을수록 좋다.
• 기본키가 아닌 속성에 대해 인덱스를 두는 것은 자주 일어날 갱신때문에 번거롭다
• 여러 검색 키에 대한 쿼리인 경우 일부 키에 대한 인덱스가 있어도 효율이 좋다. 오히려 너무 많은 인덱스가 있는 것이 퍼포먼스 증가에는 도움이 안될 수 있다.

14.2 서로 다른 검색 키에 대해서 같은 릴레이션 안에서 두개의 클러스터링 인덱스를 가지는게 가능한지 설명하시오

• 일반적으로 같은 릴레이션이 두 개의 기본 키를 가지는 것은 불가능하다. 왜냐하면 릴레이션의 튜플들이 똑같은 값을 다른 방식으로 정렬하기 위해 한번 더 만들어야 하기 때문이다. 
• 어찌어찌 복사해서 만들 수는 있겠지만 매우 비효율적이다.

14.7 만약 정렬된 엔트리가 순서대로 B+Tree에 삽입된다면 각 리프노드는 점유율이 얼마나 될지 설명하시오

• 정렬된 상태라면 순서대로 노드를 채우고 다 차면 정확히 반으로 나누어지고 그 뒤로 왼쪽노드는 건들이지 않고 오른쪽 노드에서 같은 일이 일어나므로 모든 노드가 반만 차있는 상태가 된다.

14.9(a) B+Tree 파일 구조에서는 insertion이 후 리프노드의 연속성을 잃을 수 있는데 왜 그런지 설명하시오

• 처음 파일이 생성됬을 때는 디스크와 트리에서 모두 인접하게 할당할 있을 수 있다. 하지만, 삽입이나 삭제의 과정이 일어나면 연속성을 잃을 수 있고, 연속적인 접근을 위해서는 오래 기다려야 할 수 있다.

14.9(b)