2. 참고 자료
1. B Trees and B+ Trees. How they are useful in Databases
2. Database System Concepts, 6th Ed.
3. https://www.programiz.com/dsa/b-tree
4. Wikipedia...
3. TOC
1. 자기 디스크의 구조
2. 데이터가 디스크에 저장되는 방법
3. 인덱스
4. 멀티 레벨 인덱스
5. m-way 탐색 트리
6. B 트리
7. B 트리의 삽입
8. B+ 트리
4. 자기 디스크의 구조
A를 트랙, B를 기하학적 섹터, A와 B가 겹친 C를 디스크 섹터라 부름.
디스크 섹터는 디스크에 저장하는 최소 단위임.
0 511
10
offset
sector
D는 파일을 저장하는 단위인 블록(or 클러스터)임.
그래서 여러 개 섹터가 하나의 블록이 될 수 있음.
하지만 이 슬라이드에선 1 블록 = 1 섹터 라고 하겠음.
5. 자기 디스크의 구조
자기 디스크는
물리적으로 디스크를 회전시키고,
arm을 앞뒤로 움직여서,
특정 섹터로 헤드를 옮기고 데이터를 읽음.
-> 즉, 디스크에서 실제로 읽어야 될 블록의 개수가 DB에서 탐색 성능에 영향을 줌.
6. 데이터가 디스크에 저장되는 방법
Employee 테이블
컬럼명 데이터 크기(byte)
id 10
name 50
depth 10
section 8
addr 50
전체합 128
블록 크기는 512 byte로 가정
7. 데이터가 디스크에 저장되는 방법
id name dept
1 john ...
2 tom ...
3 anid ...
4 samil ...
5 khan ...
6 smith ...
7 ali ...
100개의 레코드
레코드 하나당 128B ->
8. 데이터가 디스크에 저장되는 방법
1 john ...
2 tom ...
3 anid ...
4 samil ...
512/128 = 4 -> 1 블록 당 4개의 레코드를 넣을 수 있음.
-> 25개의 블록에 모든 레코드를 담을 수 있음.
-> 레코드에서 원하는 값을 찾으려면 25개 블록을 읽어야 함.
9. 인덱스
1 john ...
2 tom ...
3 anid ...
4 samil ...
근데 매번 25개의 블록을 불러와야 함? 자주 불러오는 컬럼만 떼서 불러오는 블록 수를 줄이자!
name pointer
ali
anid
john
khan
samil
smith
tom
10. 인덱스
어차피 얘도 많아서 메모리에 올리기보단 디스크에 저장할 거임. 따라서
name(50) pointer(6)
ali
anid
john
khan
samil
smith
tom
블록 포인터 크기 = 6Byte라고 하면,
56 * 100 = 5600 byte
5600%512 = 11 블록 필요
그러면 만약 WHERE name = “” 을 한다면?
=> 11 + 1(실제 레코드 위치) 블록만 읽으면 됨!
11. 멀티 레벨 인덱스
이렇게 모든 레코드가 연결된 걸 dense index라고 함.
근데 만약 레코드 수가 100이 아닌 100,000 라면?
name pointer
ali
anid
john
khan
samil
smith
tom
56 * 100,000 = 5,600,000 Byte
= 10,938 Blocks !!!
블록 내 인덱스 개수 = 512 / 56 = 9개
-> 100,000 / 9 = 11,112 개의 상위 인덱스가 생김.
-> 상위 인덱스 크기는 56 * 11,112 = 622,272 Byte
-> 622,272/512 = 1,216 Blocks
즉, 탐색 시 1,216 + 9 + 1 이고, 10,938 + 1보단 작음.
name pointer
ali
name pointer
ali
anid
john
khan
samil
smith
tom
인덱스의 한 블록을
가리킴.
간단한 해결방법:
인덱스를 위한 인덱스를 두면 됨.
13. 멀티 레벨 인덱스
1. 그럼 많이 쪼갤 수록 이득이겠네요?
-> 그럴리가. 많이 쪼갤 수록 인덱스가 디스크에서 차지하는 양이 늘어남. 적당한 trade-off를 고려해야 함.
100,000 레코드에 대해서...
Dense index를 썼을 때는 10,938 블록이 필요함.
2-level index를 썼을 때는 10,938 + 1,216 = 12,154 블록이
필요함.
14. 멀티 레벨 인덱스
2. 그래서 멀티 레벨 인덱스는 어떻게 관리함? 실제 레코드가 삽입되고 삭제될 때 어쩔거임?
-> 그래서 DBMS가 알아서 관리할 수 있도록, 알고리즘화한 대표적인 예가 B-Tree
15. M-way 탐색 트리
B-Tree를 살펴보기에 앞서서, 이 트리의 기반인 m-way 탐색 트리에 대해 알아보자.
이진 탐색 트리는 2-way 탐색 트리
하나의 노드는 1개의 key와 최대 2개의 child로 이루어짐.
16. M-way 탐색 트리
20 50
10 15 30 35 60
x < 20 20 < x < 50 50 < x
최대 2개의 key, 3개의 child를 가질 수 있는 3-way 탐색 트리
30
30
=> 즉, m-way 탐색 트리는 최대 m개의 child를 가지는 탐색 트리를 말함.
탐색 방법
17. M-way 탐색 트리
그래서 노드 구조는 보통 다음과 같이 표현함.
Pointer 1 Key 1 Pointer 2 Key 2 Pointer 3 Key 3 Pointer 4
x < Key1 Key1 < x < Key2 Key3 < x
Key2 < x < Key3
M-way 탐색 트리의 탐색 시간 복잡도는
얼마일까?
18. M-way 탐색 트리
주의할 점: 한 쪽으로 치우쳐진 트리 구조라면 탐색 성능이 느림.
10
20
30
B-tree에선 이 때문에 몇 개의 제약 조건이 붙음.
19. B 트리
B-tree 에선 다음 조건을 지켜야 함.
1. 루트를 제외한 모든 노드는 최소 (m/2)의 올림 만큼의 child를 가지고 있어야 함.
ex) 3-way -> 3/2=1.5 -> 2
2. 루트는 최소 2개의 child를 가질 수 있다. (루트 이외의 노드가 존재한다면)
3. 모든 leaf 노드는 같은 레벨에 있어야 된다.
4. 모든 생성 과정은 bottom-up이다.
20. B 트리의 삽입
1. 먼저 삽입할 위치를 찾는다.
2. 노드에 삽입할 공간이 남는다면 그대로 삽입하고 끝낸다.
3. 만약 노드에 삽입할 공간이 없다면
a. 삽입할 값을 포함해서 노드의 값들을 정렬한다
b. ceiling(m/2)의 크기를 만족하도록 두 노드로 나눈 후, 가운데 키 하나를 부모 노드로
올린다.
4. 중간값을 부모로 올릴 때도 2번과 3번 과정을 반복한다.
21. B 트리의 삽입
예로 들어 10, 20, 40, 50을 m=4인 B-tree에 넣는다고 하자.
10 20 40
50
더 이상 공간이 없음.
10 20 50
40
따라서 재배치, bottom-up으로 생성함.
22. B 트리의 삽입
60, 70, 80 을 더 넣어보자.
10 20 50 60 70
40
80
23. B 트리의 삽입
60, 70, 80 을 더 넣어보자.
10 20 50 60
40 70
80
이것도 재배치
=> 왼쪽 자식 대신 오른쪽이 더 많아도 됨. 개발자 마음.
28. B 트리의 삽입
15 30
5 10 50 60 80
35
20
70
40
앞에서 설명한 멀티 레벨 인덱스와 형태가 비슷함. 그리고 규칙에 따른 삽입이 됨.
이 노드들의 크기를 블록 크기에 맞춰주고 넣을 수 있는 만큼의 key와 child 포인터를 넣으면 됨.
29. B+ 트리
15 30
5 10 50 60 80
35
20
70
40
B-트리는 각각의 key에 대해서 레코드 포인터가 있음.
30. B+ 트리
15 30
5 10 40 50 60 70 80
30 35
15 20
70
40
B+-트리는 모든 key가 leap 노드에 한번 더 있고, 여기에 레코드 포인터가 있음. 그리고 leap 노드는
이어짐.
31. B+ 트리
그래서 다음과 같이 leaf 노드와 non leaf 노드의 포인터의 역할이 다름.
그리고 삽입과 삭제 방법이 leaf에선 약간 달라짐.
k1<= x < k2 child 노드 포인터
record 포인터
32. B+ 트리
그럼 왜 B 트리 대신 B+ 트리 써요?
B 트리가 나은 점:
1. leaf에 중복 키가 없어서 노드 수가 더 적을 수 있음.
2. leaf 노드까지 내려가지 않아도 키를 바로 찾을 수 있음.
33. B+ 트리
그럼 왜 B 트리 대신 B+ 트리 써요?
B+ 트리가 나은 점:
1. B 트리보다 노드에 넣을 수 있는 키가 더 많음. 따라서 트리 깊이가 더 낮음. -> 탐색
빠름.
P1 K1 RP1 P2 K2 RP2 P3 K3 RP3 P4
B tree 키마다 레코드 포인터 필요.
P1 K1 P2 K2 P3 K3 P4 K4 P5
B+ tree
2. 삽입, 삭제, 구현이 더 쉬움.
3. B트리가 non-leaf 노드의 키 탐색이 더 빠르다고 했지만 찾는 키가 leaf에 있을 확률이 더 높아서
성능이 크게 뒤쳐지지 않음.
그래서 B+트리가 더 나음.
34. 그 외 B+ 트리의 ‘많지만 어려워서 못한 얘기들’
1. 삭제는 어떻게 해요?
a. 삽입과 비슷함. 삭제를 먼저 한 후에, ceiling(m/2)을 만족하지 않으면, 옆 노드와 merge함.
b. 이 과정을 ceiling(m/2)를 만족할 때까지 bottom-up하면 됨.
c. 루트가 삭제되면 루트 아래에서 병합된 자식 노드가 새 루트가 됨.
2. 이미 레코드가 많아요. B+ 트리에 하나하나 넣으면 오래 걸려요.
a. 빠른 벌크 로딩을 위해서 먼저 모든 key들을 정렬함.
(external sorting은 한 챕터 분량이라 넘김)
b. bottom-up으로 부모 노드를 생성함. m개씩 묶어서 상위 인덱스를 생성하고,
그 상위 인덱스 m개를 묶어서 다시 상위 인덱스를 생성함.
3. non-unique key는 어떻게 다루죠?
a. 방법은 많은데 가장 좋은 방법은 key 뒤에 구분할 id를 추가로 덧붙여서 구분하는 거임.
4. 레코드 위치를 바꾸면 관련된 모든 B+ 트리를 수정해야 하나요?
a. 그래서 보통 primary key가 아닌 인덱스들의 레코드 포인터는 primary index의 key를 가리킴.
35. 그 외 B+ 트리의 ‘많지만 어려워서 못한 얘기들’
5. 두 개 이상의 컬럼이 합쳐서 key인 경우는 어쩌죠?
a. Compare(a, b) 구현할 때와 같음. 키가 (x, y)일 때, xa 와 xb를 비교하고 ya와 yb를 비교함.
b. WHERE x < n AND y = m 이랑 WHERE x = n AND y < m 쿼리를 둘 다 쓰면 좀 골치 아픔.
36. TL;DR
1. 인덱스는 쿼리할 때, 디스크에 저장된 레코드 전체를 불러오지 않기 위해
사용한다.
2. 멀티 레벨 인덱스는 쿼리할 때, 인덱스 전체를 불러오지 않기 위해 트리 구조로
저장하는 것이다.
3. B+ 트리는 삽입과 삭제 과정을 코드로 자동화할 수 있는 멀티 레벨 인덱스다.
4. B+ 트리의 non-leaf 노드는 반드시 ceiling(m/2) 이상의 child를 가진다.
5. B+ 트리의 생성 과정은 bottom-up이다.
6. B+ 트리의 leaf 노드는 트리의 모든 키가 들어있다.
7. B+ 트리의 leaf 노드는 링크드리스트처럼 연결되어 있다.
끝
