[데이터 중심 애플리케이션 설계] 3장 저장소와 검색

 

데이터 중심 애플리케이션 설계

데이터는 오늘날 시스템을 설계할 때 마주치는 많은 도전 과제 중에서도 가장 중심에 있다. 확장성, 일관성, 신뢰성, 효율성, 유지보수성과 같은 해결하기 어려운 문제를 파악해야 할 뿐 아니라 관계형 데이터베이스, NoSQL 데이터스토어, 스트림 처리자 또는 일괄 처리 처리자, 메시지 브로커 등을 포함한 도구의 다양성에 압도된다. 어떤 선택이 애플리케이션에 적합한가? 이 유행어들을 얼마나 이해하고 있는가? 마틴 클레프만은 이 실용적이고 포괄적인

저자

마틴 클레프만

출판

위키북스

출판일

2018.04.12

 

2년 전에 데이터 중심 애플리케이션 설계 책으로 스터디를 진행했던 적이 있습니다.

얼마 전에 글또 슬랙에서 데이터 중심 애플리케이션 설계 책을 읽는 스터디가 있길래
2년 전에 책 내용의 한 30%정도 이해하고 넘어갔던 것 같은데
조금 더 경험이 쌓인 지금은 책의 내용이 더 와닿고 실무에 사용할 것도 많지 않을까 하는 기대에 스터디에 신청하게 됐습니다.

 

 

 

이번에 읽고 간단히 적어보는 요약

 

데이터저장소

• 데이터를 저장하고
• 데이터를 읽는 것이 핵심 역할

로그의 경우 다시보게될 확률이 낮음

• 대게 문제가 있는 경우에만 보게됨, 일단 Append Only로 빠르게 쌓는게 합리적일 수 있음
• Append Only는 그냥 데이터를 추가로 저장하면 되기에 쓰기 처리량이 매우 높음

트랜잭션 데이터의 경우 다시보게될 확률이 높음

• 따라서 쓰기 성능만 보는 것이 아니고 읽기 성능도 많이 신경써야함

LSM 기반의 저장소가 대두된 이유? (추측: 쓰기 + 읽기가 모두 빨라야하는 서비스에서 쓰기가 병목이 되는 경우가 발생함)

• LSM 방식은 결국 뒷단에서 컴팩션을 해줘야함
• 때때로 많은 세그먼트의 데이터를 읽어야하거나, 컴팩션 도중에 데이터를 조회하면 조회속도가 매우 느릴 수 있음
• 반면, 페이지 방식의 데이터 저장은 일관된 읽기 속도를 보임

분석 데이터는 조회하는 패턴이 트랙잭션 데이터와는 또 다름

• 조회하는 Rows는 많고 전체 Column을 조회하는 경우는 거의 없음
• 따라서 Column 단위로 데이터를 압축해서 디스크에 저장하면 I/O를 최소화할 수 있음

select
    month
    , product_name
    , sum(quantity) as quantity
from fact_orders
group by month, product_name 
order by month, quantity desc

• 분석 조회 패턴에 맞게 컬럼 지향으로 데이터를 저장하면 잇점을 가질 수 있음
• 데이터 분석 수요가 많다면 별도 저장소를 가져갈만함
• 단 추가적인 관리포인트와 비용이 발생하니 기존 데이터저장소에서 충분히 분석이 가능하다면 필수는 아닌..

(아래는 2년 전에 데이터 중심 애플리케이션 설계책으로 스터디를 하며 준비했던 내용을 요약한 내용입니다.)

스터디 자료 원문 링크: https://github.com/Learning-Is-Vital-In-Development/23-11-DesigningDataIntensiveApplications/blob/main/w04/jongmin.md

23-11-DesigningDataIntensiveApplications/w04/jongmin.md at main · Learning-Is-Vital-In-Development/23-11-DesigningDataIntensive

 

1. 데이터베이스의 기본 역할과 저장소 엔진 선택

• 데이터베이스는 (1) 데이터를 저장하고 (2) 데이터를 제공하는 것이 핵심 역할.

• 애플리케이션 개발자는 서비스의 작업 부하(Workload)에 맞는 저장소 엔진을 선택해야 함.

• 트랜잭션(OLTP)과 분석(OLAP)에 최적화된 엔진이 다르므로, 적절한 선택이 필요.

• 저장소 엔진의 성능을 최적화하려면 내부 동작을 이해해야 함.

2. 데이터 저장 방식

데이터 저장 방식에는 크게 Log-Structured(로그 구조화) 방식과 Page-Oriented(B-Tree) 방식이 있음.

(1) Log-Structured 방식

• Append-Only (추가 전용) 저장 방식으로 데이터를 계속 추가.

• 데이터 변경이 없으며, 컴팩션(compaction) 과정을 통해 중복 제거 및 최적화 수행.

• 쓰기 속도가 빠르고, 장애 복구가 간단.

• 그러나 데이터 검색 시 비효율적일 수 있으며, 읽기 속도가 느려질 가능성이 있음.

(2) Page-Oriented (B-Tree) 방식

• 저장소를 고정 크기 페이지 단위로 나누고 데이터를 업데이트할 때 해당 페이지를 갱신.

• 색인(Index) 구조를 활용하여 검색 속도가 빠름.

• 그러나 쓰기 성능이 비교적 느릴 수 있음(특히 WAL, Write-Ahead Logging 방식 사용 시).

3. 데이터베이스를 강력하게 만드는 데이터 구조

(1) 인덱스 (Index)

• 인덱스는 기존 데이터에서 파생된 추가적인 데이터로, 읽기 속도를 빠르게 하는 역할.

• 그러나 인덱스를 갱신하는 추가 작업이 필요하므로 쓰기 속도를 늦출 수 있음.

