데이터베이스 인터널스

Database Internals를 읽고 주요 내용을 요약 정리합니다.

데이터베이스 비교

데이터베이스 시스템 선택은 장기적인 결과를 초래할 수 있다. 마이그레이션 작업은 쉬운 것이 아니기 때문에 개발  초기 단계에 성능, 일관성 문제 운영 문제 등 여러 요소를 고려해야 한다. 최악의 경우 애플리케이션의 많은 부분을 수정해야 한다.

 

데이터베이스를 비교하기 전에 목표를 명확하게 세우자. 성능과 확장성에 관련된 문제는 시간이 지나거나 사용량이 증가했을 때 나타난다. 운영 환경과 최대한 유사한 환경에서 오랫동안 테스트하는 것이 가장 좋다.

 

데이터베이스 선택은 장기적인 결정이라 최신 버전에 정확히 무엇이 변경됐고 왜 변경됐는지 파악하고 업그레이드 전략을 세워 두는 것이 좋다. 데이터베이스 개발업체가 지금까지 어떤 방식으로 업그레이드를 해왔는지 확인하면 앞으로의 업그레이드 방향을 미리 예측할 수 있다. 문제가 많았다면 앞으로도 문제가 발생할 수 있다는 의미다.

 

1장 소개 및 개요

OLTP: 대량의 사용자 요청과 트랜잭션을 처리. 처리는 미리 정의돼 있고 짧음.

OLAP: 복잡한 집계 작업을 처리. 분석과  DW에 주로 사용. 많은 시간이 소요되는 복잡한 임의의 쿼리에 적합

HTAP: OTLP + OLAP 데이터베이스의 특성을 합친 DB

key-value store, RDMBS, document DB, graph DB 등이 있음

DBMS 구조

스토리지 엔진의 컴포넌트

tx manager: tx 스케줄링, DB 상태 일관성 보장

lock manager: DB 객체에 대한 잠금 제어. 물리적 무결성 제어

access method: 힙 파일, B-tree, LSM 트리 등 디스크에 저장된 데이터에 대한 접근 및 저장 방식 정의

buffer manager: 데이터 페이지를 메모리에 캐시

recovery manager: 로그를 유지 관리하고 장애 발생 시 시스템 복구

인 메모리 DBMS vs 디스트 기반 DBMS

성능과 상대적으로 낮은 데이터 접근 비용, 휘발성

인 메모리 데이터베이스의 지속성

모든 작업은 로그 파일에 작업 내용을 순차적으로 기록: WAL

디스크 기반 DBMS는 디스크 접근에 특화된 특수한 자료 구조 사용. 메모리는 포인터를 사용해 비교적으로 빠르게 참조할 수 있고 랜덤 메모리 접근 속도는 랜덤 디스크 접근보다 월등히 빠르다.

디스크 기반 자료 구조는 넓고 낮은 트리인 반면 인메모리 자료 구조는 다양한 형태가 존재.

디스크에서는 가변 크기의 데이터 제어가 복잡, 메모리에서는 포인터를 사용해 쉽게 제어

칼럼형 vs 로우형

로우형 DBMS는 한 개의 로우씩 접근하는 경우 적합. 한 블록에 모든 컬럼의 값이 들어감. 특정 사용자의 모든 정보를 읽을 때 효율적. 여러 사용자의 특정 필드를 읽을 때 비효율적. 요청하지 않은 필드까지 페이징하기 때문

 

컬럼형 DBMS는 로우 단위가 아닌 수직 분할해 저장. 같은 컬럼끼리 디스크에 연속해 저장. 예를 들어 주식 정보는 주식 시세만 따로 모아서 저장하는 것이 더 효율적임. 컬럼별로 다른 파일 또는 세그먼트에 저장하면 효율적으로 데이터를 컬럼 단위로 읽을 수 있음.

집계 평균 등을 계산하는 작업에 적합.

