으르리 2025. 5. 6. 23:56

다양한 DBMS에서 애플리케이션에 적합한 엔진을 선택할 줄 알아야함.

특정 workload 유형에서 좋은 성능을 내게 엔진을 조정하려면

-> 저장소 엔진이 내부에서 수행되는 작업을 이해하고 있어야함

1. DB를 강력하게 만드는 데이터 구조
기본적 저장소 형식

-라인마다 쉼표로 구분된 키-값 쌍을 포함한 텍스트파일
-> 데이터 추가시 파일 마지막을 살피면됨
= append-only 파일 = log (애플리케이션 로그가 아닌, 연속된 추가 레코드)
📌동시성제어, 디스크 공간 회수, 오류 처리, 부분 레코드 처리 등 더 확인이 필요하긴함
데이터 찾기특정 데이터를 찾을 때 마다 풀스캔?
-> 검색비용 O(n) 발생

=색인 등.장


색인

기본적으로 primary data에서 파생된 추가구조

DB 내용에 영향 0

- 오로지 질의 성능에만 영향, 어떤색인을 쓰는지 매우 중요

❗️잘 선택한 색인은 읽기 속도를 향상시키지만 <-> 색인은 쓰기 속도를 떨어뜨림

-> 쓰기 과정에서 큰 오버헤드가 발생하는데 이때 색인도 갱신해야해서


1)해시색인키

-값 데이터 색인dictionary type과 매우 유사해 보통 hash map(table)로 많이 구성함

키를 데이터 파일을 계속 append하는 방식,메모리에는 바이트 오프셋에 매핑해 인메모리 해시맵을 유지

데이터를 읽을 때는 해시맵 오프셋을 찾아서 위치를 읽음

ex) Riak의 기본 저장소 엔진 Bitcask


디스크의 모든 공간에 적재시엔?

데이터를 일정 크기의 segment로 로그를 나누어 쓰기 수행

각 segment파일에 대해 compaction 을 수행해 중복된 키를 버리고 키의 최신 갱신 값만 유지

이 과정은 백그라운드에서 일어나 이전 segment 파일에서 읽기 쓰기 수행가능

segment는 immutable! 한번쓰면 유지


실 구현에서는
파일포맷,레코드삭제,crash복구 등 고려해야할 사안이 많음


장점
- 무작위 쓰기보다 빠름
- 동시성이나 고장복구가 간단
- 조각화 되는 데이터 파일 문제를 피할 수 있음

 

단점
- 키가 너무 많으면 메모리 부족해짐
- 풀스캔에 비효율


2)SS테이블과 LSM트리

SS테이블(Sorted String Table) 정렬된 문자열 테이블

:키로 정렬된 형식, 각 키는 각 병합된 세그먼트 파일 내에 한번만 나타나야함

해시 색인과 다르게 메모리에 모든 키의 색인을 유지할 필요 없음

일부 키에 대한 인메모리 색인만 필요

저장 로직
write 시 inmemory balanced tree에 추가 (memtable이라고도 함)
memtable이 임곗값보다 커지면 SS테이블 파일로 디스크에 기록
-> 새 SS테이블이 가장 최신 세그먼트
디스크에 기록하는 동안 새 memtable 기록
세그먼트 파일을 수정은 백그라운드에서 수행

LSM 트리 만들기
Log-Structured- Merge-Tree (SS테이블의 모음)
LSM 저장소 엔진: 정렬된 파일 병합과 컴팩션 원리를 기반으로 하는 저장소 엔진
-> 존재 하지 않는 데이터 select 시 모든 세그먼트를 full scan
❗️Bloom filter 사용
집합 내용을 근사한 메모리 확률적 데이터 구조
여러 개의 해시 함수를 사용, 특정 키가 들어오면 비트 배열에 여러 위치를 1로 설정
검색 시에도 같은 해시 함수를 적용해 비트 배열의 해당 위치들이 모두 1인지 확인
데이터가 존재 하지 않음을 명확히 안내

3)B트리
고정 크기의 블록/페이지로 나누고 페이지 단위로 reds/write
각 페이지는 고유한 주소를 가지고있어 빠르게 식별 가능

Root에서 시작하여 leaf 페이지(하위 페이지)를 참조해나감.
각 페이지는 키와 leaf페이지의 참조값을 가지고있음
-> 따라서 n개의 키를 가진 B트리는 항상 O(log n)

Orphan page(고아 페이지):어떤 페이지와도 관계가없는 페이지
이를 복구할 수 있게 Write_ahead log, WAL 또는 redo log(재실행 로그) 구조를 추가해 B트리 구현

4) 기타 색인 구조
a. 색인 안에 값 저장 : Heap file 이용
- clusterd index : index안에 모든 row와 데이터 저장
- beclusterd index : index안에 데이터 참조만 저장
- covering index : 위 두 index의 절충안, index안에 테이블의 column 일부를 저장

