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