Transcript chapter_6

File Structure
Chapter 6. Organizing Files for Performance
전북대학교 전자정보공학부
장 재 우 교수
Contents
 Data Compression
 Reclaiming Space in Files
 Finding Things Quickly
 Keysorting
File Structures
- Chapter 6 -
-2-
E-mail : [email protected]
1. 데이터의 압축
 데이터 압축(data compression)
 화일 정보를 더 작은 공간에 저장되도록 인코딩(encoding)
 저장공간의 절약, 전송시간 단축
 (1) 고정길이 필드의 압축
 미국의 50개주 : 16비트  6비트로 50개 주 표현가능
 인코딩이나 디코딩 알고리즘이 매우 단순
 문제점
 인코딩 부분을 사람이 읽을 수 없다
 인코딩, 디코딩을 위한 시간이 소비된다
 주소화일을 처리하는 모든 S/W 가 인코딩, 디코딩 모듈 포함
File Structures
- Chapter 6 -
-3-
E-mail : [email protected]
Data Compression
 (2) 반복되는 열의 삭제: 진행–길이 인코딩 (Run-Length Encoding)
 방법 : triple 로 표현 <ff, value, count>
 예) 22 23 24 24 24 24 24 24 24 25 26 26 26 26 26 26 25 24
압축
22 23 ff 24 07 25 ff 26 06 25 24
 희소 행렬, 기기 데이터(instrument data), 텍스트를 포함하는 많은 종
류의 데이터에 적용
 특정한 양의 공간 절약을 보장하지 않음(원래 데이터보다 더 커질
수도 있음)
File Structures
- Chapter 6 -
-4-
E-mail : [email protected]
Data Compression
 (3) 가변 길이 코드의 대입: Huffman code
 화일 내에서의 출현 빈도가 문자마다 다르다는 사실에 착안
 데이터 집합에 나타나는 값의 확률을 결정
 각 값에 대한 탐색 경로가 그 값에 대한 코드를 이진트리로 구성
 빈도가 높은 문자에 적은 자리수의 코드 부여
File Structures
- Chapter 6 -
-5-
E-mail : [email protected]
Data Compression
 Huffman code (계속)
 코드 생성 예제
1.0
0
0.4
0.1
0.1
0.1
0.1
0.1
0.1
a
0.6
0.6
Encoding Occurrence
Unit
Probability
a
b
c
d
e
f
g
1
1
0
0.4
1
0
0.2
1.0
0.6
0.2
0.2
0
d
0.1
0.4
0.2
0.2
0
0.2
1
0
e
0.1
f
0.1
1
b
0.1
g
0.1
확률값에 따라 내림차순으로 정렬
File Structures
- Chapter 6 -
-6-
E-mail : [email protected]
1
c
0.1
Data Compression
 (4) 되돌릴 수 없는 압축 방식 (irreversible compression)
 디코딩시 최초의 데이터를 복원할 수 없는 압축
 래스터 이미지(raster image)의 축소
예) 400 * 400 이미지  100 * 100 이미지
 음성 압축 (speech compression)
 (5) Unix 에서의 압축
 System V UNIX
 pack과 unpack을 제공(허프만 코딩 사용)
 Window 에서의 압축
 ALZip
 확장자 (.zip)
File Structures
- Chapter 6 -
-7-
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 (1) 레코드 삭제와 저장 공간의 축약
File Structures
- Chapter 6 -
-8-
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 (2) 동적인 공간 재사용을 위한 고정 길이 레코드의 삭제
 고정길이 레코드
 삭제된 레코드 공간의 재사용 문제를 단순하게 처리가능
 여유공간을 순서적으로 재활용하는 레코드 삭제
 삭제된 레코드를 특별한 방법으로 표기
 삭제된 레코드가 차지한 공간을 알 수 있도록 하여, 레코드를 삽입할
때 그 공간을 재사용할 수 있도록 함
File Structures
- Chapter 6 -
-9-
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 연결 리스트(linked list)
 각 원소나 노드가 리스트 내에서 그것의 후속자(successor)에 대해
같은 종류의 참조를 포함하는 자료구조
 리스트의 끝 : -1을 사용
 가용 리스트(avail list) : 화일 내에 사용 가능한 공간(available space)인
삭제 레코드를 연결함
File Structures
- Chapter 6 -
- 10 -
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 스택(stack)
 모든 노드의 삽입과 삭제가 리스트의 한쪽 끝에서 발생하는 리스
