데이터베이스 시스템의 선택은 중요합니다. 성능, 일관성 문제, 운영의 어려움과 같은 이유로 데이터베이스를 변경하게 되는 경우가 발생할 수 있습니다. 데이터베이스를 변경할 때 마이그레이션이 쉽지 않을 수도 있기 때문에 초기 설계 단계에서 애플리케이션의 특성에 알맞는 데이터베이스를 선택해야 합니다. 데이터베이스를 선택함에 있어 다음과 같은 변수를 통해서 어떤 데이터베이스를 선택할지 예측할 수 있습니다.
- 스키마와 레코드 크기
- 클라이언트 수
- 쿼리 형식과 접근 패턴
- 읽기와 쓰기 쿼리 비율
- 위 변수들의 변동폭
그리고 위의 변수들을 기준으로 다음과 같은 체크리스트에 관한 답을 내려서 선택할 수 있습니다.
- 요청된 쿼리를 수행할 수 있는가?
- 데이터를 모두 저장할 수 있는가?
- 단일 노드는 몇 건의 읽기와 쓰기 요청을 처리할 수 있는가?
- 시스템에는 몇 개의 노드가 필요한가?
- 데이터 증가 추세에 맞춰 클러스터를 확장할 수 있는가?
- 유지보수는 어떻게 할 것인가?
위의 변수들과 질문들을 통해서 애플리케이션에서 적절한 데이터베이스를 선택할 수 있을 것입니다.
DBMS 아키텍처
모든 데이터베이스가 동일한 아키텍처를 갖는 것은 아닙니다. 데이터베이스마다 다른 아키텍처를 가지고 있으며 내부 컴포넌트의 경계를 명확히 나누는 것이 어렵습니다. 그러나 몇몇 공통된 부분들을 모아서 나타낸 아키텍처는 다음과 같습니다.
DBMS는 클라이언트/서버 모델을 기반으로 합니다. 데이터베이스와 애플리케이션은 각각 서버와 클라이언트의 역할을 합니다. 위 그림에서처럼 사용자가 쿼리를 요청하면 쿼리를 쿼리 프로세서에 전달합니다. 쿼리 프로세서에서는 쿼리를 분석하고 분석된 쿼리를 쿼리 옵티마이저에 전달합니다. 쿼리 옵티마이저에서는 쿼리의 실행 계획(Execution plan)을 최적화합니다. 그리고 선택된 실행 계획을 실행 엔진에서 실행합니다.
스토리지 엔진은 그림과 같이 다양한 역할을 수행하는 컴포넌트들로 구성되어 있습니다.
- 트랜잭션 매니저 : 트랜잭션을 스케줄링하고 데이터베이스 상태의 논리적 일관성을 보장
- 락 매니저 : 트랜잭션에서 접근하는 데이터베이스 객체에 대한 잠금 제어
- 엑세스 메소드 : 디스크에 저장된 데이터에 대한 접근 및 저장 방식 정의
- 버퍼 매니저 : 데이터 페이지를 메모리에 캐시
- 리커버리 매니저 : 로그를 유지 관리하고 장애 발생 시 시스템 복구
인메모리 DBMS vs 디스크 기반 DBMS
인메모리 데이터베이스는 메모리에 데이터를 저장하고 디스크는 복구와 로그 저장 용도로 사용합니다. 반면에 디스크 기반 데이터베이스는 대부분의 데이터를 디스크에 저장하고 캐시로 메모리를 사용합니다. 인메모리 데이터베이스는 데이터 접근 성능이 디스크 기반보다 높습니다. 하지만 RAM은 휘발성이기 때문에 데이터를 영구적으로 저장할 수 없습니다. 그래서 장애 발생 시 데이터가 손실될 수 있습니다. 그래서 인메모리 데이터베이스에서는 데이터 손실을 방지하기 위해 데이터를 디스크에 백업합니다. 보통 write-ahead log(WAL)을 사용합니다.
컬럼형 DBMS vs 로우형 DBMS
데이터는 디스크에 저장하는 레이아웃 방식에 따라 컬럼형과 로우형 데이터베이스로 분류할 수 있습니다.
로우형 데이터 레이아웃
로우형 DBMS는 데이터 레코드를 로우 형식으로 저장합니다. 이러한 방식은 한 개의 로우에 접근하는 경우에 적합합니다. 디스크에 저장된 데이터는 블록 단위(디스크에 엑세스하는 최소 단위)로 접근하는데 한 블록에 모든 컬럼 값이 들어갑니다. 이러한 접근 방식은 특정 사용자의 모든 정보를 읽을 때는 효율적이지만, 여러 사용자의 하나의 필드를 읽을 때는 비효율적입니다. 왜냐하면 요청하지 않은 필드까지 페이징하기 때문입니다.
컬럼형 데이터 레이아웃
컬럼형 DBMS는 데이터를 컬럼 단위로 저장합니다. 로우형과 달리 컬럼끼리 디스크에 연속해서 저장하는 방식입니다. 컬럼형 데이터베이스는 데이터의 평균과 같은 집계 분석 작업을 수행하는데 적합합니다. 컬럼형 데이터베이스는 조인이나 필터링, 다중 로우 집계 등을 위해 튜플을 재구성하기 위해서는 컬럼 사이의 관계를 정의하는 메타데이터가 추가로 필요합니다. 그래서 각 값마다 추가적인 값이 중복되서 저장되므로 데이터 양이 증가합니다. 컬럼형 데이터베이스에서는 아래와 같이 데이터를 저장합니다.
Symbol: 1:DOW; 2:DOW; 3:S&P; 4:S&P
Date: 1:08 Aug 2018; 2:09 Aug 2018; 3:08 Aug 2018; 4:09 Aug 2018
Price: 1:24,314.65; 2:24,136.16; 3:2,414.45; 4:2,232.32와이드 컬럼 스토어
구글의 빅테이블이나 HBase는 와이드 컬럼 스토어입니다. 일반적인 컬럼형 데이터베이스와는 다른 특성을 갖고 있기 때문에 와이드 컬럼 스토어로 다르게 구분합니다. 와이드 컬럼 스토어는 데이터를 다차원 맵의 형태로 표현하고 여러 컬럼을 컬럼 패밀리 단위로 저장합니다. 컬럼 패밀리의 데이터는 로우 형식으로 저장합니다. 이러한 방식은 키 단위 엑세스 패턴에 적합합니다.
데이터 파일과 인덱스 파일
데이터베이스는 여러 필드로 구성된 레코드를 테이블 형식으로 저장하는데 일반적으로 각 테이블은 별도의 파일에 저장합니다. 그리고 테이블의 각 레코드는 검색 키로 찾을 수 있습니다. 주로 이러한 레코드의 위치를 찾는데 인덱스를 사용합니다. 데이터베이스 시스템은 데이터 파일과 인덱스 파일을 분리합니다. 데이터 파일에는 데이터의 레코드가 저장되며 인덱스 파일에는 레코드에 대한 메타데이터를 저장하고 이를 통해 데이터 파일에서 레코드를 찾습니다.
데이터 파일
데이터 파일은 Heap-organized table, Hash-organized table, Index-organized table와 같은 종류가 있습니다.
- Heap-organized table : 레코드를 삽입 순서대로 저장하고 데이터 검색 시 데이터 실제 위치를 가리키는 인덱스를 필요로 합니다.
- Hash-organized table : 레코드를 각 키의 해시 값에 해당하는 버킷에 저장합니다. 버킷 내 레코드는 삽입 순서대로 저장하거나 키 순서로 정렬하면 조회 속도를 향상시킬 수 있습니다.
- Index-organized table : 인덱스에 데이터 레코드를 저장합니다. 데이터는 키 순서로 정렬됩니다.
인덱스 파일
인덱스틑 디스크에 저장된 데이터 레코드를 효율적으로 검색할 수 있는 자료 구조입니다. 인덱스 파일은 데이터 레코드를 식별할 수 있는 키나 기본 키를 데이터 파일의 해당 레코드 위치에 매핑하는 특별한 구조로 구성되어 있습니다.
프라이머리 인덱스는 기본 키나 기본키 역할을 할 수 있는 여러 키의 조합에 대한 인덱스입니다. 다른 인덱스는 모두 세컨더리 인덱스입니다.
데이터베이스에서 데이터 레코드를 직접 참조할지 프라이머리 키 인덱스를 통해 접근할 지 의견이 갈립니다. 각각의 방식은 장단점이 존재합니다. 데이터를 직접 참조하면 디스크 탐색 오버헤드가 줄지만 레코드를 갱신하거나 위치를 변경할 때 포인터를 수정해야 합니다. 반면 프라이머리 인덱스를 통해 간접 참조하면 포인트 갱신 비용은 줄어들지만 레코드 위치를 찾는 과정이 추가됩니다.
버퍼링(Buffering), 불변성(Immutability), 순서(Ordering)
데이터베이스 자료 구조에 고려해야 할 대표적인 속성 3가지가 있습니다. 이 3가지 특정을 조합하여 데이터베이스에 가진 특징에 맞도록 사용하거나 사용하지 않는 방식으로 자료 구조를 설계할 수 있습니다. 각 속성의 특징은 다음과 같습니다.
- 버퍼링
- 데이터를 디스크에 쓰기전 일부를 메모리에 저장할지 여부를 정의
- 불변성
- 파일 일부를 읽고 갱신한 뒤 똑같은 자리에 다시 쓸지에 대한 여부
- 순서
- 디스크 페이지에 데이터 레코드를 키 순서로 저장할지에 대한 것
정리
이번 포스트에서는 DBMS의 아키텍처와 주요 컴포넌트에 관해 살펴보았습니다. 인메모리 기반과 디스크 기반의 DBMS의 차이에 대해 알아보았고, 컬럼형과 로우형 데이터베이스에 차이도 알아보았습니다. 그리고 데이터베이스에서 데이터를 저장하는 방식에 대해 알아보았습니다. 그리고 마지막에 데이터베이스 자료 구조의 중요한 3가지 속성인 버퍼링, 불변성, 순서에 관해 살펴보았습니다. 이번 포스트를 통해서 데이터베이스의 기본 개념에 대해 청사진을 그릴 수 있었을 것이라고 생각합니다.