treecode

트랜잭션의 격리 수준이란 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것이다.

격리 수준

READ UNCOMMITTED

READ COMMITTED

REPEATABLE READ
SERIALIZABLE

(밑으로 갈수록 격리 수준이 높아지고, 처리 성능이 떨어지지만 SERIALIZABLE이 아니라면 크게 성능 개선, 저하는 발생하지 않는다)

READ UNCOMMITTED는 트랜잭션이 커밋되지 않은 상태에서도 조회가 가능하기 때문에 이상한 값이 읽힐 수 있고 이를 더티 리드라고 하는데 일반적인 데이터베이스에서는 거의 사용하지 않는다.

SERIALIZABLE도 동시성이 중요한 데이터베이스에서 거의 사용되지 않는다.

READ COMMITTED는 오라클에서 기본으로 사용되는 격리 수준으로 가장 많이 선택되는 단계인데 어떤 트랜잭션에서 데이터를 변경했더라도 COMMIT이 완료된 데이터만 다른 트랜잭션에서 조회할 수 있다. 만약 트랜잭션이 커밋되기 전에 다른 트랜잭션에서 조회를 한다면 언두 로그에 백업(복사)해둔 변경 전 데이터가 반환이 된다. 

READ COMMITTED는 NON-REPEATABLE READ라는 부정합의 문제가 남아있는데 처음 조회를 했을 때는 바뀌지 않은 데이터가 중간에 다른 트랜잭션에서 UPDATE를 하고 커밋을 한 뒤에 다시 조회를 했을 때 바뀐 데이터가 반환되는 것이다.

REPEATABLE READ는 MySQL의 InnoDB 스토리지 엔진에서 기본으로 사용되는 격리 수준으로 바이너리 로그를 가진 MySQL 서버에서는 최소 REPEATABLE READ 이상의 격리 수준을 사용해야 한다.

InnoDB 스토리지 엔진은 트랜잭션이 롤백될 가능성에 대비해 변경되기 전 레코드를 언두 공간에 백업해두고 실제 레코드 값을 변경하는데 이러한 변경 방식을 MVCC(Multi Version Concurrency Control)라고 한다.

[MVCC와 언두 로그]

REPEATABLE READ는 언두 영역에 백업된 이전 데이터를 이용해 동일 트랜잭션 내에서는 동일한 결과를 보여줄 수 있게 보장한다.

READ COMMITTED도 MVCC를 이용해 커밋되기 전의 데이터를 보여주는데 둘의 차이는 언두 영역에 백업된 레코드의 여러 개의 멀티 버전 가운데 몇번째 이전 버전까지 찾아 들어가느냐에 있다.

모든 InnoDB 트랜잭션은 순차적으로 증가하는 고유한 트랜잭션 번호를 가지며, 언두 영역에 백업된 모든 레코드에는 트랜잭션의 번호가 기록되어 있다. (언두 영역의 백업된 데이터는 InnoDB 스토리지 엔진이 불필요해지면 주기적으로 삭제)

REPEATABLE READ은 MVCC를 보장하기 위해 실행 중인 트랜잭션 가운데 가장 오래된 트랜잭션 번호보다 트랜잭션 번호가 앞선 언두 영역의 데이터는 삭제할 수 없다. 정확히는 특정 트랜잭션 번호의 구간 내에서 백업된 언두 데이터가 보존돼야 한다.

userB(tx_id: 10)이 트랜잭션을 시작하고 다음 트랜잭션인 userA(tx_id: 12)가 시작해서 값을 바꿔도 userB는 언두 로그에 백업해둔 자기보다 낮은 tx_id의 데이터가 보인다. 하지만 REPEATABLE READ도 SELECT ... FOR UPDATE로 조회를 할 경우 현재 레코드의 값을 가져오는 부정합의 문제가 있긴 하다. 이렇게 다른 트랜잭션에서 변경을 해서 레코드가 보였다 안 보였다 하는 현상을 PHANTOM READ라고 한다.

 프로세스란 실행중인 프로그램을 말하며, 프로세스의 문맥(Context)을 아는 것이 중요하다. 여러 개의 프로세스들이 번갈아 실행이 되기 때문에 문맥 정보를 기억해두지 않으면 이어서 실행할 수 없기 때문이다.