트
File Structures
- Chapter 6 -
- 11 -
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 삭제 레코드의 연결과 스택 작업
 재사용 가능한 공간에 대한 빠른 접근을 위한 기준
 화일 내에 빈 슬롯이 존재하는지를 즉시 알 수 있는 방법
 만약 빈 슬롯이 존재한다면, 하나를 즉시 얻을 수 있는 방법
 사용 가능한 슬롯이 다음 슬롯을 가리키도록 링크를 배치함
 포인팅 작업(pointing) : 상대 레코드번호(RRNs) 사용
 고정길이 레코드 삭제의 구현
 레코드 삭제 기법
 삭제되는 레코드에 특별한 표기: *
 삭제된 레코드에 대한 공간의 재사용
 재사용 가능한 레코드 슬롯 RRN
File Structures
- Chapter 6 -
- 12 -
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 레코드 3 삭제
List head (first available record) => 3
0
1
2
3
Edwards... Bates...
Wills...
*-1
Edwards...
 레코드 5 삭제
4
Maters...
5
Browns...
6
Chavez
List head (first available record) => 5
0
1
2
3
Edwards... Bates...
Wills...
*-1
4
Maters...
5
*3
6
Chavez
 레코드 1 삭제
List head (first available record) => 1
0
1
2
3
Edwards...
*5
Wills...
*-1
4
Maters...
5
*3
6
Chavez
 세 개의 새로운 레코드 삽입
List head (first available record) => -1
0
1
2
3
4
5
Edwards... 1st new rec.. Wills... 3rd new rec.. Maters... 2nd new rec..
File Structures
- Chapter 6 -
6
Chavez
- 13 -
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 (3) 가변길이 레코드의 삭제
 가변길이 레코드의 가용 리스트
 VariableLengthBuffer : 레코드의 시작 부분에 각 레코드의 길이를 정의
 가용 리스트 : 링크는 바이트 오프셋을 포함
File Structures
- Chapter 6 -
- 14 -
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 레코드의 삽입과 삭제
 가용 리스트의 탐색 : 충분히 큰 레코드 슬롯을 발견할 때까지 가용
리스트를 모두 검색
File Structures
- Chapter 6 -
- 15 -
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 (4) 저장공간 단편화
 고정길이 레코드 : 레코드 끝  낭비 공간
 내부 단편화
File Structures
- Chapter 6 -
- 16 -
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 저장공간 단편화(가변길이 레코드)
File Structures
- Chapter 6 -
- 17 -
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 저장 공간 단편화(가변길이 레코드)
레코드 삭제후 더 작은 레코드 삽입
내부 단편화 발생
가용 리스트로 사용
(슬롯을 두 개로 나누어 사용되지 않은
슬롯은 가용리스트에 유지)
내부 단편화 제거
File Structures
- Chapter 6 -
- 18 -
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 저장공간 단편화(가변길이 레코드)
File Structures
- Chapter 6 -
- 19 -
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 외부 단편화(external fragmentation)
 <그림6.12>의 8바이트
 가용 리스트에 존재하나, 너무 단편화 되어서 사용될 수 없는 것
 외부 단편화 심할 경우  화일의 재구성
 저장공간의 홀(hole) 병합
 배치 전략을 채택하여 단편화가 발생되기 전에 이를 최소화
File Structures
- Chapter 6 -
- 20 -
E-mail : [email protected]
2. 파일의 재생 이용 (Reclaim) 공간
 (5) 배치 전략(placement strategies)
 최초적합 배치기법(first-fit placement strategy)
 가용 리스트는 삭제된 레코드를 앞(front)에 삽입
 충분히 큰 레코드 슬롯을 찾을 때까지 처음부터 레코드 탐색
 최적적합 배치기법(best-fit placement strategy)
 가용리스트를 크기에 따라 오름차순에 따라 순서화
 삽입할 레코드를 포함할 정도로 큰 것 중 제일 작은 슬롯을 사용
 단점 : 외부 단편화, 추가 처리 시간
 최악적합 배치기법(worst-fit placement strategy)
 가용리스트를 크기에 따라 내림차순으로 정리
 항상 가장 큰 레코드 슬롯을 반환
 장점 : 가용리스트의 첫 번째 요소만을 찾도록 단순화, 외부단편화 가
능성 줄임
File Structures
- Chapter 6 -
- 21 -
E-mail : [email protected]
3. 빠른 검색 (Finding Things)
 보조 기억장치에 대한 접근 비용이 매우 크기 때문에, 이를 최소화 할 수 있는
정렬(sort) 및 검색(search) 방법이 필요
 (1) 단순 필드와 레코드 화일에서의 조회
 RRN 이나 byte offset 을 알지 못할 때, 현재까지 키를 사용한 접근은
