💡 핵심 인사이트
로우 기반 저장소(Row-oriented Storage)는 데이터를 하나의 레코드(행, Tuple) 단위로 묶어서 디스크에 순차적으로 기록하는 전통적인 방식입니다.
찰나의 순간에 데이터를 삽입, 수정, 삭제해야 하는 은행, 쇼핑몰 등의 OLTP(온라인 트랜잭션 처리) 환경에 절대적으로 최적화되어 있습니다.

Ⅰ. 로우 스토어(Row Store)의 데이터 블록 구조

관계형 데이터베이스(MySQL, Oracle, PostgreSQL 등)의 기본 스토리지 아키텍처입니다. 데이터베이스는 디스크에 접근할 때 1바이트씩 읽지 않고, 고정된 크기의 블록(Block) 또는 페이지(Page) 단위(보통 4KB ~ 8KB)로 덩어리째 읽고 씁니다.

로우 스토어는 이 하나의 블록 안에 특정 개체(예: 한 명의 회원)에 대한 모든 속성(이름, 나이, 연락처, 주소)을 연속된 바이트로 꽉 채워서 저장합니다.

[ 물리적 디스크 블록 (예: 8KB) ]
┌──────────────────────────────────────────────────┐
│ 블록 헤더 (메타데이터)                           │
├──────────────────────────────────────────────────┤
│ 레코드 1: [ 홍길동 | 30 | 010-111... | 서울 ]    │
│ 레코드 2: [ 김철수 | 25 | 010-222... | 부산 ]    │
│ 레코드 3: [ 이영희 | 28 | 010-333... | 대전 ]    │
│ ... 빈 공간 (여유 공간) ...                      │
└──────────────────────────────────────────────────┘

Ⅱ. 로우 스토어의 핵심 장점 (왜 트랜잭션에 강한가?)

쇼핑몰에서 고객이 결제를 진행하는 상황을 가정해 봅시다. 이때 DB에는 "주문번호, 고객명, 상품코드, 결제금액, 배송지" 정보가 담긴 **한 줄(Row)의 데이터가 동시에 삽입(INSERT)**되어야 합니다.

1. 단일 디스크 I/O로 빠른 Write 연산

새로운 레코드를 삽입할 때, 로우 스토어는 디스크의 맨 끝(또는 빈 공간이 있는 블록)에 한 줄의 데이터를 덩어리째 한 번에 밀어 넣습니다. 단 한 번의 디스크 쓰기(Write) 작업으로 모든 컬럼이 완벽하게 저장되므로 매우 빠릅니다. (컬럼 스토어처럼 각 컬럼 블록을 찾아다닐 필요가 없습니다.)

2. 단일 레코드 조회(Select) 시 최고의 효율

"홍길동 회원의 상세 정보를 모두 보여줘!"라는 쿼리(Point Query)가 들어왔을 때, 인덱스를 타서 홍길동이 저장된 디스크 블록 하나만 쓱 퍼올리면, 그 안에 나이, 주소, 연락처가 다 들어있으므로 즉시 응답할 수 있습니다.

Ⅲ. 로우 스토어의 단점과 한계

은행이나 쇼핑몰의 일상적인 영업(OLTP)에는 무적이지만, 연말 정산이나 데이터 분석(OLAP)을 할 때는 약점을 드러냅니다.

비효율적인 대량 집계 연산

"전체 고객의 평균 나이를 구하라"라는 쿼리를 날렸을 때, 나이 정보만 필요한데도 불구하고 DB는 나이 옆에 찰싹 붙어있는 불필요한 이름, 주소, 전화번호 데이터까지 통째로 메모리로 끌어올려야 합니다. 결과적으로 쓸데없는 디스크 I/O가 폭발적으로 발생하여 메모리 버퍼를 금방 채워버리고 시스템을 랙(Lag) 걸리게 만듭니다.

📢 섹션 요약 비유: 로우 스토어는 '1인분 종합 선물 세트(도시락)' 포장 방식입니다. 손님 한 명이 오면 도시락 하나만 툭 내주면 되므로(INSERT/조회) 장사하기 편합니다. 하지만 나중에 "오늘 판 도시락에서 콩자반(특정 컬럼)이 몇 알 나갔지?"를 세려면 포장된 도시락을 전부 다 뜯어헤쳐야 하는(풀스캔) 엄청난 수고가 따릅니다.