b. multi column index
- concatenated index : 하나의 column에 다른 column을 추가하는 방식 
ex) (성,이름) 전화번호부
- 다차원 색인: 한 번에 여러 칼럼에 질의하는 일반적인 방식
ex) 위도/경도 검색, PostGIS의 R트리

c. 전문 검색과 퍼지 색인
유사한 키, 애매모호(fuzzy)한 질의 위한 기술

d. 모든 것을 메모리에 보관
RAM이 저렴해지면서 Inmemory DB가 개발됨
ex) Redis,Couchbase
기존 디스크 중심 아키텍처에서 발생하는 오버헤드 없이 가용한 메모리보다 더 큰 데이터셋을 지원하게끔 확장
-> 안티 캐싱 : 메모리가 부족할 때 최근에 안 쓴 데이터를 디스크로 보냄
   -> 가상 메모리 스왑과 유사해 보이지만 개별 레코드 단위로 작업하며 전체 색인이 메모리에 있어야함

2. 트랜잭션 처리나 분석?
transaction?
논리 단위 형태로서 읽기와 쓰기 그룹
📌트랜잭션이 반드시 ACID(원자성(atomicity), 일관성(consistency), 격리성(isolation), 지속성 
(durability)) 속성을 가질 필요는 없음
 트랜잭션 처리는 주기적으로 수행되는일괄 처리 작업과 달리 지연 시간(lowdatency)이 낮은 읽기와 쓰기를 가능하게 한다는 의미

OLTP(online transaction processing)?
 사용자 입력을 기반으로 삽입되거나 갱신되는 애플리케이션 대화식 접근 패턴
-> data analytic 사용 
= OLAP(online analytic processing) 
많은 수의 레코드를 스캔해 레코드 당 일부 칼럼만 읽어 집계,통계 계산 
-> 분석용 개별 DB 필요성 증가
= data warehouse 등장

1) 데이터 웨어하우징
data warehouse
: OLTP 작업에 영향을 주지 않고 마음껏 질의할 수 있는 개별 데이터베이스

OLTP와 데이터 웨어하우스
둘다 SQL 인터페이스를 제공하나 다른 질이 패턴에 맞게 최적화되어있음
OLTP : 트랜잭션 처리(CRUD 중심), 빠른 쓰기와 인덱스 효율 중심
data warehouse: 분석/리포팅 중심, 대규모 스캔/집계/조인 성능 중심

2) 분석용 스키마
a. 별 모양 스키마(star schema, dimensional modeling)
많은 data warehouse의 정형화된 방식
스키마 중심에 fact table을 차원 테이블로 둘러싸고있음
b. 눈꽃송이 모양 스키마(snowflake schema)
star schema의 변형
차원이 하위차원으로 더 세분화 됨

3. 칼럼 지향 저장소
 테이블에 엄청난 개수 로우와 데이터가 있다면 효율적으로 저장하고 질의하기 어려워짐
 대부분이 OLTP DB는 로우 지향방식으로 데이터 배치
-> 테이블에서 한 로우의 모든 값은 서로 인접 저장
-> 이는 대용량 데이터쿼리 시 많은 시간 소요

= 칼럼 지향 저장소 등장

-> 모든 값을 하나의 로우가 아닌 각 칼럼별로 모든 값을 함께 저장, 각 칼럼을 개별 파일에 저장해 질의에 사용되는 칼럼만 읽고 구분 분석
1) 칼럼 압축
수백만 로우를 스캔해야 하는 데이터 웨어하우스 질의는 디스크로부터 메모리로 데이터를 가져오는 대역폭이 큰 병목
벡터화 처리(vectorized processing)
: 비트 AW와 OR 같은 연산자는 압축된 칼럼 데이터 덩어리를 바로 연산할 수 있게 설계하는 기법
2) 칼럼 저장소의 순서 정렬  칼럼 저장소에서 로우가 저장되는 순서는 중요하지는 않음
-> 삽입된 순서대로 저장하는것이 가장 쉬운 방안
-> 정렬은 압축에 도움이 되기때문에 SS테이블 처럼 순서를 도입해 색인 매커니즘으로 사용은 가능
❗ 칼럼을 독립적으로 정렬할 수는 없음 
     ->칼럼의 어떤 항목이 동일한 로우에 속하는지 알 수 없기 때문

3)칼럼 지향 저장소에쓰기  데이터 웨어하우스는 대부분 분석용 읽기 질의
-> 쓰기나 수정은 어려운편

특히  B 트리 사용과 같은 제자리 갱신(update-in-place) 접근 방식은중간에 값을 삽입하거나 수정할 때, 

전체 칼럼 파일을 다시 써야 함
그래서 LSM 트리처럼 메모리에 먼저 쓰고, 나중에 디스크에 병합해서 저장하는 방식을 사용

반응형