Indexing and Hashing

1. Indexing and Hashing Data Warehousing Lab. M.S. 2 HyunSuk Jung 2003.8.12

2. 순서 • Indexing • Hashing • Apache Xindice • Plan

3. Index를 사용하는 이유 • 대부분의 query들은 파일 안에 레코드들의 일 부분만을 참조한다. 이러한 레코드들을 찾는 overhead를 줄이기 위해, 파일에 대해서 index를 사용한다. • Index-sequential 파일은 가장 오래된 index 기법이다. Search-key 순서대로 레코드를 빠르게 검색하기 위해 레코드들이 순차적으로 저장된다. 빠른 랜덤한 접근을 위해 index 구조를 사용한다.

4. Index-sequential file

5. Index의 2가지 유형(1/2) • Dense index : 모든 search-key 값 포함.

6. Index의 2가지 유형(2/2) • Sparse index : 일부의 search-key 값 포함.

7. Primary index와 secondary index • Search key의 정렬 순서와 relation의 정렬순서가 일치한다면, 그때의 search-key 상의 index를 primary index라고 한다. • 그 외의 다른 index를 secondary index라고 한다. Primary key외의 다른 search key를 사용하는 query의 수행을 향상시킨다. 그러다 데이터베이스의 수정 시 overhead가 크다.

8. B+-tree index • Index-sequential 파일의 가장 큰 단점은 파일이 커질수록 수행이 감소된다는 것이다. 이것을 극복하고자, B+-tree index를 사용한다. • Balanced tree 형태: tree의 root로부터 leaf까지의 모든 경로가 같은 길이이다. • B+-tree가 AVL tree같은 balanced binary-tree 구조보다 훨씬 더 짧다. 그래서 레코드를 가져오기 위한 disk access가 더 적다.

9. B+-tree의 정의 • Root node는 차수가 m인 경우, 0, 2, 또는 m/2 이상의 sub tree를 갖는다. • 루트와 leaf node를 제외한 모든 node는 m/2 이상의 sub tree를 갖는다. • 모든 leaf node는 동일한 레벨에 있다. • leaf가 아닌 node의 키 수는 sub tree 수보다 적다. • Leaf node는 파일의 순차세트로서 모두 리스트로 연결되어 있다.

10. 19 29 5 5 11 11 19 11 11 17 17 5 7 2 2 3 3 19 23 29 31 5 7 9 19 29 31 B+-tree 예제 • Key 값이 다음과 같을 때 B+-tree를 만들어라. (2, 3, 5, 7, 11, 17, 19, 23, 29, 31) note: 한 node 안에 포인터의 수는 4개이다. - Root node Index set Nonleaf node Insert 9 9 - Leaf node Sequence set

11. B+-tree index의 특징 • B+-tree는 leaf node를 찾기 위하여 경로를 제공하는 index set과 tree의 내부 node를 포함하여 모든 node를 순차적으로 leaf node에 열거해 놓은 sequence set으로 구성. • Index set은 leaf node에 접근하기 위한 경로로만 사용하기 때문에 인덱스 부분에 속하는 node의 search-key 값이 leaf node의 sequence set에 다시 나타난다. • Sequence set의 leaf node는 순차적으로 연결된다. • 따라서 B+-tree는 파일의 한 node에 해당하는 레코드를 직접 및 순차적으로 접근하는 인덱스 파일 구성에 널리 사용.

12. B-tree • B+-tree와 유사 • B-tree의 장점: search-key값의 중복되는 공간을 제거. • B-tree의 단점은 전체적으로 복잡한 점이다. 그래서 시스템 디자이너들은 거의 B+-tree를 더 좋아한다.

13. B-tree 예제 • (2, 3, 5, 7, 11, 17, 19, 23, 29, 31) 7 bucket 23 bucket 2 bucket 3 bucket 5 bucket 11 bucket 17 bucket 19 bucket 29 bucket 31 bucket

