데이터 중심 어플리케이션 - 3장

저장소와 검색

 

데이터베이스가 데이터를 저장하는 방법과 데이터를 요청했을 때 다시 찾을수 있는 방법에 대한 내용이 

기술되어 있습니다.

관계형 데이터베이스와 NoSQL 데이터베이스에 사용되는 저장소 엔진 설명과 로그구조 계열 저장소 엔진과

 B트리 같은 페이지 지향 계열 저장소 엔진 검토합니다.

 

NoSQL 데이터베이스(예: Cassandra, LevelDB, RocksDB 등)에서 핵심 개념

 

SSTable (Sorted String Table)

• 정렬된 키-값 데이터 블록을 담고 있는 불변 파일입니다.
• 일반적으로 압축, 인덱스, 블룸 필터 등과 함께 저장되어 효율적인 읽기를 지원합니다.
• 쓰기 시에는 기존 SSTable을 변경하지 않고, 새로운 SSTable을 생성합니다.

SSTable 구성 요소 예:

• 데이터 블록 (key-value 쌍)
• 인덱스 블록 (key → 데이터 블록 위치)
• 블룸 필터 (존재 여부 빠르게 확인)

LSM Tree (Log-Structured Merge Tree)

• 쓰기 성능을 최적화하기 위해 설계된 트리 구조입니다.
• 데이터를 먼저 메모리(MemTable) 에 저장하고, 일정량 쌓이면 디스크에 SSTable로 flush 합니다.
• 시간이 지나며 SSTable이 많아지면, 읽기 성능이 떨어지기 때문에 주기적으로 Compaction(병합) 작업을 통해 SSTable을 정리합니다.
• 쓰기(write) : MemTable (메모리) → flush → SSTable 생성
• 읽기(read) : MemTable → 최신 SSTable부터 순서대로 조회 (블룸 필터/인덱스 사용)  

SSTable vs LSM 요약 비교

항목	SSTable	LSM Tree
데이터 저장 단위	O (파일)	X (전체 구조)
읽기 효율	높음 (정렬 + 인덱스 + 필터)	SSTable 개수가 많으면 낮아질 수 있음
쓰기 성능	새 파일 생성으로 빠름	전체적으로 매우 우수
삭제 처리	Tombstone 기록	Compaction 시 제거됨
용도	디스크에 쓰기 위한 데이터 포맷	DB의 쓰기 최적화 전체 메커니즘

 

MemTable 이 있으면 속도는 빠르지만 장애시 데이터 손실 위험이 존재하며 WAL만 있으면 데이터 복구할 수

있지만 읽기나 정렬 속도가 떨어짐. 이 두 구조를 동시에 사용해서 성능과 신뢰성을 확보할 수 있음

 

MemTable vs WAL 요약 비교

항목	MemTable	WAL(Write-Ahead Log)
역할	메모리에 저장되는 최신 키-값 데이터 구조	디스크에 기록되는 순차 로그 (복구용)
위치	메모리 (RAM)	디스크 (HDD/SSD)
데이터 구조	보통 정렬된 Map 구조 (예: SkipList, AVL 등)	단순한 append-only 로그 파일
목적	빠른 읽기/쓰기 및 정렬 저장	장애 발생 시 데이터 복구 보장
휘발성	예 (시스템 재시작 시 소실됨)	아니오 (디스크에 영구 보관됨)
flush 시점	일정량 이상 쌓이거나 타이머 조건 충족 시 SSTable로 flush	flush 이후 불필요해진 WAL segment는 삭제 가능
복구에 사용	사용안됨 (RAM이기 때문에 재부팅 시 존재하지 않음)	사용됨(시스템 재시작 시 MemTable 재생성에 사용됨)
성능 영향	쓰기 매우 빠름 (RAM이므로)	디스크 쓰기지만 순차적으로 쓰기 때문에 효율적

 

 

LSM Tree는 디스크 쓰기가 빠르고 B-Tree는 읽기 성능이 우수(단일경로)하며 삭제/갱신이 즉각 반영된다.

LSM은 쓰기 로드가 많은 NoSQL, B-Tree는 RDBMS에서 적합하다. 예로 PostgreSQL(MySQL)에서 B-Tree 사용

 Cassandra 또는 RocksDB에서 LSM Tree 사용한다.

 

LSM Tree vs B-Tree: 개념 비교

