행 기반과 열 기반 데이터베이스, 워크로드에 맞춘 선택 기준

저장 단위가 바꾸는 데이터 접근 방식

데이터베이스는 데이터를 행 단위로 배치할 수도 있고, 같은 컬럼 값을 모아 둘 수도 있다. 이 차이는 단순한 저장 형식의 차이가 아니다. 어떤 쿼리가 빠르게 처리되는지, 압축과 I/O를 어떻게 활용하는지, 어떤 워크로드에 맞는지가 함께 달라진다.

행 기반(Row-Based) 구조는 레코드 하나를 중심으로 움직이는 업무에 적합하다. 반대로 열 기반(Column-Based) 구조는 많은 데이터에서 필요한 속성만 골라 읽고 집계하는 작업에 강점을 가진다.

레코드 작업이 중심인 행 기반 저장소

행 기반 데이터베이스는 하나의 레코드에 속한 모든 필드를 물리적으로 연속해 저장한다. 사용자 정보라면 ID, 이름, 나이, 도시가 한 덩어리로 배치되는 방식이다.

⤢✕

이 구조는 전체 레코드를 읽거나 변경하는 요청에 자연스럽게 맞는다. 단일 레코드 검색과 조작을 위한 인덱싱에 효율적이며, 삽입·갱신·삭제 같은 작업도 레코드 단위로 처리하기 좋다. 그래서 OLTP(Online Transaction Processing) 환경에서 주로 선택된다.

은행 거래, 재고 관리, 주문 처리처럼 트랜잭션이 핵심인 시스템이 대표적이다. 사용자 정보나 세션 관리처럼 웹 애플리케이션에서 레코드 전체를 자주 조회하거나 갱신하는 경우에도 적합하다.

대표적인 행 기반 데이터베이스로는 InnoDB 스토리지 엔진을 사용하는 MySQL, Oracle, SQL Server, PostgreSQL이 있다.

분석 쿼리에 맞춘 열 기반 저장소

열 기반 데이터베이스는 같은 컬럼에 속하는 값을 함께 저장한다. 모든 사용자의 ID가 모여 있고, 이름·나이·도시도 각각 별도 영역에 놓이는 구조다.

⤢✕

같은 데이터 타입이 연속해 저장되므로 압축률을 높이기 쉽고, 쿼리에 필요한 컬럼만 읽을 수 있다. 대용량 데이터에서 특정 필드를 집계하거나 스캔하는 작업에 유리한 이유다. OLAP(Online Analytical Processing)와 데이터 분석 워크로드가 이 구조의 주된 대상이다.

데이터 웨어하우스, 리포팅과 대시보드 중심의 비즈니스 인텔리전스, SUM·AVG·COUNT 같은 집계 함수가 빈번한 환경이 여기에 해당한다. 시계열 이력을 분석하고 트렌드를 파악하는 작업도 열 기반 저장 방식과 잘 맞는다.

Apache Cassandra, Google BigQuery, Amazon Redshift, Vertica, ClickHouse가 대표적인 선택지다. Cassandra는 확장성이 뛰어난 분산 데이터베이스이며, BigQuery와 Redshift는 데이터 웨어하우스 용도로 쓰인다. Vertica는 엔터프라이즈급 분석 데이터베이스이고, ClickHouse는 실시간 분석에 최적화된 OLAP 데이터베이스다.

읽는 범위에 따라 갈리는 성능 특성

행 기반 구조에서는 단일 레코드 조회와 다중 레코드 삽입·갱신이 높은 성능을 보이는 반면, 전체 컬럼을 스캔하는 작업은 낮은 성능을 보일 수 있다. 열 기반 구조는 집계 연산과 특정 컬럼 스캔에서 높은 성능을 보이지만, 단일 레코드 조회에는 낮은 성능을 보일 수 있다.

⤢✕

디스크 I/O 관점에서도 차이가 드러난다. 행 기반 데이터베이스는 전체 레코드를 읽고 쓰는 작업에 효율적이다. 열 기반 데이터베이스는 필요한 컬럼만 읽을 수 있고 동일한 데이터 타입을 연속해서 저장하므로, 대용량 분석에서 압축과 읽기 효율을 활용할 수 있다.

단일 플랫폼에서 행·열 저장 방식을 함께 쓰는 경우

행 기반과 열 기반의 장점을 함께 가져가려는 하이브리드 접근법도 있다. PostgreSQL의 cstore_fdw, MySQL 호환 컬럼 스토어 엔진인 MariaDB ColumnStore, Columnstore Indexes를 제공하는 SQL Server, Hybrid Columnar Compression을 제공하는 Oracle Database가 이 범주에 속한다.

⤢✕

하이브리드 구성에서는 쿼리 옵티마이저가 작업의 특성에 맞춰 적절한 스토리지 엔진을 선택한다. 트랜잭션 처리와 분석을 모두 다뤄야 하지만 관리 플랫폼을 분리하기 어렵다면 검토할 수 있는 방식이다.

워크로드에서 출발하는 선택

선택의 출발점은 제품 이름이 아니라 실제 작업의 성격이다. OLTP와 OLAP 중 어느 쪽이 주된 워크로드인지, 단일 레코드를 다루는지 분석 집계를 반복하는지, 갱신이 잦은지 일괄 로드가 많은지 확인해야 한다. 데이터 규모와 수직적·수평적 확장 요구사항도 함께 판단 대상이다.

⤢✕

전자상거래 플랫폼에서 실시간 주문, 재고, 사용자 프로필, 주문 이력을 처리한다면 MySQL 같은 행 기반 데이터베이스가 맞는다. 트랜잭션이 주요 워크로드이고 단일 레코드 갱신이 빈번하며 일관성이 중요하기 때문이다.

대용량 로그를 저장하고 패턴 분석, 이상 탐지, 시계열 트렌드 분석, 리포트를 수행하는 시스템이라면 ClickHouse 같은 열 기반 데이터베이스를 선택할 수 있다. 특정 컬럼 기반의 집계 연산이 빈번하고, 쓰기는 일괄 처리이며 읽기가 주요 작업인 조건에 부합한다.

실시간 거래 처리와 사기 탐지, 고객 행동 분석, 규제 준수 리포팅을 함께 수행하는 금융 서비스 플랫폼은 SQL Server with Columnstore Indexes 같은 하이브리드 접근법을 고려할 수 있다. OLTP와 OLAP가 모두 중요하고, 트랜잭션과 분석을 단일 플랫폼에서 관리해야 하는 경우다.

저장 구조는 시스템의 성능, 확장성, 유지보수성에 직접 영향을 준다. 요구사항을 워크로드와 데이터 접근 패턴으로 분해한 뒤, 그 결과에 맞춰 행 기반·열 기반·하이브리드 구조를 선택하는 것이 핵심이다.