2. DBMS 분류 - 저장매체 & 레이아웃 관점

이번 글에서는 다양한 관점에서 DBMS 를 분류해보려고 한다.

DBMS 를 분류하는데는 다양한 관점이 있지만 특히 중간 스토리지와 레이아웃 관점에서 분류해보려고 한다.

(다만 DBMS가 각 관점에서 딱 잘라 분류되지는 않을 수 있다는 점을 염두해두자.)

 

이 두가지 관점 외에도 다음의 기준으로 3가지로 DBMS를 분류하는 방법도 있다.

 

1. OLTP (online transaction processing) database

대량의 사용자 요청과 트랜잭션을 처리하며, 빠르게 실행되는 사전 정의된 쿼리를 자주 사용한다.

 

보통 웹 개발할 때 사용하는 DBMS 가 속한다고 이해했다.

예를 들어 로그인 기능을 구현할 때 사용자를 조회하는 경우, 사용자 조회 쿼리는 사전에 개발자에 의해 정의되어있으며, 상대적으로 실행시간이 짧고 간단하다.

 

2. OLAP (online analytical processing) database

복잡한 집계 기능을 다루는 DBMS 이다.

보통 분석과 data warehousing 등에 사용되며, 복잡하고 실행 시간이 상대적으로 긴 애드 혹 쿼리들을 다룰 수 있다.

 

'애드 혹 쿼리' 라는 것은 쿼리가 고정되어있지 않고, 해결하려는 문제에 따라 동적으로 쿼리가 달라지는 것을 말한다.

예를 들어 쇼핑 몰에서 30대 남성이 최근 1년동안 자주 구매한 상품을 찾아보려고 할 때, 원하는 데이터를 추리기 위해 쿼리를 동적으로 생성할 것이고, 대상 소스 데이터의 크기가 매우 크다면 그만큼 쿼리 실행시간이 오래 걸릴 것이다.

 

3. HTAP (hybrid transactional and analytical processing)

OLTP와 OLAP 의 특징을 모두 갖고 있다.

 

이 밖에도 key-value 저장소, 관계형 DB, document-oriented 저장소, 그래프 DB 등 다양한 종류가 존재하지만, storage engine 과 관련하여 중요한 분류 기준만 살펴보려고 한다.

이제 저장소 종류와, 데이터를 다루는 레이아웃 관점에서 DBMS를 분류해보자.

 

저장 매체 ( 메모리 vs 디스크 )

데이터베이스는 데이터를 메모리와 디스크에 저장한다.

In-memory DBMS 는 주로 메모리에 데이터를 저장하며, 디스크에는 복구와 로깅 목적의 데이터를 저장한다.

Disk-based DBMS 는 대무문의 데이터를 디스크에 저장하며, 디스크에 저장된 내용을 캐싱하거나 데이터를 임시 저장하는 공간으로서 메모리를 활용한다.

즉, 두 종류의 DBMS 모두 메모리와 디스크를 활용한다.

 

인 메모리 DBMS 는 데이터 저장 공간의 종류 뿐만 아니라, 데이터의 저장 구조, 사용하는 최적화 기법도 디스크 기반 DBMS와 다르다.

또한 메모리에 접근하는 것은 디스크에 접근하는 것보다 속도가 빠르기 때문에 인 메모리 DBMS는 낮은 접근 비용, 세분화된 엑세스, 높은 성능을 장점으로 가지고 있다.

 

메모리에 저장된 데이터를 다루는 것은 디스크에 저장된 데이터를 다루는 것보다 프로그래밍하기 쉽다.

운영체제에서 메모리 관리 기능을 추상화하여 제공해주기 때문에 단순히 메모리 청크를 할당받고 해제하는 관점으로 메모리를 다룰 수 있기 때문이다. 반면 디스크에 저장된 데이터를 다룰 때는 이런 기능을 제공받지 못하기 때문에 데이터 참조, 직렬화 포맷, 메모리 해제, fragmentation 관리 등을 직접 해야한다.

 

하지만 인 메모리 DBMS 는 높은 비용과 데이터의 휘발성(lack of durability)이라는 단점을 갖고 있다.

RAM은 소프트웨어 오류, 충돌, 하드웨어 결함, 전원 끊김 등의 문제가 발생하면 내부 데이터가 사라진다.

이런 문제를 예방하기 위해 무정전 전원 공급 장치 또는 배터리가 있는 RAM 등을 활용하는 대안이 존재하지만, 이 경우 추가적인 하드웨어 장비가 필요하고, 이를 관리하는 추가적인 인력이 필요하게 된다.

따라서 결론적으로는 디스크 기반 DBMS가 비용 면에서도 좋고 유지보수에도 더 용이하다.

 

물론 비휘발성 메모리 (NVM, Non-Volatile Memory = HDD, SSD 등) 기술도 꾸준히 발전하고 있다.