항목	B-Tree	LSM Tree
구조	균형 잡힌 계층적 트리 구조	쓰기 로그 기반 병합형 구조
저장방식	디스크에 직접 쓰며 각 노드는 정렬된 키-값을 포함	먼저 메모리(MemTable)에 쓰고, 나중에 디스크(SSTable)로 flush
쓰기 성능	비교적 느림 (무작위 I/O 발생 가능)	빠름 (순차 쓰기 위주, 디스크 캐시 활용 용이)
읽기 성능	빠름 (한 번에 탐색 가능, 일반적으로 디스크 접근 횟수 적음)	느릴 수 있음 (여러 SSTable 탐색 필요, Compaction으로 해결 가능)
삭제 처리	즉시 삭제	tombstone 마킹 → 나중에 compaction 시 실제 삭제
인덱싱	디스크에 정렬된 페이지가 계층적으로 연결됨	MemTable + 다수의 SSTable 계층으로 구성
Compaction	불필요	필수 (쓰기 최적화의 핵심이며 읽기 성능 개선에도 중요함)

 

OLTP VS OLAP

 

특성	트랜잭션 처리 시스템(OLTP)	분석 시스템(OLAP)
읽기 패턴	질의당 적은 수의 레코드, 키 기준으로 가져옴	많은 레코드에 대한 집계
쓰기 패턴	임의 접근, 사용자 입력을 낮은 지연 시간으로 기록	대규모 불러오기 또는 이벤트 스트림
사용처	어플리케이셔을 통한 최종 사용자/소비자	의사결정 지원을 위한 내부 분석가
데이터 표현	데이터의 최신 상태(현재 시점)	시간이 지나면 일어난 이벤트 이력
데이터셋 크기	기가바이트에서 테라바이트	테라바이트에서 페타바이트
DBMS	오라클, MySQL (Row 기반)	버티카(컬럼 기반), 엑사데이터, AWS RedShift

 

데이터웨어하우스

다양한 출처의 데이터를 통합하여, 분석과 의사결정에 최적화된 형태로 저장하는 시스템으로
일반적으로 OLAP(Online Analytical Processing) 용도로 사용되며, 트랜잭션 처리보다는 데이터 분석/보고에 초점을 둡니다.

 

데이터웨어 하우스 특징

특성	설명
주제 중심적 (Subject-oriented)	특정 주제(판매, 고객, 제품 등)에 맞게 데이터를 구조화함
통합된 (Integrated)	서로 다른 시스템에서 수집된 데이터를 일관된 포맷으로 통합
시간 가변적 (Time-variant)	장기간 데이터를 저장하여 시간 흐름에 따른 변화 추적 가능
비휘발성 (Non-volatile)	저장된 데이터는 변경되지 않고 읽기 전용으로 유지 (분석에 집중)

 

 

스타스키마 스노우플레이크

스타 스키마(Star Schema)와 스노우플레이크 스키마(Snowflake Schema)**는 모두 데이터 웨어하우스에서 사용하는 다차원 모델링 기법입니다. 스타 스키마는 비정규화 형태이며 스노우플레이크는 정규화 형태입니다.

데이터웨어하우스는 성능이 읽기 성능이 중요하기 때문에 스노우플레이크 보다는 복잡성을 줄이기 위해 스타스키마

형태의 모델을 많이 사용합니다. 다만, 비정규화 형태는 데이터 갱신시 비용이 많이 소요되기 때문에 자주 변경이 되는

형태는 스노우플레이크 형태가 적합할 수 도 있습니다. 주어진 비즈니스 환경에 따라 적합한 모델링 정책이 필요합니다.

 

항목	스타스키마	스노우플레이크
정규화 수준	비정규화 (중복 허용)	정규화 (중복 최소화)
설계 복잡도	단순 (구현과 사용 쉬움)	복잡 (정규화로 인해 테이블 많음)
쿼리 성능	빠름 (조인 적음, 인덱스 활용 용이)	느릴 수 있음 (조인 많아짐)
저장 공간 효율성	낮음 (중복 존재)	높음 (정규화로 데이터 최소화)
유지 보수	쉬움 (테이블 구조 단순)	어려움 (정규화된 테이블 간 관계 관리 필요)
사용 예	작은 DW, 빠른 응답이 중요한 경우	대규모 DW, 공간 최적화가 중요한 경우