프로세스의 문맥을 나타내는 정보는 CPU의 PC(Program Counter)와 각종 레지스터, 프로세스의 주소 공간, 그리고 운영체제 커널에 생성되는 해당 프로세스의 PCB(Process Control Block)와 커널 스택이 있다.

CPU의 PC는 해당 프로세스의 code 공간에 다음 실행할 명령어의 주소를 담고 있고커널 주소 공간은 프로세스들이 공유하기 때문에 프로세스별로 data영역에 PCB, 스택 영역에 프로세스별 스택을 생성한다.

프로세스의 상태는 다음과 같이 나뉜다.

NEW(생성 중)

RUNNING(CPU를 잡고 명령 수행 중)

READY(CPU 대기 상태)

BLOCKED(CPU가 있어도 명령을 수행할 수 없는 상태)

TERMINATED(처리가 끝난 상태)

SUSPENDED (외부적인 이유로 프로세스 수행이 정지된 상태)

프로세스 스케줄링 큐

프로세스는 준비 상태가 되면 READY 큐에 들어가서 CPU를 받아 처리를 하고 이때는 RUNNING 상태가 되고 이후 타이머 인터럽트에 의해 다시 READY 상태가 되거나 입출력 요청시 BLOCKED 상태가 되며 Device 큐에 들어간다.

여기서 프로세스 상태와 큐 공간은 운영체제가 프로세스를 스케줄링 하기 위해 Data 영역에 큐를 만들어놓고 프로세스 상태를 바꾸어가며 처리를 한다. (실제 큐는 우선 순위 큐처럼 우선 순위가 있다)

운영체제는 data 영역에 프로세스별로 PCB를 생성해서 보관한다 했는데 위에서 말한 프로세스의 상태, 스케줄링 정보, 우선순위, 프로세스의 문맥 정보, CPU 관련 PC, 레지스터 값 등을 구조체로 보관하고 있는다.

그래서 운영체제는 CPU를 현재 프로세스에서 다른 프로세스로 넘겨줄 때 현재 프로세스의 PCB에 상태를 저장하고 다음 프로세스의 상태를 PCB에서 읽어오는데 이를 문맥 교환(Context Switching)이라 한다.

시스템 콜이나 인터럽트가 발생해도 프로세스가 바뀌지 않으면 컨텍스트 스위칭이 발생하지 않는데 이 경우는 컨텍스트 스위칭은 아니지만 운영체제에게 CPU가 넘어가면서 PCB에 save가 된다. 하지만 컨텍스트 스위칭(캐시 메모리를 flush하는 등)에 비하면 추가 오버헤드가 적은 편이다.

프로세스 스케줄링에는 장기, 단기, 중기가 있는데 먼저 단기 스케줄러(Short term, CPU Scheduler)는 다음 번에 어떤 프로세스를 running시킬지 결정하고 프로세스에 CPU를 주는 문제를 담당한다.

장기 스케줄러(Long term, job scheduler)는 시작 프로세스중 어떤 것을 Ready 큐로 보낼지 결정하며 메모리에 올라가있는 프로세스의 수(degree of Multiprogramming)를 제어하는 방식으로 시분할 시스템에서는 보통 장기 스케줄러를 사용하지 않고 중기 스케줄러를 사용한다. 중기 스케줄러(Medium term, Swapper)는 일단 프로세스가 시작되면 메모리를 할당하고 너무 많은 프로그램이 올라가면 일부를 메모리를 뺏는 방식으로 프로세스의 수를 제어한다. 이때 프로세스 상태를 SUSPENDED라고 하며 프로세스가 통째로 디스크에 swap oup 되는데 이 외에 사용자가 프로그램을 정지시킨 경우도 SUSPENDED에 해당된다.