(2) 해시 색인 (Hash Index)

• Key-Value 형태로 색인하며, 메모리에 유지.

• 단점: 메모리 사용량이 많고, 범위 검색(Range Query)이 어려움.

(3) SS-테이블 & LSM 트리

• SS-테이블(Sorted String Table): 데이터를 키 순서로 정렬한 데이터 구조.

• LSM(Log-Structured Merge) 트리는 SS-테이블을 기반으로 쓰기 성능을 향상시키는 저장소 방식.

• LSM 방식의 예시: LevelDB, RocksDB, Cassandra, HBase 등.

(4) B-Tree

• 전통적으로 가장 많이 사용되는 색인 구조.

• 데이터를 고정 크기 페이지로 관리하며, 읽기 성능이 뛰어남.

• 그러나 쓰기 연산 시 페이지 갱신이 필요하므로 쓰기 속도가 상대적으로 느릴 수 있음.

4. B-Tree vs. LSM 트리 비교

특성	B-Tree	LSM-Tree
쓰기 속도	느림 (기존 페이지 갱신 필요)	빠름 (Append-Only + 컴팩션)
읽기 속도	빠름 (즉시 검색 가능)	가변적 (여러 SS-테이블 조회 필요)
디스크 I/O	페이지 덮어쓰기로 I/O 부담 있음	순차적 쓰기로 I/O 부담 적음
컴팩션 필요 여부	없음	있음 (백그라운드에서 수행)
사용 예시	MySQL, PostgreSQL	Cassandra, LevelDB, RocksDB

• B-Tree는 읽기 성능이 뛰어나며, OLTP(트랜잭션 시스템)에 적합.

• LSM-Tree는 쓰기 성능이 뛰어나며, 로그 구조 기반 데이터베이스에 적합.

5. 트랜잭션 처리(OLTP) vs. 분석 시스템(OLAP)

OLTP (Online Transaction Processing)

• 트랜잭션 처리 시스템으로, 낮은 지연시간의 읽기/쓰기가 핵심.

• 인덱스를 활용하여 소량의 데이터를 빠르게 조회하는 것이 중요.

• 예: MySQL, PostgreSQL

OLAP (Online Analytical Processing)

• 분석 시스템으로, 대량의 데이터를 조회하여 집계하는 것이 핵심.

• 수많은 레코드를 읽고 연산해야 하므로 디스크 대역폭이 병목이 됨.

• 데이터 웨어하우스에서 주로 사용.

• 예: Amazon Redshift, Google BigQuery, Snowflake

특성	OLTP (트랜잭션)	OLAP (분석)
주요 읽기 패턴	적은 수의 레코드 조회 (Key 기반)	대량의 레코드 집계
주요 쓰기 패턴	임의 접근(랜덤) 쓰기	대규모 일괄 쓰기 (ETL)
사용 사례	웹 애플리케이션	비즈니스 분석, 데이터 마이닝
데이터 크기	기가바이트 ~ 테라바이트	테라바이트 ~ 페타바이트

6. 컬럼 지향 저장소 (Column-Oriented Storage)

• 행(Row)-지향 저장소는 한 행의 모든 컬럼을 함께 저장 → OLTP에 적합.

• 컬럼(Column)-지향 저장소는 컬럼별로 데이터를 저장 → OLAP에 적합.

컬럼 지향 저장소의 장점

• 필요한 컬럼만 읽으면 되므로 디스크 I/O가 줄어듦.

• 같은 컬럼의 값들은 유사한 패턴을 가지므로 압축 효율이 높음.

• 예: Amazon Redshift, ClickHouse, Apache Parquet, Google BigQuery

7. 최적화 기법

(1) 컬럼 압축

• 컬럼 데이터는 비슷한 값이 많기 때문에 RLE(Run-Length Encoding), 비트맵 인덱싱 등을 활용해 압축 가능.

• 압축된 데이터는 CPU 캐시에 효율적으로 로드되어 분석 성능 향상.

(2) 정렬 (Sort Key)

• 컬럼 저장소에서는 특정 컬럼을 기준으로 정렬하면 범위 조회가 훨씬 빨라짐.

• 정렬된 데이터는 압축률도 높아짐.

(3) 집계 및 캐싱

• 자주 사용되는 질의를 미리 집계하여 저장하는 구체화 뷰(Materialized View) 사용.

• 데이터 큐브(Data Cube)를 활용해 다차원 분석을 수행.

8. 정리

(1) 저장소 엔진은 OLTP vs. OLAP에 따라 선택해야 함

• OLTP: 빠른 랜덤 접근 & 인덱스 활용 → B-Tree 기반 엔진 사용

• OLAP: 대량 데이터 분석 & 디스크 대역폭 최적화 → 컬럼 지향 저장소 사용

(2) 로그 구조화 vs. 제자리 갱신 저장소

• 로그 구조화 저장소 (LSM-Tree): 쓰기 성능이 뛰어나며, 로그 기반 데이터 저장.

• 사용 예시: LevelDB, RocksDB, Cassandra, HBase

• 제자리 갱신 저장소 (B-Tree): 빠른 읽기 성능, 페이지 기반 저장.

• 사용 예시: MySQL, PostgreSQL

(3) 컬럼 저장소는 분석용 데이터베이스에 적합

• OLAP 시스템에서는 컬럼 지향 저장 방식 + 압축 + 정렬 최적화를 활용.

• 컬럼 저장소는 데이터 웨어하우스, 빅데이터 분석 환경에서 필수적.

이 요약을 보면 B-Tree vs. LSM-Tree, OLTP vs. OLAP, 컬럼 지향 저장소의 핵심 원리를 한눈에 정리할 수 있습니다. 🚀