아키텍처 구성
1. 쿼리 평가 엔진
- 사용자로부터 입력받은 SQL구문을 분석하고, 어떤 순서로 기억장치의 데이터에 접근할지 결정함. 이때 실행계획을 정하는 것
- 쿼리 평가 엔진은 실행계획을 세우고 실행하는 DBMS의 핵심적인 모듈
플랜 실행 기능, 연산 평가 기능, 옵티마이저, 파서포함
2. 버퍼 매니저
- DBMS는 특별한 용도로 사용하는 버퍼를 위한 메모리 영역을 확보함. 이 메모리 영역을 관리하는 역할을 버퍼 매니저가 수행
- 디스크 용량 매니저와 연계되어 동작함
3. 디스크 용량 매니저
어디에 데이터를 어떻게 저장할지 관리하며, 데이터의 읽고 쓰기 제어함
4. 트랜잭션 매니저, 락 매니저
- 수백에서 수천명, 어쩌면 그 이상이 동시에 데이터베이스에 접근함 - 이 각각의 처리는 트랜잭션 단위로 관리됨
- 트랜잭션의 정합성을 유지하면서 실행시키고, 데이터에 락을 걸어 대기시키는 등의 역할이 트랜잭션 매니저 / 락 매니저의 역할
5. 리커버리 매니저
- 정기적으로 데이터를 백업하고 문제가 일어났을 때 복구해주는 역할 수행
버퍼, 메모리
일반적인 SQL구문의 실행 시간 대부분은 입출력에 사용되므로, 디스크 접근 시간을 줄이는 것은 큰 폭의 성능 향상을 가능하게 한다. 그리고 이런 성능 향상을 목적으로 데이터를 따로 저장하는 것을 버퍼, 캐시라고 한다.
버퍼 매니저는 이런 버퍼에 데이터를 어떻게, 그리고 어느 정도의 기간 동안 올릴지를 관리한다.
DBMS가 데이터를 유지하기 위해 사용하는 메모리
대부분의 DBMS는 아래와 같은 두 개의 역할을 하는 메모리 영역을 가지고 있다.
일반적으로 데이터 캐시 메모리 영역이 로그 버퍼 영역보다 훨씬 크다.
- 데이터 캐시
- 디스크에 있는 데이터의 일부를 메모리에 유지하기 위해 사용하는 메모리 영역
- 데이터 캐시 메모리 영역에 데이터가 존재한다면 빠르게 응답
- PostgreSQL에서는 공유 버퍼, MySQL에선 버퍼 풀이라고 칭함
- 로그 버퍼
- 갱신과 관련된 SQL구문을 받으면 곧바로 데이터를 변경하지 않음. 일단 로그 버퍼 위에 변경 정보를 보내고 그 후에 디스크에 변경을 수행함
- 오라클이나 PostgreSQL의 경우, 1MB도 되지 않는 작은 크기 -
- 데이터베이스의 갱신처리는
구문 실행 시점과 실제 갱신 시점에 차이가 있는 비동기 처리. 사용자에게는 갱신이 끝났다고 통지하고, 내부적으로는 관련 처리를 지속함 - 만약 로그 버퍼 위에 존재하는 데이터가 로그 파일에 반영되기 전에 장애가 발생하여 유실된다면? → 복구 불가. 즉 사용자가 수행한 갱신 정보가 유실됨
정리하자면, 사용자가 갱신 SQL을 실행하면 우선 로그 버퍼 위에 변경 정보를 기록하고, 커밋되는 시점에 갱신 정보를 로그 파일에 쓴다.
❓DB의 로그 파일이란 쿼리 실행 기록을 남기는 파일을 의미하는 건지?
Commit
- 갱신 처리를 확정하는 것. 로그 버퍼에서 디스크로 씀
- 커밋된 데이터는 영속화된다
- 반드시 디스크에 동기 접근이 일어남
- PostgreSQL의 경우, 비동기 커밋을 지원함 - 커밋시점에도 로그 버퍼에서 디스크에 쓰지 않아 신뢰성을 버리고 속도를 추구하는 기능. 위험하므로 일반적으로는 사용하지 않는 것이 좋다
- 커밋 시점에 반드시 갱신 정보를 로그 파일에 씀 → 장애가 발생해도 정합성을 유지하도록 함
데이터 갱신시 동기/비동기 처리의 차이
- 동기 처리시에는 데이터 정합성은 보장받을 수 있으나, 성능적으로 비동기처리보다 뒤떨어짐
- 비동기 처리시에는 성능은 우수하나 데이터 정합성을 보장할 수 없음. 로그 버퍼의 데이터가 로그 파일에 반영되기 전에 유실되면 정합성을 잃음
왜 데이터 캐시(공유 버퍼)가 로그 버퍼보다 훨씬 클까?
데이터베이스는 기본적으로 조회를 메인으로 한다. 일반적으로 조회시에는 검색 대상 레코드가 수백만에서 수천만 건에 달하기도 하지만, 갱신 처리시에는 갱신 대상이 많아 봤자 트랜잭션별로 한 건에서 수만 건이다.
따라서 갱신 처리보다는 자주 검색하는 데이터를 캐시에 올려놓는 데에 더 많은 메모리를 사용하고자한 것이다.
만약 내가 만드는 시스템에서는 조회보다 갱신 작업이 훨씬 많이 일어난다면, 로그 버퍼를 늘리는 최적화 작업이 필요할 것이다.
로그 버퍼가 크게 잡히면 갱신 처리에 큰 부하가 걸릴 것을 고려한 분배이고, 데이터 캐시 영역의 메모리가 크다면 검색 처리의 성능을 고려한 분배이다.
워킹 메모리
DBMS는 일반적으로 데이터 캐시와 로그 버퍼 외에도 정렬 또는 해시 관련 처리에 사용되는 작업용 영역으로 워킹 메모리를 가지고 있다. 워크 버퍼, 정렬 버퍼라고도 한다.
- SQL에서
정렬(ORDER BY) 또는 해시 조인이 필요한 경우에 워킹 메모리를 사용- (해시 조인시 해시 테이블이 워킹 메모리에 저장됨)
- 쿼리 실행 종료시 해제
- 처리가 필요한 데이터의 양보다 메모리가 작으면 디스크를 사용해야 하므로 성능 저하가 발생함 (OS의 스왑)
- 자바가 힙 메모리가 부족할 때 모든 처리를 중단하는 것과 다르게, 일반적으로 워킹 메모리가 부족하면 사용하는 임시 영역을 가지고 있음