(BlOCKED는 자신이 요청한 event가 만족되면 READY, SUSPENDED는 외부에서 resume 해주어야 Active)

MySQL 서버는 사람의 머리 역할을 하는 MySQL 엔진과 손발 역할을 하는 스토리지 엔진으로 구분할 수 있다.

MySQL 엔진은 클라이언트로부터의 접속 및 요청을 처리하는 커넥션 핸들러와 SQL 파서, 전처리기, 쿼리의 최적화된 실행을 위한 옵티마이저가 중심을 이룬다. (SQL 문장을 분석하거나 최적화하는 등 두뇌 처리)

스토리지 엔진은 실제 데이터를 디스크 스토리지에 저장하거나 읽어오는 등 데이터를 읽고 쓰는 역할을 하며 MySQL 엔진의 쿼리 실행기에서 스토리지 엔진에 읽기 또는 쓰기 요청을 하는 것을 핸들러 요청이라 한다. (MySQL 엔진이 스토리지 엔진에게 데이터를 읽어오거나 저장하도록 명령하려면 반드시 핸들러를 통해야 한다)

MySQL 엔진은 하나, 스토리지 엔진은 여러 개를 동시에 사용할 수 있다.

MySQL의 메모리 공간은 글로벌 메모리와 로컬 메모리 영역으로 나뉘는데 글로벌 메모리 영역은 MySQL 서버가 시작되면서 운영체제로부터 할당되며 클라이언트 스레드의 수와 무관하게 보통 하나(2개 이상도 되긴 함)의 메모리 공간으로 모든 스레드에 의해 공유된다.

로컬(세션) 메모리 영역은 클라이언트 스레드가 쿼리를 처리하는데 사용하는 메모리 영역으로 클라이언트 스레드별로 독립적으로 할당되며 절대 공유되지 않는다. 중요한 특징은 각 쿼리의 용도별로 필요할 때만 공간이 할당되고 필요하지 않은 경우에는 MySQL이 메모리 공간을 할당조차도 하지 않을 수도 있다.

거의 대부분의 작업이 MySQL 엔진에서 처리되고, 마지막 데이터 읽기, 쓰기 작업만 스토리지 엔진에 의해 처리(group by, order by등의 복잡한 처리는 MySQL 엔진의 쿼리 실행기에서 처리)가 되는데 하나의 쿼리 작업에 있는 하위 작업들이 각각 어느 영역에서 처리되는지 구분할 줄 아는 것이 중요하다.

쿼리 파서는 사용자 요청으로 들어온 쿼리 문장을 MySQL이 인식할 수 있는 토큰 단위로 분리해서 트리 형태의 구조로 만들어낸다.

(이 과정에서 문법 오류가 발견된다.)

전처리기는 테이블 이름이나 칼럼 이름 또는 내장 함수와 같은 개체를 매핑해 해당 객체의 존재 여부와 접근 권한 등을 확인한다

옵티마이저는 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할지를 결정하는 중요한 역할을 하며 DBMS의 두뇌에 해당한다. 어떻게 하면 옵티마이저가 더 나은 선택을 할 수 있도록 유도하는지 아는 것이 중요하다.

쿼리 캐시는 SQL의 실행 결과를 메모리에 캐시하는 것으로 매우 빠른 성능을 보이지만 테이블의 데이터가 변경되면 캐시에 저장된 결과 중에서 변경된 테이블과 관련된 모든 것을 삭제해야 한다. 이는 동시 처리 성능 저하와 많은 버그의 원인이 되기 때문에 MySQL 8.0으로 올라오면서 제거되었다.

데이터베이스 서버에서 테이블의 구조 정보와 스토어드 프로그램 등의 정보를 데이터 딕셔너리 또는 메타데이터라고 하는데 MySQL 8.0부터는 메타데이터와 MySQL 서버가 작동하는데 기본적으로 필요한 시스템 테이블 등을 InnoDB의 테이블에 저장해서 트랜잭션을 지원하도록 했다. (이전에는 메타데이터를 파일 기반으로 관리해서 MySQL 서버가 비정상으로 종료시 깨지는 문제 발생)

