002. DBMS and Buffer - llighter/database GitHub Wiki

SQL 레벨업

Memory Hierachy Wikipedia

Transaction Commit ... SQL Database Engine Blog

1. 공짜 밥은 존재할까?

• 기억 비용 : 데이터를 저장하는데 소모되는 비용
• 접근 속도 <-> 기억 비용 : 트레이드오프

2. DBMS와 기억장치의 관계

- HDD

• 2차 기억장치

- Memory

• 1차 기억장치

- 버퍼를 활용한 속도 향상

• 메모리가 크다면 디스크 접근을 줄여준다.
• 성능 향상을 목적으로 데이터를 저장하는 메모리 : 버퍼(buffer) 또는 캐시(cache)
• 버퍼 매니저 : '데이터를 어떻게, 어느 정도의 기간동안 올릴지' 관리

3. 메모리 위에 있는 두 개의 버퍼

DBMS가 데이터를 유지하기 위해 사용하는 메모리는 크게 두 종류이다.

• 데이터 캐시
• 로그 버퍼

데이터 캐시

• 디스크에 있는 데이터의 일부를 메모리에 유지
• '디스크를 건드리는 자는 불행해진다.'

로그 버퍼

• 갱신 처리와 관련(INSERT, DELETE, UPDATE, MERGE)
• DBMS는 갱신 처리와 관련된 SQL 구분을 받으면 로그 버퍼 위에 변경 정볼르 보내고 이후에 디스크 변경을 수행
• 데이터베이스의 갱신 처리는 SQL 구문의 실행 시점과 저장소에 갱신하는 시점에 차이가 있는 비동기 처리 이다.
• 디스크 I/O는 부하기 크기 때문에 위와 같이 비동기로 처리하여 한번에 적용하는 것이 성능상 유리하다.

4. 메모리의 성질이 초래하는 트레이드오프

- 휘발성의 문제점

• 장애 발생 시 메모리에 있던 데이터 유실로 인한 부정합 발생
• 데이터 캐시의 경우 원본 데이터는 남아 있기 때문에 다시 읽으면 됨
• 로그 버퍼 같은 경우 갱신 정보가 사라지기 때문에 심각한 문제가 발생 ex. 은행 입출금
• 따라서 커밋(Commit) 시점에서 갱신 정보를 로그 파일(Disk)에 쓴다.
• 커밋으로 인해 디스크에 동기 접근 할 때 지연 발생 가능성이 있음
• 데이터 정합성 <-> 성능 : 트레이드 오프

5. 시스템 특성에 따른 트레이드오프

- 데이터 캐시와 로그 버퍼의 크기

• 초깃값 : 데이터 캐시 > 로그 버퍼
• DB가 기본적으로 검색을 메인으로 처리한다고 가정하였기 때문
• cf. MySQL의 매뉴얼 : '서버가 DB전용이라면 물리 메모리의 80%를 버퍼 풀로 할당해도 괜찮다.'

- 검색과 갱신 중에서 중요한 것

• 검색 <-> 갱신 : 트레이드오프
• DBMS 중 자동으로 설정하는 기능이 있기도 하지만 리스크가 있다.

6. 추가적인 메모리 영역 '워킹 메모리'

- 언제 사용될까?

• 워킹 메모리(Working Memory): 정렬 또는 해시 관련 처리에 사용되는 작업용 영역
• 정렬 : ORDER BY, 집합 연산, 윈도우 함수 등
• 해시 : 테이블 등의 결합
• ORACLE의 경우 PGA(Program Global Area) 라고 부름
• 필요한 경우 사용되고, 종료되면 해제되는 임시 영역
• 이 영역이 다루려는 데이터양보다 작아 부족해지는 경우 DBMS는 저장소(Disk)를 사용한다.
• cf. OS에서의 스왑(swap)
• Oracle : 임시 테이블 스페이스(TEMP Tablespace)

- 부족하면 어떤 일이 일어날까?

• 저장소(Disk) 접근으로 전체적인 속도 저하