순차 탐색을 의미함
 요구된 키를 포함하는 레코드가 없거나 두개 이상일 경우
 Finding a better way to handle keyed access
 (2) 추측에 의한 검색 : 이진 탐색(binary search)
 1000개의 고정길이 레코드를 가지고 있고 키를 사용하여 오름차순
으로 정렬된 파일
 Jane Kelly라는 레코드를 이진 탐색으로 찾는 방법 : 최대 10번 비교
File Structures
- Chapter 6 -
- 22 -
E-mail : [email protected]
Finding Things
 이진 탐색 알고리즘 (<그림 6.13>)
int BinarySearch(FixedRecordFile &file, RecType &obj, KeyType &key)
// 키에 대한 이진 탐색
// 키가 발견되어 진다면, obj는 해당하는 레코드를 포함하고 1을 되돌려 준다.
{
int low = 0; int high = file.NumRecs() – 1;
while(low <= high)
{
int guess = (high-low)/2;
file.ReadByRRN(obj.guess);
if(obj.Key() == key) return 1; // 레코드를 찾은 경우
if(obj.Key() < key) high = guess –1; // guess 앞부분을 검색
else low = guess + 1; // guess 뒷부분을 검색
}
return 0;
// 키를 발견하지 못하고 루프를 끝나는 경우
}
File Structures
- Chapter 6 -
- 23 -
E-mail : [email protected]
Finding Things
 (3) 이진 탐색(binary search) 대 순차 탐색(sequential search)
 이진 탐색 (n개의 레코드)
 최대 log n  + 1 번 비교
2
 평균 log n  + 1 /2번 비교
2
 O(log n)의 복잡도
2
 순차 탐색일 경우 : 최대 n번 비교, 평균 n/2 번 비교
 O(n)의 복잡도
 2000개의 레코드로 이루어진 화일에서 Jane Kelly 레코드 찾기
 이진 탐색 : 최대 1 + log22000 = 11 비교
 순차 탐색 : 평균 1/2n = 1000 비교
 이진탐색에서 고려해야 할 비용
 키에 대해서 정렬되어 있어야 가능
 정렬은 화일 처리에서 매우 중요
File Structures
- Chapter 6 -
- 24 -
E-mail : [email protected]
Finding Things
 (4) 메모리에서의 디스크 화일 정렬
 내부 정렬(internal sorting) : 디스크에서 메모리로 전체 화일을 읽어
메모리 내에서 정렬
 탐색과 디스크 내에서의 많은 이동에 대한 비용을 줄임
 메모리 공간이 충분할 때 가능한 해결책
File Structures
- Chapter 6 -
- 25 -
E-mail : [email protected]
Finding Things
 (5) 이진 탐색과 내부 정렬의 제약
 문제점1 : 이진 탐색은 1번 또는 2번 이상의 접근을 필요로 한다.
 순차 접근에 비해서는 좋은 성능이지만, 키에 의한 반복된 접근이 많
다면 탐색을 위한 비용이 큼 (예, 1000 개의 레코드 : 9.5회의 접근)
 RRN 에 의한 검색 : 1회의 접근으로 해결
 RRN 검색 성능 가지면서 키에 의한 접근의 장점 유지  인덱스 구조
 문제점 2 : 화일을 정렬하여 유지하는 것은 매우 비싸다
 레코드 삽입시 : 평균적으로 레코드들의 절반 Read, 기존 레코드의 이
동 요구
 더 좋은 해결책 : 새로운 레코드를 삽입할 때 화일 내 레코드를 재순서
화하지 않고, 보다 효율적으로 화일을 재순서화 하는 화일 구조 필요
 문제점3 : 내부 정렬은 단지 작은 화일에서만 적용
 화일이 너무 클 경우 : 외부 정렬 방법을 이용
 키 정렬(key sort) : 내부 정렬의 응용
File Structures
- Chapter 6 -
- 26 -
E-mail : [email protected]
4. 키정렬 (Keysorting)
 키정렬
 메모리에서는 화일로부터 키만을 읽어 이를 정렬하고, 이 키에 대한 새로
운 순서에 따라 화일 내 레코드를 재정리 (tag sort 라고도 함)
 (1) 방법 설명
 가정 : 고정길이 레코드 화일, 헤더 레코드에 전체 레코드 유지
 사용되는 class : <그림6.15> - next slide
 알고리즘
① 디스크에서 키 RRN 쌍을 읽어 keyRRN 객체의 배열(KEYNODES[])에 저
장  결과 : <그림6.16>
② 메모리상에서 KEYNODES[] 를 정렬한다.  결과 : <그림6.17>
③ KEYNODES[] 의 배열 순서대로 입력화일의 레코드를 읽어서 새로운
화일에 기록한다
 <그림6.18> 키 정렬을 위한 알고리즘