운영체제를 공부하기에 앞서 컴퓨터 시스템 구조를 보면 이전에 PC 조립을 통해 보았듯 메인 보드 위에 CPU, RAM, SSD, I/O 포트등이 있다. 운영체제는 이러한 컴퓨터 하드웨어 바로 위에 설치되어 하드웨어 소프트웨어 사이에서 컴퓨터의 자원(CPU, 메모리, 입출력 장치 등)을 효율적으로 관리하는 역할을 한다. (CPU 스케줄링, 메모리 관리, 인터럽트 입출력 관리, 프로세스 관리 등)

각각의 디스크, I/O 장치들에는 메인 CPU와 메모리처럼 이를 전담하는 device controller와 작업 공간인 local buffer가 있고 CPU에는 register, Interrupt line, mode bit이 붙어있다. 

먼저 레지스터는 CPU의 내부 메모리중 하나로 내부 메모리는 레지스터와 캐시 메모리인 L1, L2, (L3)으로 구성 되어 있는데 메인 메모리(RAM)가 HDD, SSD에 비해 아무리 빠르다고 해도 CPU와 속도 차이가 심하기 때문에 효율적으로 처리하기 위해 CPU 내부에 임시 메모리 저장소가 있는 것이다. (레지스터는 주로 연산 결과를 기억하는 용도)

CPU는 매우 빠르게 메인 메모리로부터 입력을 처리하는데만 집중을 하는데 입출력 처리 같은 경우는 CPU가 기다리기에 너무 비효율적이라 입출력이 되는 동안 다른 프로그램으로 넘어가 명령을 처리한다. 입출력 요청을 받으면 device controller는 입출력을 처리하는데 이후 interrupt line에 인터럽트가 전달(DMA Controller)되어 처리가 끝났다는 것을 알리는데 인터럽트가 들어오면 CPU 제어권이 운영체제에 넘어오면서 운영체제는 CPU를 넘겨 받고 인터럽트 처리를 한다.

운영체제가 프로그램에 CPU를 넘겨주고 받는 등의 처리를 하지만 다른 프로그램에 CPU를 넘겨주면 다시 강제로 받아올 수가 없기 때문에 CPU가 묶이는 상황(무한 루프 등)이 발생할 수 있다. 그래서 또 다른 하드웨어 요소인 타이머를 사용해 시간 제한을 걸어두고 초과가 되면 타이머 인터럽트에 의해 CPU 제어권이 다시 운영체제에 돌아가도록 한다. 이렇게 타이머 인터럽트에 의해 강제로 반납되는 것 외에도 사용자 프로그램은 직접 입출력을 받아오거나 할 수 없기 때문에 운영체제에 입출력 요청을 하고 CPU를 반납한다. 이를 시스템 콜이라 하며 일반적으로 디바이스 컨트롤러에서 발생하는 하드웨어적 인터럽트와 달리 트랩(소프트웨어적 인터럽트)이라고 한다.

운영체제에는 다양한 인터럽트에 따라 처리하는 인터럽트 처리 루틴이 있고 인터럽트를 처리하는 함수인 인터럽트 처리 루틴의 주소를 가지는 인터럽트 벡터가 있다.

운영체제와 사용자 프로그램은 이렇게 처리할 수 있는 권한에도 차이가 있기 때문에 보호 장치인 mode bit가 존재하는데 사용자 프로그램을 수행하는 사용자 모드(1)과 OS 코드를 수행하는 모니터 모드(0)로 계속 전환하면서 처리를 한다. (인터럽트 발생시 mode bit가 0으로, 사용자 프로그램에 cpu를 넘기기 전 1로 셋팅하는 등)

그리고 CPU에 인터럽트가 너무 걸려도 비효율적이기 때문에 DMA(Direct Memory Access) 컨트롤러가 존재하는데 DMA 컨트롤러는 입출력 처리가 끝나면 로컬 버퍼의 데이터를 메인 메모리에 복사하고 CPU에 인터럽트를 한번만 걸어서 요청한다.