최근에 아파치 파케이, 아파치 ORC, 쿠두, 클릭하우스 등이 인기

 

루오형 DBMS와 컬럼형 DBMS의 차이점을 데이터를 저장하는 방식만으로 설명하기에는 부족한 부분이 있음. 데이터 레이아웃은 컬럼형 DBMS에서 목효하고 있는 여러 최적화 단계 중 하나일 뿐이다.

같은 컬럼의 여러 값을 한 번에 읽으면 캐시 활용도와 처리 효율성이 증대. 최신 CPU는 벡터 연산을 통해 한 번의 CPU 명령어로 여러 데이터를 처리.

자료형별로 저장하며 압축률 증대.

로우형 컬럼형 선택의 기준은 액세스 패턴임.

 

와이드 컬럼 스토어: 빅테이블, HBase와 같은 와이드 컬럼 스토어는 데이터를 다차원 맵으로 표현하고 여러 칼럼을 칼럼 패밀리 단위로 저장. 칼럼 패밀리의 데이터는 로우 형식으로 저장. 키 단위 액세스 패턴에 적합.

데이터 파일과 인덱스 파일

데이터베이스 시스템은 데이터 파일과 인덱스 파일로 분리. 데이터 파일에는 데이터 레코드를 저장. 인덱스 파일에는 레코드에 대한 메타데이터를 저장.

 

데이터 파일

인덱스 구조형 테이블, 힙 구조형 테이블, 해시 구조형 테이블을 기반으로 한다.

힙파일: 레코드를 특정 순서를 따르지 않고 대체로 삽입 순서대로 저장. 따라서 새로운 페이지가 추가돼도 파일을 재구성하지 않아도 된다.

데이터 검색 시 데이터의 실제 위치를 가리키는 인덱스 필요.

해시 파일: 레코드를 각 키의 해시 값에 해당하는 버킷에 저장. 버킷 내 레코드는 삽입 순서대로 저장하거나 키 순서로 정렬하면 조회 속도를 향상시킬 수 있다.

인덱스 구조형 테이블: 인덱스에 실제 데이터 레코드를 저장

 

인덱스 파일

디스크에 저장된 데이터 레코드를 효율적으로 검색할 수 있는 자료 구조

실제 데이터 레코드의 정렬 순서와 검색 키의 정렬 순서가 같은 인덱스를 클러스터형 인덱스라고 한다.

 

기본 인덱스를 통한 간접 참조

데이터를 직접 참조하면 디스크 탐색 오버헤드 감소. 하지만 레코드 갱신 또는 위치 변경시에 포인터를 수정해야 하는 오버헤드.

기본 인덱스를 통해 간첩 참조시, 포인터 갱신 비용 감소. 하지만 레코드 위치 찾는 과정이 추가.

 

읽기 작업이 맣은 워크로드에서는 인덱스 개수가 여러 개여도 괜찮지만, 쓰기 작업이 맣은 워크로드에서는 인덱스 개수가 많으면 포인터 갱신이 문제가 될 수 있다. 

혼용 방식: 인덱스에 데이터 파일 오프셋과 기본 키를 모두 저장. 참조 시 우선 오프셋 유효 확인 후, 변경 시 기본키 인덱스를 통해 접근 후 갱신.

버퍼링과 불변셩, 순서화

버퍼링: 데이터를 디스크에 쓰기 전에 일부를 메모리에 저장할지 여부를 정의. 물론 모든 디스크 기반 자료 구조에서는 버퍼를 어느 정도 사용. 디스크와 데이터를 주고받는 가장 작은 전송 단위의 블록이므로 블록을 채워서 쓰는 것이 적합.

가변성: 파일 일부를 읽고 갱신한 뒤 똑같은 자리에 다시 쓸지에 대한 여부를 나타내는 속성.

순서화: 디스크 페이지에 데이터 레코드를 키 순서로 저장할지에 대한 여부를 정의.

2장 B-트리 개요