File Structures
- Chapter 6 -
- 27 -
E-mail : [email protected]
4. 키정렬 (Keysorting)
class FixedRecordFile
{ public :
int NumRecs();
int ReadByRRN(RecType & record, int RRN);
// 키정렬을 위해 필요한 추가적인 메소드
int Create(char *filename);
int Append(RecType &record);
};
class KeyRRN
// (KEY, RRN)의 쌍을 포함한다
{ public :
KeyType KEY; int RRN;
KeyRRN();
KeyRRN(KeyType key, int rrn);
};
int Sort(KeyRRN [], int numKeys);
// 키에 의해 배열을 정렬한다
<그림6.15> 키정렬 알고리즘에 의해 사용되는 클래스를 위해 요구되는
최소한의 기능
File Structures
- Chapter 6 -
- 28 -
E-mail : [email protected]
4. 키정렬 (Keysorting)
File Structures
- Chapter 6 -
- 29 -
E-mail : [email protected]
4. 키정렬 (Keysorting)
File Structures
- Chapter 6 -
- 30 -
E-mail : [email protected]
4. 키정렬 (Keysorting)



int KeySort(FixedRecordFile & inFile, char * outFileName)
{
RecType obj;
KeyRRN * KEYNODEs = new KeyRRN[inFile.NumRecs()];
// 화일을 읽어서 키를 적재
for(int i=0; i<inFile.NumRecs(); i++)
{
inFile.ReadByRRN(obj, i);
// 레코드 I를 읽는다
KEYNODES[i] = KeyRRN(obj.Key(), i);
// 키와 RRN을 키 배열에 넣는다
}
Sort(KEYNODES, inFile.NumRecs());
// 키 배열을 정렬한다
FixedRecordFile outFile;
// 정렬된 키순서로 레코드를 지니게 될 화일
outFile.Create(outFileName); // 새로운 화일을 생성한다
// 정렬된 키 순서로 새로운 화일에 기록한다
for(int j=0; j<inFile.NumRecs(); j++)
{
inFile.ReadByRRN(obj, KEYNODES[j].RRN); // 키 순서로 읽기
outFile.Append(obj);
// 키순서로 기록
}
return 1;
}
<그림6.18> 키정렬을 위한 알고리즘
File Structures
- Chapter 6 -
- 31 -
E-mail : [email protected]
4. 키정렬 (Keysorting)
 (2) 키정렬의 제한
 새로운 정렬화일에 기록하기 위해서는 두 번 레코드를 읽어야 한다. ( 알고
리즘의  )
 알고리즘  의 수행시, 입력화일에 대한 임의 탐색(random seek)이 필요한
데 이는 순차탐색(sequential seek)에 비해 많은 시간이 필요
 출력화일에는 순차적으로 레코드가 출력되지만, 입력화일과 출력화일을
번갈아 탐색하기 때문에 순차적 탐색의 성능을 기대할 수 없음
 (3) 그 밖의 해결책
 키정렬
 전체 레코드를 가지고 작업할 필요가 없음
 새로이 정렬된 순서를 반영하도록 화일 내 레코드를 모두 재정리 해야 함
 인덱스 화일 : <그림6.19>
 원본 화일과의 결합에 사용되는 두 번째 종류의 화일(a second kind of file)
 탐색 : 인덱스 화일에서 이진 탐색을 수행하고, 인덱스 화일 레코드에 있는 RRN
을 사용
File Structures
- Chapter 6 -
- 32 -
E-mail : [email protected]
4. 키정렬 (Keysorting)
File Structures
- Chapter 6 -
- 33 -
E-mail : [email protected]
HomeWork #3
 키 정렬(KeySorting)을 사용하여 Student ID 로 정렬되어 있는 파일(input.txt) 을, 학생 이름
(Name)순으로 정렬하여 새로운 파일 (output.txt)을 생성하는 프로그램을 작성하라.
레코드의 구성 (고정길이)
참조
 Student ID : 2
 구성 클래스 및 멤버들
 Name : 15
Figure 6.15
 Address : 30
 Keysort Algorithm
 Department : 15
Figure 6.18
Keysort
[ Name ]
output.txt
input.txt
02 John Heerstr 22
05 Bate Que Delicia
12 Berin Glund Berg
:
05
12
02
:
Compter Eng
Civil Eng
Electronic Eng
Bate Que Delicia Civil Eng
Berin Glund Berg Electronic Eng
John Heerstr 22
Computer Eng
 input.txt 화일은 [ http://dblab.chonbuk.ac.kr] 에서 다운로드
 제출 : [email protected]
File Structures
- Chapter 6 -
- 34 -
E-mail : [email protected]