그래서 NVM 에서도 기술에 따라 읽고 쓰기 지연시간을 줄이거나 없애고, 읽고 쓰기 성능이 개선되며, RAM처럼 바이트 기반 주소 체계를 사용할 수 있기도 하다.

 

In-memory DBMS는 안정성을 위해 디스크에 데이터를 백업해둔다.

또한 데이터를 다루는 각각의 명령어를 실행하기 '전에' 연속적인 로그 파일에 해당 결과를 기록하는 Write ahead log (WAL) 기법을 활용하여 데이터가 유실되었을 때 복구한다.

그리고 DBMS가 시작하는 중이나 충돌 후에, 이미 확실하게 반영된 로그 내용을  다시 실행하지 않도록 In-Memory DB는 백업용 복사본을 갖고 있다. 이 복사본은 디스크 기반의 정렬된 자료구조에 저장된다. 그리고 복사본 데이터를 수정할 때는 클라이언트 요청과는 독립적으로 비동기적으로 수정되며, I/O 비용을 줄이기 위해 수정 사항을 모았다가 한번에 배치로 수정한다.

그리고 DB 를 복구할 때는 이 백업본과 로그를 함께 활용한다.

 

구체적으로, 로그 기록은 데이터 일괄 백업에 활용된다.

로그 기록을 처리하는 배치 작업이 끝나면, 백업 데이터에는 특정 시점의 DB 스냅샷이 저장되고, 그 시점까지 스냅샷을 만드는데 활용된 로그 데이터는 삭제된다.

이 작업을 가리켜 checkpointing 이라고 부른다.

이를 통해 백업이 완료될 때까지 클라이언트의 접근을 막지 않으면서도 디스크에 저장하는 DB 백업본의 상태를 최신으로 유지하여 데이터 복구 시간을 줄일 수 있다.

 

참고) 인-메모리 데이터베이스나, 디스크 기반 DBMS 가 메모리에 대량의 데이터를 캐싱하는 것이나 똑같지 않냐고 생각할 수 있지만, 이 둘은 다르다. 저장하는 데이터 레이아웃이나 직렬화 형태가 다르기 때문에 이로부터 오는 오버헤드로 인해 인-메모리 데이터베이스와 동일한 수준의 최적화가 되지 않기 때문이다.

 

디스크 기반 DB는 디스크 접근에 특화된 특별한 자료구조를 사용한다.

메모리는 디스크보다 랜덤 엑세스도 빠르고, 포인터를 따라가는 것도 빠르다.

디스크는 주로 짧고 넓은 트리 기반의 자료구조를 사용하지만, 메모리 기반 DB에서는 구현시 자료구조 선택 폭이 더 넓고 디스크에서 구현할 수 없기나 힘든 최적화 기법도 사용할 수 있다.

그리고 디스크에서는 가변 크기 데이터를 다룰 때 주의가 필요하지만, 메모리에서는 포인터를 사용해 참조하므로 상관이 없다.

 

레이아웃 ( Column-Oriented vs Row-Oriented )

많은 데이터베이스는 데이터를 다룰 때 테이블의 행/열로 구성된 record의 집합으로 다룬다.

디스크에 데이터를 저장하는 방식에 따라 데이터베이스를 분류하는 기준 중에 행 기반 / 열 기반으로 나누는 방법이 있다.

즉, 테이블을 행 단위로 쪼개서 다루거나, 테이블을 열 단위로 쪼개서 다룰 수 있는 것이다.

우리에게 익숙한 관계형 DB는 보통 행 기반 DBMS이고, 열 기반 DBMS 의 예시로는 Monet DB, C-Store 등이 있다.

 

Row-Oriented Data Layout

행 기반 DBMS 는 row 또는 record 단위로 데이터를 저장한다.

이 데이터 레이아웃은 모든 레코드가 동일한 Field 집합을 갖고 있는 테이블 형식의 데이터 표현에 가깝다.

이 방식은 여러 필드로 구성된 행이 키에 의해 유일하게 식별되는 경우 적용하기 좋다.

 

행 기반 데이터 레이아웃에서 레코드를 생성, 조회할 때는 모든 필드를 한번에 생성하거나 읽는 경우가 많고, 수정할 때는 필드마다 따로 구분해서 수정할 수 있다.

또한 행 단위로 데이터에 접근하는 상황에서 이 데이터 레이아웃이 가장 유용하기 때문에, 모든 행을 한 공간에 함께 저장하면 spatial locality 를 개선할 수 있다.

 

디스크와 같은 영구 저장매체는 보통 블록 단위로 데이터를 접근하기 때문에 행 기반 데이터 레이아웃에서는 하나의 행을 구성하는 모든 컬럼의 데이터가 하나의 블록에 들어있게 된다.

