[DB] - DBMS와 버퍼 (1장)

[Irisation23]

DBMS와 버퍼

해당 Discussion은 버퍼 매니저의 기능 수행을 초점으로 맞춰 정리한다.
버퍼는 성능에 굉장히 중요한 영향을 미친다. 그리고 메모리는 한정된 희소 자원이다.
따라서 데이터를 버퍼에 어떠한 식으로 확보할 것인가 하는 부분에서 트레이드오프가 발생한다.

트레이드 오프란? 🤔

https://www.joinc.co.kr/w/man/12/%ED%8A%B8%EB%A0%88%EC%9D%B4%EB%93%9C%EC%98%A4%ED%94%84#:~:text=%EA%B7%B8%EB%9F%AC%EB%AF%80%EB%A1%9C%20%EC%8B%9C%EA%B0%84%EA%B3%BC%20%EB%B9%84%EC%9A%A9%EC%9D%84%20%EB%B9%84%EA%B5%90%ED%95%B4%20%EA%B0%80%EB%A9%B4%EC%84%9C%20%EC%B5%9C%EC%A0%81%EC%9D%98

많은 데이터를 영속적으로 저장하려 하면 속도를 잃고, 속도를 얻고자 하면 많은 데이터를 영속적으로 저장하기 힘들다는 트레이드오프가 발생하게된다.

---

2. DBMS와 기억장치의 관계

DBMS는 데이터 저장을 목적으로 하는 미들웨어이다.
DBMS의 대표적인 기억장치로 하드디스크와 메모리 2가지이다.

2.1 하드디스크(HDD)

인메모리 데이터베이스(in-memory database), SSD(Solid State Drive) 등등의 여러 기억장치가 있지만 가장 많이 이용되는 이유는
용량, 비용, 성능 관점에서 타당성이 아직까지는 가장 높기 때문에 이용되고있다.

하드디스크는 기억장치 계층에서 가운데인 2차 기억장치로 분류된다.
큰 장점도, 큰 단점도 없는 무난한 매체이다.

DBMS는 데이터를 디스크에도 저장하지만 이외의 장소에서도 보관한다.
이외의 장소는 1차 기억장치인 메모리에 보관하기도 한다.

2.2 메모리

메모리는 디스크에 비해 비용이 비싸다. 이때문에 일반적인 데이터베이스 서버의 경우 타배되는 메모리 양은 한두 자리 정도이다.
상용 시스템의 데이터베이스 내부 데이터를 모두 메모리에 올리는 것은 불가능하다.

2.3 버퍼를 활용한 속도 향상

DBMS가 일부 데이터를 메모리에 올리는 것은 성능 향상을 목표로 하고 있기 때문이다.
SQL 구문의 실행 속도를 올리기 위함이라 생각하면 될것 같다.
자주 접근하는 데이터를 메모리 위에 올려둔다면, 같은 SQL 구문을 실행한다고 해도 디스크에서 데이터를 가져올 필요 없이 곧바로 메모리에 읽어 빠르게 데이터를 검색할 수 있다.

메모리와 디스크는 수십만 배에서 수백만 배의 성능차이가 있다.

메모리에 미리 데이터를 올리는 이유는 디스크 접근을 줄이기 위함이다.
반복적인 SQL 구문의 실행 시간 대부분을 저장소 I/O (입출력)에 사용하기 때문이다.

이처럼 성능 향상을 목적으로 데이터를 저장하는 메모리를 버퍼(buffer) 또는 캐시(cache)라고 부른다.

OS 관점에서는 둘의 차이를 두고 있지만 해당 SQL 레벨업의 책에서는 동일한 개념으로 두고 있다.

캐시메모리와 버퍼메모리가 찜찜하다면?
캐시메모리와 버퍼메모리 정리 를 참조해보자.

사용자와 저장소 사이에서 SQL 구문의 디스크 접근을 줄여주는 역할을 한다.

고속 접근이 가능한 버퍼에 데이터를 어떻게, 어느 정도의 기간 동안 올릴지 관리하는 것이 DBMS의 버퍼 매니저이다.

---

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

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

• 데이터 캐시
• 로그 버퍼

두개의 버퍼는 사용자가 용도에 따라 크기를 변경하는 것이 가능하다.
만약 세팅이 필요하다면 해당 DBMS의 메모리 버퍼 설정 참조를 찾아보는 것을 추천한다.

3.1 데이터 캐시

데이터 캐시는 디스크에 있는 데이터의 일부를 메모리에 유지하기 위해 사용하는 메모리 영역이다.

3.2 로그 버퍼

