태그: Fundamentals of Database Engineering
이 태그가 붙은 글 "Fundamentals of Database Engineering".
섹션4: key column 과 non-key column
차이는 유일성이 아니라 값이 내부 페이지까지 올라가느냐다. non-key column 으로 넣으면 인덱스가 작아지는 게 아니라 트리가 한 층 얕아진다.
섹션4,5: 데이터베이스 인덱싱과 B+트리
인덱스가 디스크에서 어떻게 생겼는지, 왜 B트리가 아니라 B+트리인지. 그리고 쓰기가 쌓였을 때 PostgreSQL 과 InnoDB 의 인덱스가 서로 다르게 망가지는 이유.
열 저장은 안에서 어떻게 생겼나 — row group, 정렬 키, zone map
1개의 댓글열 저장도 행을 먼저 자른다. 그 덩어리가 읽기의 최소 단위라서, 인덱스를 걸어도 범위 조회에는 쓰이지 않는다. 열 저장의 진짜 인덱스는 정렬 키 하나뿐이다.
행 기반과 열 기반, 모니터링은 왜 열 기반인가
인덱스를 걸면 똑같지 않나 — 그 직관이 어디서 틀리는지 Postgres 와 DuckDB 로 300만 행을 돌려 확인했다. 인덱스는 탐색을 해결하지 읽는 양을 줄이지 않고, 열 저장의 이점은 대부분 값의 카디널리티에서 나온다.
섹션3 실습: 페이지 안을 직접 열어보기
pageinspect 로 라인 포인터 배열을 열어 ctid 의 두 번째 숫자가 행 번호가 아님을 확인하고, VACUUM 이 슬롯을 남기는 기준이 인덱스 하나임을 검증한다.
섹션3: 데이터베이스 내부
PostgreSQL 에는 클러스터 인덱스가 없어서 PK 인덱스조차 보조 인덱스다. 그리고 VACUUM 이 지운 데이터는 되살리는 게 아니라, 복구 목표를 그 이전으로 잡아 애초에 지워지지 않게 한다.
섹션2 실습 2: Django 에서 같은 문제 겪어보기
transaction.atomic 은 격리 수준을 바꾸지 않는다. QuerySet 캐시는 어디까지 유효한가. ORM 이 lost update 를 유도하는 지점과 F(), select_for_update 를 실제로 돌려서 확인한다.
섹션2 실습 1: ACID 직접 까보기
A·C·I·D 를 차례로 눈으로 확인한다. t_xmin / t_xmax 를 직접 찍어 보면 네 글자가 각각 어떤 장치로 만들어지는지, 그리고 C 만 왜 다른지가 드러난다.
섹션2: ACID
ACID 네 글자를 DB가 실제로 어떤 장치로 구현하는지. MySQL InnoDB의 Undo Log와 PostgreSQL의 Append-Only는 원자성과 격리성을 정반대 방식으로 만든다.