따라서 행 기반 데이터 레이아웃은 전체 데이터를 조회하는 상황에서는 적합하지만, 특정 컬럼의 데이터만 모아보려는 경우에는 다른 데이터가 페이지에 함께 담겨오므로 비효율적이다. (블록 = 데이터를 디스크에 저장하는 단위, 페이지 = 디스크와 메모리 사이 데이터를 읽고 쓰는 단위)

 

 

Column-Oriented Data Layout

열 기반 DBMS 는 데이터를 컬럼 기준으로 (=수직으로) 나눠서 저장한다.

따라서 같은 열에 속한 데이터는 연속적으로 같은 파일에 저장된다.

다른 열에 속한 데이터는 다른 파일 또는 세그먼트에 저장하여 컬럼 단위 쿼리의 실행 효율을 높인다.

이렇게 하면 읽고자 하는 데이터를 하나의 패스(pass)로 바로 읽어들일 수 있으므로, row 에 속한 모든 데이터를 읽고 필요없는 컬럼 정보는 버려야하는 Row-Oriented 방식과 비교했을 때 더 효율적이다.

 

열 기반 저장소는 트렌드 찾기, 평균 구하기와 같이 데이터를 집계해서 분석하는 워크로드를 수행하기에 적합하다.

또한 논리적인 관점에서 row 를 봤을 때 특정 필드의 중요도(읽고 쓰기 집중도)가 높은 집계를 처리할 때 열 기반 저장소를 활용하면 좋다.

 

열 기반 저장소를 사용하더라도, 논리적인 관점에서는 여전히 데이터를 표 형태로 볼 수 있다.

다만 실제 저장소에 저장될 때는 열 기준으로 저장된다.

 

<이름> | <나이> | <성별>

홍길동  |     20    |    남

사임당  |     32    |    여

전우치  |     42    |    남

 

예를 들어 위와 같이 표 형태로 데이터를 생각하면, 실제 데이터를 저장할 때는

 

<이름> : 1. 홍길동 2. 사임당 3. 전우치

<나이> : 1. 20      2. 32       3. 42

<성별> : 1. 남       2. 여        3. 남

 

과 같이 저장되며, 같은 행에 속하는 데이터는 서로 가깝게 저장된다.

여러 행에 대해 집계를 내거나, 조인, 필터링 등을 수행하려는 경우에는 위 데이터를 다시 row 형태로 재구성하는 것이 좋다.

이를 위해 각각의 컬럼 속 데이터에 같은 행에 연관된 데이터임을 나타내는 명시적인 메타데이터를 두거나 (위 그림에서 각 데이터 앞에 숫자 키를 명시한 것, 다만 이때는 중복데이터가 저장되며, 저장하는 데이터의 크기가 커지는 문제가 있다.), Virtual ID 와 같은 식별자를 사용하고, offset 을 계산하여 인덱스로 연관된 데이터를 식별하는 암시적 메타데이터를 활용할 수 있다.

 

예시로는 Apache Parquet, Apache ORC, RCFile 과 같은 열 기반 파일 포맷이나 Apache Kudu, ClickHouse 와 같은 열 기반 저장소가 있다.

 

행 기반 저장소와 열 기반 저장소 사이에는 데이터가 저장되는 방식 이외에도 차이점이 존재한다.

 

한 번의 실행으로 같은 컬럼 내 여러 데이터를 읽어들이는 것은 캐시 사용률과 컴퓨팅 효율을 크게 개선한다.

예를 들어 최신 CPU 에서는 벡터화된 instruction 을 사용하여 하나의 CPU instruction 으로 여러 데이터 포인트를 처리할 수 있다.

 

또한 같은 타입을 갖는 데이터를 함께 저장하는 것은 더 높은 압축률을 가진다.

따라서 각 데이터 타입에 맞는 효과적인 압축 알고리즘을 사용할 수 있다.

 

행 기반 / 열 기반 저장소 중에 어떤 것을 사용할지 결정하려면, access pattern 을 이해해야 한다.

만약 데이터를 조회할 때 record 단위로 읽을 필요가 많고, 워크로드가 주로 point query 와 범위 스캔으로 구성되어 있다면 행 기반 접근 방법이 더 적합할 것이고, 만약 데이터 스캔이 많은 행에 걸쳐 일어나거나, 컬럼들의 부분 집합에 대해서만 집계하는 경우가 많다면 열 기반 저장소를 사용하는 것이 더 적합할 것이다.

 

Wide Column Stores

열 기반 DBMS 를 분류할 때는 BigTable, HBase 와 같은 wide column 저장소와 혼동하면 안된다.

wide column 저장소는 다차원 맵으로 데이터를 표현하고, 컬럼들은 column family 로 묶인다.

그리고 각 column family 안에서는 데이터를 행 기반으로 저장한다.

이 레이아웃은 하나 이상의 키를 사용하여 조회하는 데이터들을 저장하기에 적합하다.

 

<BigTable 의 일종인 Webtable 예시 설명>