데이터베이스에 접근하는 API를 작업하면서도, 편리한 ORM을 이용하다보니 순수한 데이터베이스의 아키텍처나 내부 동작 구조를 정확히 파악하지 못한 상태라 위 도서를 통해 정리해보고자 한다.
DBMS 캐시
디스크의 데이터에 직접 제어하는 일에는 기억 비용이라는 것이 소모된다. 간단하게 데이터를 저장하는 데 소모되는 비용을 나타낸다. 많은 데이터를 영속적으로 저장하려면 속도를 잃고, 속도를 얻고자 하면 많은 데이터를 영속적으로 저장하기 어렵다.
사용자 - 캐시(버퍼) - 디스크DBMS는 디스크 접근을 줄이려는 목적으로 캐시(버퍼)라는 메모리를 사용한다.
DBMS의 캐시에는 아래와 같이 세 가지 정도의 종류가 있다.
데이터 캐시 (검색 중시)
데이터의 일부를 메모리에 유지하기 위해 사용하는 영역
실행할 select 구문에서 선택하고 싶은 데이터가 캐시되어 있다면, 빠른 속도로 응답 가능
로그 버퍼 (갱신 중시)
사용자에게 SQL 구문을 받으면, 곧바로 저장소 데이터를 변경하는 것이 아니라 로그 버퍼 위에 변경 정보를 전송, 이후에 디스크 변경 수행 (비동기식 작업)
저장소 데이터 변경에는 시간이 소요되므로, 사용자에게 SQL 구문이 끝났다고 알리는 미들웨어 역할
워킹 메모리
정렬 또는 해시 관련 처리
- 정렬 :
ORDER BY구문, 집합 연산, 윈도우 함수 등 - 해시 : 테이블 등의 결합
데이터베이스가 어떤 기능에 중점을 두는지에 기반을 둬서 메모리 리소스를 적절히 분배해야 한다.
휘발성의 문제
캐시(버퍼)는 메모리상에 존재하므로 장애 발생 시 휘발 가능성이 높다.
이를 피하고자 DBMS는 커밋 시점에 반드시 갱신 정보를 로그 파일(영속적 저장소)에 저장한다.
다만, 커밋 시에 디스크 동기 접근이 일어나는데 결국 여기서 지연 발생 가능성이 있다.
성능과 데이터 정합성은 반비례할 수 밖에 없으므로 주의한다.
옵티마이저 (최적화)
인덱스 유무, 데이터의 분산 및 편향 정도, DBMS 매개변수 등의 조건을 고려해서 선택 가능한 많은 실행 계획을 작성하고, 이들의 비용을 연산해 가장 낮은 비용의 실행 계획을 선택한다.
단, 옵티마이저가 선택하는 실행 계획이 최적이 아닐 수 있으므로 사용자가 대응할 수 있는 힌트 구 등을 사용하는 방법도 있다.