로그 버퍼는 갱신 처리(INSERT, DELETE, UPDATE, MERGE)와 관련이 있다.
DBMS는 갱신과 관련된 SQL 구문을 사용자로부터 받으면, 곧바로 저장소에 있는 데이터를 변경하지 않는다.
일단 로그 버퍼위에 변경 정보를 보내고 이후(COMMIT 후) 디스크에 변경을 수행한다. -> 하지만 해당 내용은 제품에 따라 다름으로 일반적인 개념이라고 알아두자.

데이터베이스의 갱신 처리는 SQL 구문의 실행 시점과 저장소에 갱신하는 시점에 차이가 있는 비동기 처리 이다.

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

메모리는 비싼 가격은 단점이지만 이외에도 몇 가지 단점이 존재한다.

4.1 휘발성

메모리에는 데이터의 영속성이 없다. 작업도중 DBMS가 프로세스 다운(서버 다운) 현상이 발생한다면 작업 내역을 잃게된다.
해당 이유를 토대로 디스크를 완전히 대체하기 어렵다.

4.2 휘발성의 문제점

메모리에 있던 데이터가 모두 사라져버리면 데이터 부정합이 발생된다.
데이터 캐시는 원본 데이터가 디스크 위에 있어서 문제가 되지 않지만, 로그 버퍼위에 존재하는 데이터는 문제가 생긴다.
데이터 갱신이 이루어지는 도중에 데이터를 잃게 된다면 이는 분명 해결책이 제시되어야 하는 것이다.
100% 완벽한 해결책은 없지만 방법은 강구해 볼 수 있다.

4.3 휘발성 문제의 타협점

DBMS는 커밋 시점에 반드시 갱신 정보를 로그 파일(이는 영속적인 저장소 위에 존재한다.)에 씀으로써, 장애가 발생해도 정합성을 유지할 수 있게한다.
DBMS는 커밋된 데이터를 영속화한다.

반대로 커밋 때는 반드시 디스크에 동기 접근이 일어난다. 디스크에 동기 처리를 한다면 데이터 정합성은 높아지지만 성능이 낮아진다.( 디스크 동기 과정이 성능에 영향을 주기 때문) 그러나 성능을 챙기기 위한다면 데이터 정합성이 깨질 위험이 커진다.

이름	데이터 정합성	성능
동기 처리	O	X
비동기 처리	X	O

적절한 타협점을 찾아 사용해야한다.

---

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

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

데이터 캐시와 로그 버퍼의 용량이 비대칭적인 크기를 유지하고 있는 이유가 있을까?
대부분의 데이터베이스 제품군은 데이터 캐시의 용량이 로그 버퍼의 용량보다 크다.
그 이유는 데이터의 갱신 보다는 데이터의 조회가 실제 운영에는 더 많이 이루어지기 때문이다.
해당 이유를 토대로 데이터 캐시의 용량이 로그 버퍼의 용량보다 큰것이다.

데이터 캐시는 조회, 로그 버퍼는 갱신을 목표로 설계되었다고 생각하자.

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

메모리는 희소 자원이다. 이 메모리를 검색과 갱신 둘 중 어느 것을 우선할 지, 버려야 할 지 판단해야한다.
설계된 목표에 알맞는 메모리 설계가 필요함을 인식하고 있자.

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

2개의 버퍼 이외에도 일반적인 메모리 영역을 하나 더 가지고있다. 이는 정렬 또는 해시 관련 처리에 사용되는 작업용 영역으로 워킹 메모리(working memory)라고 부른다.
정렬은 ORDER BY 구, 집합 연산, 윈도우 함수 등의 기능을 사용할 때 사용된다.
해시는 주로 테이블 등의 결합에서 사용된다.

DBMS 별로 워킹 메모리 는 다른 명칭을 사용하고 있다.

Oracle: PGA
PostgreSQL: 워크 버퍼
MySQL: 정렬 버퍼

해당 작업용 메모리 영역은 SQL에서 정렬 또는 해시가 필요한 때 사용되고, 종료 되면 해제되는 임시 영역으로 일반적으로 데이터 캐시와 로그 버퍼와는 다른 영역으로 관리되는 경우가 있다.

워킹 메모리가 성능적으로 중요한 이유는 만약 이 영역이 다루려는 데이터양보다 작아 부족해지는 경우가 생기면 대부분의 DBMS가 저장소를 사용하기 때문이다.

해당 개념은 OS에서의 swap과 같은 개념이다.

https://jhnyang.tistory.com/103

많은 DBMS는 워킹 메모리가 부족할 때 사용하는 임시적인 영역을 가지고 있다.

Oracle: 임시 테이블 스페이스(TEMP Tablespace)
Microsoft SQL Server: TEMPDB
PostgreSQL: 일시 영역(pgsql_tmp)

임시 영역은 접근 속도가 느리다.

---

출처

SQL 레벨업 - 미크
https://alex-blog.tistory.com/120