14. Hashing • 순차적인 파일 구성은 데이터를 가져오기 위해 index 구조를 필요로 한다. 반대로 hashing을 기반으로 한 파일 구성은 찾고자 하는 record의 search key 값을 함수에 넣어 직접 데이터의 주소를 찾도록 한다. • 좋은 hash function은 search key 값이 bucket에 골고루 분배되도록 할당하는 것이다.

15. Static hashing • Bucket의 수가 고정되어 있는 hash 함수를 사용한다. 그런 hash function은 쉽게 특정부분이 커지는 것을 허용할 수 없다. • 이를 수정하기 위해 여러 동적 hashing 기술이 있다. 그 중 한 예가 extendable hashing이다. 데이터 크기에 따라 bucket이 쪼개지고 모아지면서 데이터베이스 크기를 조절한다.

16. 2 2 3 2 3 3 5 7 2 17 29 11 23 31 19 000 001 010 011 100 101 110 111 Hashing 예제 • search-key 값이 다음과 같은 레코드를 포함하는 파일을 extendable hashing을 이용해서 이 파일에 대한 extendable hash 구조를 보여라. 2, 3, 5, 7, 11, 17, 19, 23, 29, 31 h(x) = x mod 8이며, bucket은 3개의 레코드를 가질 수 있다.

17. ToXin • 대부분의 인덱스 기법이 단지 제한된 query의 클래스만을 지원하는 query processing 단계를 지원할 수 있었다. 이러한 한계를 극복하기 위해서 Toxin을 개발했다. • Toxin은 모든 query processing단계에서 데이터베이스의 총체적인 path구조를 완전히 활용하는 XML data에 대한 인덱싱 기법이다. Toxin은 두 가지 타입의 구조를 구성한다.

18. Toxin • ToXin의 두가지 구성요소 • VT: value table • IT: instance table • x/publications/issue/y 뿐만 아니라 x/issue/y에 매치하는 경로도 찾을 수 있다. • Forward, backward검색 가능

19. Apache Xindice • Xindice는 B-tree기반. • XPath Query Engine: 문서 집합을 XPath로 쿼리하기 위해서 사용함. • XML Indexing: 많은 문서에 대해서 쿼리의 수행을 향상 시키기 위해서 element와 attribute 값을 인덱스로 정의할 수 있다. • XML:DB XUpdate Implementation: 데이터베이스에 XML을 저장할 때 전체 문서를 검색할 필요없이 그 데이터만 변화시키길 원할 때가 있을 것이다. XUpdate는 데이터의 서버 측면 업데이트를 원할 때 사용하는 기법이다. • Java XML:DB API Implementation: 자바 프로그래머를 위해서 Xindice는 XML:DB API를 공급한다. • XML Objects: XML Objects는 서버에 여분의 기능을 추가하여 서버 확장 기법을 제공한다. 그리고 데이터베이스 엔진안에서 복잡한 연산을 실행할 수 있거나 서버에 현재 존재하지 않는 기능을 추가할 수 있다. • Command Line Management Tools: 관리자를 돕기 위해 Xindice는 command line 조종 관리 툴을 제공한다. XML:DB API를 통해서 할 수 있는 모든 것은 command line을 통해 할 수 있다.

20. Plan • Xindice는 XPath와 Xupdate를 지원하는데 XQuery를 지원할 수 있도록 한다. • XQuery를 지원하는 새로운 index기법을 연구, 구현한다. • Xindice를 기반으로 해서 제안한 방법을 실험한다.

21. Xindice • Data storage • (key, value)

22. 포함질의 • 간접포함질의: 엘리먼트들, 애트리뷰트들, 그리고 그것들의 내용을 이루는 텍스트 단어들간의 포함관계가 간접 포함관계(조상-자손 관계)로만 이루어진 질의. • Ex) /companies//profile//’scanners’ • 직접포함질의: 직접 포함관계(부모-자식 관계)로 이루어진 질의. • Ex) /companies/company/profile/description/’printers’ • 완전포함질의: 완전 포함관계로만 이루어진 질의 • Ex) //symbol=‘AAPL’ • K-근접 포함질의: 텍스트 단어간의 근접도에 기반을 둔 질의 • Ex) (k=3): Distance(“printers”,”scanners”)<=3