Relational Systems: The Life of a Query
전형적인 RDMBS에는 5개의 메인 컴포넌트가 있다.
승객의 리스트를 달라는 클라이언트의 요청을 예로 들어보자. 이는 하나의 쿼리 트랜잭션이 된다. 그리고 다음과 같이 동작한다.
- 클라이언트의 API 요청은 네트워크를 타고
Client Communication Manager의 커넥션이 된다. 이 커넥션은 ODBC 또는 JDBC를 통해 만들어진다.
Client Communication Manager가 하는 일은 다음과 같다.- connection state를 만들고 기억한다.
- SQL commands에 응답하고 데이터와 컨트롤 메세지 (result codes, errors, etc)를 반환한다.
이 예제에서 Communication Manger는 보안 자격 증명 (security credentials) 를 만들고 새로운 커넥션과 현재 SQL command를 위한 세부사항을 저장한다. 그리고 나서 클라이언트의 요청을 DBMS의 깊은 곳으로 보낸다.
- 클라이언트의 첫 번째 SQL command를 받으면, DBMS는 command에 thread of computation를 할당한다. DBMS는 쓰레드의 데이터와 컨트롤 결과를
Communication Manager를 통해 클라이언트에 연결되도록 해야한다. 이 일은Process Manager가 한다. 이 단계에서 한가지 더 해야할 중요한 일은 admission control 이다. 쿼리를 바로 실행할지, 아니면 시스템의 자원이 충분할 때 까지 기다릴지 결정한다. - 쿼리가 쓰레드에 할당되면
Relational Query Processor가 쿼리를 실행하기 시작한다. 이 모듈은 유저가 인증되었는지 확인하고, 유저의 SQL 쿼리 텍스트를 쿼리 플랜으로 컴파일한다. 컴파일이 되면, 쿼리 플랜의 결과는 plan executor에 의해 핸들링된다. plan executor는 하나의 논리적 단위로 묶인 operators를 포함한다. operators는 joins, selection, projection, aggregation, sorting 등과 같은 것이다. - 클라이언트 요청의 query plan에는 하나 이상의 operators가 있다. operators는 DBMS의
Transactional Storage Manager에게 데이터 fetch를 요청한다. 이 모듈은 모든 데이터 엑세스 (read) 와 데이터 조작(manipulation) (create, update, delete)를 관리한다. 테이블과 인덱스를 포함한 데이터를 정리하고 접근하기 위한 알고리즘과 자료구조를 가지고 있다. 또한 버퍼 관리 모듈을 가지고 있다.
예제로 돌아와서, 클라이언트의 쿼리는 ACID를 보장하기 위해 트랜잭션 관리 코드를 실행시킨다. 데이터에 접근하기 전에, 락 매니저로부터 락을 얻는다. 클라이언트의 쿼리가 update를 포함하고 있다면 로그 매니저가 트랜잭션이 커밋된 경우 durable한지, 트랜잭션이 중단(aborted)된 경우 롤백이 가능한지 보장한다. - 이제, 데이터 레코드를 접근하여 클라이언트에게 결과를 주기 위해 계산(compute)할 준비가 되었다. 지금까지의 실행을 unwinding the stack 한다. access method는 query executor’s operator에게 컨트롤을 넘겨준다. 결과는
Client Communications Manager가 사용할 수 있도록 버퍼에 저장된다.
catalog와 memory manager는 유틸리티로, 트랜잭션 중에 실행된다. catalog는 query processor가 authentication, parsing, 그리고 query optimization 하는 중에 사용한다. memory manager는 메모리가 동적으로 할당되거나 할당이 해제될 때, DBMS의 어디에서든 실행된다. 다른 나머지 모듈은 특정 쿼리에서 독립적으로 실행된다.
