로우기반과 컬럼기반 DB 저장 구조, 워크로드에 맞게 고르기

레코드를 함께 읽는 로우기반 저장 방식

로우기반 데이터베이스는 데이터를 레코드, 즉 행 단위로 디스크에 순차 저장한다. 한 행에 속한 모든 컬럼 값이 물리적으로 가까이 배치되며, 전통적인 RDBMS에서 널리 쓰이는 방식이다.

⤢✕

이 구조는 OLTP(Online Transaction Processing)와 트랜잭션 중심 애플리케이션에 적합하다. 사용자 정보 관리, 주문 처리, 재고 관리처럼 단일 레코드를 자주 조회하거나 삽입·수정·삭제하는 시스템이 대표적이다.

특정 레코드의 모든 필드를 읽을 때는 한 행의 데이터가 함께 저장되어 있어 효율적이다. SELECT * FROM table WHERE id = 10처럼 단일 레코드를 찾는 쿼리, 인덱스를 이용한 빠른 접근, 레코드 단위 CRUD 작업에 강점을 보인다. 정규화와 참조 무결성 제약조건을 적용하기도 쉬워 데이터 중복을 줄이고 일관성을 관리하는 데 유리하다.

반대로 분석 쿼리처럼 일부 컬럼만 필요할 때도 행 전체를 읽게 되어 불필요한 데이터가 따라온다. 대용량 테이블 전체를 스캔하는 작업에서는 성능이 낮아질 수 있다. 서로 다른 데이터 타입이 인접하는 구조도 압축에는 불리하다. 일반적으로 컬럼기반보다 압축률이 낮으며, 행 단위보다는 테이블 또는 페이지 단위 압축 기법을 사용한다.

Oracle, MySQL, PostgreSQL, SQL Server, DB2가 주요 사용 DBMS에 해당한다.

같은 속성 값을 모으는 컬럼기반 저장 방식

컬럼기반 데이터베이스는 열 단위로 데이터를 저장한다. 같은 컬럼에 속한 값들이 물리적으로 연속 배치되므로, 분석에 필요한 컬럼만 읽는 방식에 맞는다.

⤢✕

OLAP(Online Analytical Processing), 데이터 웨어하우스, 빅데이터 분석, 대량 집계와 통계 처리, BI 애플리케이션이 주된 대상이다. SELECT avg(salary) FROM employees GROUP BY department 같은 집계 쿼리는 필요한 컬럼만 읽을 수 있어 처리에 유리하다.

같은 데이터 타입이 모여 있으므로 비트맵 인코딩, 런렝스 인코딩, 딕셔너리 인코딩 같은 압축 기법을 적용하기 좋다. 높은 압축률을 기대할 수 있고, 스토리지 효율과 대량 데이터 스캔 성능도 높일 수 있다.

대신 삽입·수정·삭제처럼 레코드 단위로 변하는 작업은 부담이 커진다. 전체 행을 조회하려면 여러 컬럼에서 값을 조합해야 하며, 트랜잭션 처리와 레코드 단위 인덱싱도 상대적으로 복잡하다. 분석 목적에서는 일부 비정규화를 허용하고, 데이터 마트나 큐브 형태로 집계 데이터를 미리 계산해 저장하는 방식도 활용된다.

Vertica, Apache Cassandra (하이브리드 방식), Greenplum, Amazon Redshift, Google BigQuery, ClickHouse, Snowflake가 주요 사용 DBMS다.

쿼리 패턴이 저장 방식을 결정한다

온라인 쇼핑몰의 주문 처리는 주문마다 단일 레코드를 추가하거나 수정하는 일이 빈번하다. 이런 흐름은 로우기반 저장 방식과 잘 맞는다. 컬럼기반은 실시간 주문 처리에는 부적합하며 지연 시간이 발생할 수 있다.

판매 데이터를 분석할 때는 상황이 다르다. “지역별 월간 판매량”처럼 집계가 중심인 쿼리를 로우기반에서 수행하면 전체 테이블 스캔으로 느려질 수 있다. 컬럼기반에서는 지역, 날짜, 판매량 컬럼만 읽어 빠르게 집계할 수 있다.

혼합 워크로드에서는 실시간 트랜잭션을 로우기반 시스템에서 처리하고, ETL 과정을 거쳐 컬럼기반 분석 시스템으로 이관하는 구성이 사용된다.

저장소를 분리하거나 결합하는 운영 방식

일부 DBMS는 워크로드에 따라 로우 저장과 컬럼 저장 방식을 동적으로 선택하는 하이브리드 저장 방식을 제공한다. 인메모리 데이터베이스에서는 두 방식을 메모리 안에서 유연하게 전환할 수도 있다.

다중 저장소 아키텍처는 OLTP 워크로드를 로우기반에, OLAP 워크로드를 컬럼기반에 분리해 운영한다. 실시간 분석이 필요하면 로우기반 운영 DB와 컬럼기반 분석 DB 사이에 실시간 동기화 메커니즘을 둘 수 있다.

저장 방식은 DBMS 이름만으로 고르는 문제가 아니다. 데이터 특성, 쿼리 패턴, 트랜잭션 요구사항, 분석 성능 요구사항이 어느 쪽에 더 가까운지부터 정해야 한다.