1 / 34

Chapter 6. Organizing Files for Performance

전북대학교 전자정보공학부 장 재 우 교수. Chapter 6. Organizing Files for Performance. Contents. Data Compression Reclaiming Space in Files Finding Things Quickly Keysorting. 1. 데이터의 압축. 데이터 압축 (data compression) 화일 정보를 더 작은 공간에 저장되도록 인코딩 (encoding) 저장공간의 절약 , 전송시간 단축 (1) 고정길이 필드의 압축

cwen
Download Presentation

Chapter 6. Organizing Files for Performance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 전북대학교 전자정보공학부 장 재 우 교수 Chapter 6. Organizing Files for Performance

  2. Contents • Data Compression • Reclaiming Space in Files • Finding Things Quickly • Keysorting E-mail : jwchang@chonbuk.ac.kr

  3. 1. 데이터의 압축 • 데이터 압축(data compression) • 화일 정보를 더 작은 공간에 저장되도록 인코딩(encoding) • 저장공간의 절약, 전송시간 단축 • (1)고정길이 필드의 압축 • 미국의 50개주 : 16비트  6비트로 50개 주 표현가능 • 인코딩이나 디코딩 알고리즘이 매우 단순 • 문제점 • 인코딩 부분을 사람이 읽을 수 없다 • 인코딩, 디코딩을 위한 시간이 소비된다 • 주소화일을 처리하는 모든 S/W 가 인코딩, 디코딩 모듈 포함 E-mail : jwchang@chonbuk.ac.kr

  4. 압축 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

  5. Data Compression • (3) 가변 길이 코드의 대입: Huffman code • 화일 내에서의 출현 빈도가 문자마다 다르다는 사실에 착안 • 데이터 집합에 나타나는 값의 확률을 결정 • 각 값에 대한 탐색 경로가 그 값에 대한 코드를 이진트리로 구성 • 빈도가 높은 문자에 적은 자리수의 코드 부여 E-mail : jwchang@chonbuk.ac.kr

  6. 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

  7. 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

  8. 2. 파일의 재생 이용 (Reclaim) 공간 • (1) 레코드 삭제와 저장 공간의 축약 E-mail : jwchang@chonbuk.ac.kr

  9. 2. 파일의 재생 이용 (Reclaim) 공간 • (2) 동적인 공간 재사용을 위한 고정 길이 레코드의 삭제 • 고정길이 레코드 • 삭제된 레코드 공간의 재사용 문제를 단순하게 처리가능 • 여유공간을 순서적으로 재활용하는 레코드 삭제 • 삭제된 레코드를 특별한 방법으로 표기 • 삭제된 레코드가 차지한 공간을 알 수 있도록 하여, 레코드를 삽입할 때 그 공간을 재사용할 수 있도록 함 E-mail : jwchang@chonbuk.ac.kr

  10. 2. 파일의 재생 이용 (Reclaim) 공간 • 연결 리스트(linked list) • 각 원소나 노드가 리스트 내에서 그것의 후속자(successor)에 대해 같은 종류의 참조를 포함하는 자료구조 • 리스트의 끝 : -1을 사용 • 가용 리스트(avail list) : 화일 내에 사용 가능한 공간(available space)인 삭제 레코드를 연결함 E-mail : jwchang@chonbuk.ac.kr

  11. 2. 파일의 재생 이용 (Reclaim) 공간 • 스택(stack) • 모든 노드의 삽입과 삭제가 리스트의 한쪽 끝에서 발생하는 리스트 E-mail : jwchang@chonbuk.ac.kr

  12. 2. 파일의 재생 이용 (Reclaim) 공간 • 삭제 레코드의 연결과 스택 작업 • 재사용 가능한 공간에 대한 빠른 접근을 위한 기준 • 화일 내에 빈 슬롯이 존재하는지를 즉시 알 수 있는 방법 • 만약 빈 슬롯이 존재한다면, 하나를 즉시 얻을 수 있는 방법 • 사용 가능한 슬롯이 다음 슬롯을 가리키도록 링크를 배치함 • 포인팅 작업(pointing) : 상대 레코드번호(RRNs) 사용 • 고정길이 레코드 삭제의 구현 • 레코드 삭제 기법 • 삭제되는 레코드에 특별한 표기: * • 삭제된 레코드에 대한 공간의 재사용 • 재사용 가능한 레코드 슬롯 RRN E-mail : jwchang@chonbuk.ac.kr

  13. 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

  14. 2. 파일의 재생 이용 (Reclaim) 공간 • (3) 가변길이 레코드의 삭제 • 가변길이 레코드의 가용 리스트 • VariableLengthBuffer : 레코드의 시작 부분에 각 레코드의 길이를 정의 • 가용 리스트 : 링크는 바이트 오프셋을 포함 E-mail : jwchang@chonbuk.ac.kr

  15. 2. 파일의 재생 이용 (Reclaim) 공간 • 레코드의 삽입과 삭제 • 가용 리스트의 탐색 : 충분히 큰 레코드 슬롯을 발견할 때까지 가용 리스트를 모두 검색 E-mail : jwchang@chonbuk.ac.kr

  16. 2. 파일의 재생 이용 (Reclaim) 공간 • (4) 저장공간 단편화 • 고정길이 레코드 : 레코드 끝  낭비 공간 • 내부 단편화 E-mail : jwchang@chonbuk.ac.kr

  17. 2. 파일의 재생 이용 (Reclaim) 공간 • 저장공간 단편화(가변길이 레코드) E-mail : jwchang@chonbuk.ac.kr

  18. 2. 파일의 재생 이용 (Reclaim) 공간 • 저장 공간 단편화(가변길이 레코드) 레코드 삭제후 더 작은 레코드 삽입 내부 단편화 발생 (슬롯을 두 개로 나누어 사용되지 않은 슬롯은 가용리스트에 유지) 가용 리스트로 사용 내부 단편화 제거 E-mail : jwchang@chonbuk.ac.kr

  19. 2. 파일의 재생 이용 (Reclaim) 공간 • 저장공간 단편화(가변길이 레코드) E-mail : jwchang@chonbuk.ac.kr

  20. 2. 파일의 재생 이용 (Reclaim) 공간 • 외부 단편화(external fragmentation) • <그림6.12>의 8바이트 • 가용 리스트에 존재하나, 너무 단편화 되어서 사용될 수 없는 것 • 외부 단편화 심할 경우  화일의 재구성 • 저장공간의 홀(hole) 병합 • 배치 전략을 채택하여 단편화가 발생되기 전에 이를 최소화 E-mail : jwchang@chonbuk.ac.kr

  21. 2. 파일의 재생 이용 (Reclaim) 공간 • (5) 배치 전략(placement strategies) • 최초적합 배치기법(first-fit placement strategy) • 가용 리스트는 삭제된 레코드를 앞(front)에 삽입 • 충분히 큰 레코드 슬롯을 찾을 때까지 처음부터 레코드 탐색 • 최적적합 배치기법(best-fit placement strategy) • 가용리스트를 크기에 따라 오름차순에 따라 순서화 • 삽입할 레코드를 포함할 정도로 큰 것 중 제일 작은 슬롯을 사용 • 단점 : 외부 단편화, 추가 처리 시간 • 최악적합 배치기법(worst-fit placement strategy) • 가용리스트를 크기에 따라 내림차순으로 정리 • 항상 가장 큰 레코드 슬롯을 반환 • 장점 : 가용리스트의 첫 번째 요소만을 찾도록 단순화, 외부단편화 가능성 줄임 E-mail : jwchang@chonbuk.ac.kr

  22. 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

  23. 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

  24. 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

  25. Finding Things • (4) 메모리에서의 디스크 화일 정렬 • 내부 정렬(internal sorting) : 디스크에서 메모리로 전체 화일을 읽어 메모리 내에서 정렬 • 탐색과 디스크 내에서의 많은 이동에 대한 비용을 줄임 • 메모리 공간이 충분할 때 가능한 해결책 E-mail : jwchang@chonbuk.ac.kr

  26. Finding Things • (5) 이진 탐색과 내부 정렬의 제약 • 문제점1 : 이진 탐색은 1번 또는 2번 이상의 접근을 필요로 한다. • 순차 접근에 비해서는 좋은 성능이지만, 키에 의한 반복된 접근이 많다면 탐색을 위한 비용이 큼 (예, 1000 개의 레코드 : 9.5회의 접근) • RRN 에 의한 검색 : 1회의 접근으로 해결 • RRN 검색 성능 가지면서 키에 의한 접근의 장점 유지  인덱스 구조 • 문제점 2 : 화일을 정렬하여 유지하는 것은 매우 비싸다 • 레코드 삽입시 : 평균적으로 레코드들의 절반 Read, 기존 레코드의 이동 요구 • 더 좋은 해결책 : 새로운 레코드를 삽입할 때 화일 내 레코드를 재순서화하지 않고, 보다 효율적으로 화일을 재순서화 하는 화일 구조 필요 • 문제점3 : 내부 정렬은 단지 작은 화일에서만 적용 • 화일이 너무 클 경우 : 외부 정렬 방법을 이용 • 키 정렬(key sort) : 내부 정렬의 응용 E-mail : jwchang@chonbuk.ac.kr

  27. 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

  28. 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

  29. 4. 키정렬 (Keysorting) E-mail : jwchang@chonbuk.ac.kr

  30. 4. 키정렬 (Keysorting) E-mail : jwchang@chonbuk.ac.kr

  31. 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

  32. 4. 키정렬 (Keysorting) • (2) 키정렬의 제한 • 새로운 정렬화일에 기록하기 위해서는 두 번 레코드를 읽어야 한다. ( 알고리즘의 ) • 알고리즘  의 수행시, 입력화일에 대한 임의 탐색(random seek)이 필요한데 이는 순차탐색(sequential seek)에 비해 많은 시간이 필요 • 출력화일에는 순차적으로 레코드가 출력되지만, 입력화일과 출력화일을 번갈아 탐색하기 때문에 순차적 탐색의 성능을 기대할 수 없음 • (3) 그 밖의 해결책 • 키정렬 • 전체 레코드를 가지고 작업할 필요가 없음 • 새로이 정렬된 순서를 반영하도록 화일 내 레코드를 모두 재정리 해야 함 • 인덱스 화일 : <그림6.19> • 원본 화일과의 결합에 사용되는 두 번째 종류의 화일(a second kind of file) • 탐색 : 인덱스 화일에서 이진 탐색을 수행하고, 인덱스 화일 레코드에 있는 RRN을 사용 E-mail : jwchang@chonbuk.ac.kr

  33. 4. 키정렬 (Keysorting) E-mail : jwchang@chonbuk.ac.kr

  34. 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

More Related