데이터베이스 아키텍처

 

🪡 아기텍처 개관

 

✨모델링의 정의

DBMS마다 데이터베이스에 대한 정의가 조금씩 다르다.

오라클은 디스크에 저장된 데이터 집합 (Datafile, Redo Log FIle, Control File 등) 을 데이터베이스라고 지칭하고, SGC(System Global Area) 공유 메모리 영역과 이를 엑세스하는 프로그램 집합을 합쳐서 인스턴스(Instance)라고 부른다. 기본적으로는 하나의 인스턴스가 하나의 데이터베이스만을 엑세스하는 형식이지만, RAC(Real Application Cluster)환경에서는 여러 인스턴스가 하나의 데이터베이스를 액세스할 수 있다. 반대로, 하나의 인스턴스가 여러 개의 데이터베이스를 엑세스할 수는 없다.

SQL Server는 하나의 인스턴스당 최고 32,767개의 데이터베이스를 정의해 사용이 가능하다. 기본적으로 amrster, model, msdb, tmepdb 드으이 시스템 데이터베이스가 만들어지고, 여기에 사용자 데이터베이스를 추가 생성하는 구조다. 데이터베이스를 하나 만들 때마다 주 데이터 파일(mdf)과 트랜잭션 로그 파일(ldf)이 하나씩 생기고,  저장할 데이터가 많을 경우 보조(Non-primary) 데이터 파일을 추가할 수 있다(ndf)

 

 

 

 

🧶 프로세스

 

✨ 프로세스?

SQL Server는 쓰레드 기반 아키텍처이므로 프로세스 대신에 쓰레드를 쓰는 것이 적합하다. SQL Server 뿐만 아니라 Oracle Window 버전에서도 쓰레드를 사용하지만, 프로세스와 구분해가며 설명하면 복잡하기 때문에 '프로세스' 로 통칭해 사용할 것이다.

프로세스는 서버 프로세스(Server Processes)와 백그라운드 프로세스(Background Processes) 집합으로 나뉘어진다. 서버 프로세스는 사용자가 던지는 명령을 처리하고, 백그라운드 프로세스는 뒤에서 일을 처리한다.

 

💡서버 프로세스(Server Processes)

서버 프로세스는 사용자 프로세스와 통신을 통해 각종 명령을 처리하고, SQL Server에서는 Worker 쓰레드가 같은 역할을 담당한다.

SQL을 파싱하고 필요하면 최적화를 수행하며, 커서를 열어 SQL을 실행하며 블록을 읽고 읽은 데이터를 정렬해서 클라이언트가 요청한 결과를 만들며 네트워크를 통해서 전송하는 작업을 전부 서버 프로세스가 실행한다고 생각하면 된다.

스스로 처리할 수 없게 구현되지 않은 기능, 예를 들면 데이터 파일로부터 DB 버퍼 캐시로 블록 적재를 하거나 Dirty 블록을 밀어냄으로 Free 블록을 확보하는 일, 그리고 Redo 로그 버퍼를 비우는 일 등은 OS, I/O 서브시스템, 백그라운드 프로세스가 처리할 수 있도록 Call을 통해 요청한다. 클라이언트가 서버 프로세스와 연결하는 방식은 모두 다르지만, 오라클의 경우는 서버 방식과 공유 서버 방식이 있다.

 

🐈‍⬛전용 서버(Dedicated Server) 방식

처음 연결요청을 받는 리스너가 프로세스(WIndow에서는 쓰레드)를 생성하고, 이 서버 프로세스가 단 하나의 프로세스를 위해 전용(Dedicated)서비스를 제공한다는 점이 특징이다. 전용 서비스를 제공하기 때문에, SQL을 수행할 때마다 연결 요청을 반복하게 되면 서버 프로세스의 생성과 해제도 반복을 하게 되기 때문에 DBMS에 큰 부담을 주고, 성능도 그만큼 떨어지게 된다. 그렇기 때문에 전용 서버 방식을 사용하는 OLTP성 애플리케이션에서는 Connection Pooling 기법을 필수적으로 사용해야만 한다.

 

🐣공유 서버(Shared Server) 방식

공유 서버는 그대로 하나의 프로세스를 여러 사용자 세션에서 재사용하는 것으로, 앞에 있는 Connection Pooling 기법을 구현해놓은 것이라고 볼 수 있다. 여러 개의 프로세스를 띄우고, 반복 재사용한다고 보면 쉽다.

- Java를 생각해보면 각각의 Class를 계속해서 호출하는 게 아니라, 호출을 위한 Service를 만들고 그것을 계속해서 활용해 재사용성을 높인다고 생각하면 쉽다. 조금 더 들어가면, Disptcher Servlet을 생각해보자.

공유 서버 방식으로 접속을 하게 되면, 사용자 프로세스는 서버 프로세스와 직접 통신하지 않고 Disptcher 프로세스를 거치게 된다. 사용자 명령이 Disptcher 에게 전달되면, 이를 SGA에 있는 요청 큐(Request Quese)에 등록한다. 이후 가장 먼저 가용해진 서버 프로세스가 요청 큐에 있는 사용자 명령을 꺼내 처리하고, 그 결과를 응답 큐(Response Queue)에 등록한다. 응답 큐를 모니터링하던 DIspatcher는 결과 발견 시 사용자 프로세스에게 전달한다.

 

💡백그라운드 프로세스(Background Processes)

 

 

 

 

🏹 파일 구조

 

✨데이터 파일

Oracle과 SQL Server 모두 물리적으로는 데이터 파일에 데이터를 저장, 관리한다. 이를 위해 공간을 할당 및 관리하는 논리 구조도 크게 다르지 않지만 약간의 차이가 존재한다

 

🐣블록(=페이지)

대부분의 DBMS에서 I/O는 블록 단위로 이루어진다. 즉,  데이터를 읽고 쓸 때의 논리적 단위가 블록이다.

Oracle에서는 2kb, 4kb, 8kb, 16kb, 32kb, 64kb의 다양한 블록 크기 사용이 가능하지만, SQL Server에서는 8kb 단일 크기를 사용한다는 특징이 있다.

블록 단위로 I/O한다는 것은 결국 하나의 레코드에서 하나의 칼럼만을 읽으려고 할 때도 레코드가 속한 블록 전체를 읽게 된다는 것을 말하는 것과 같다. 그렇기 때문에 SQL 성능을 좌우하는 가장 중요한 성능 지표는 엑세스하는 블록의 개수이며, 옵티마이저의 판단에 가장 큰 영향을 미치는 것 또한 엑세스를 위한 블록 개수라고 할 수 있다. 

 

🐤익스텐트(Extent)

테이블 스페이스로부터 공간을 할당하는 단위를 말한다.

테이블이나 인덱스에 데이터를 입력하다 공간이 부족해질 경우, 해당 오브젝트가 속한 테이블 스페이스(물리적으로는 데이터 파일)로 부터 추가 공간 할당을 받게 되는데, 이때 정해진 익스텐트 크기의 연속 블록 할당을 받는다. 예를 들어서, 블록 크기가 8kb인 상태에서 64kb 단위로 익스텐트를 할당하도록 정의했다면, 공간이 부족할 때마다 테이블 스페이스로부터 8개의 연속된 블록을 찾아 (만약, 찾지 못하면 새로 생성한다) 세그먼트에 할당한다. 익스텐트 내의 블록은 논리적으로는 인접하지만, 익스텐트끼리 서로 인접하진 않는다. 그러니까, 어떤 세그먼트에 2개의 익스텐트가 할당되었을 경우 데이터 파일 내에서는 서로 먼 거리에 위치할 수 있다는 말이다.

Oracle은 한 익스텐트에 속한 모든 블록을 단일 오브젝트가 사용하지만, SQL Server는 2개 이상의 오브젝트가 나눠서 사용할 수도 있다.

 

🎁세그먼트

SQL Server에서는 세그먼트라는 용어를 사용하지 않지만, 힙과과 인덱스 구조의 오브젝트가 여기에 속한다.

세그먼트는 테이블, 인덱스, Undo처럼 저장 공간을 필요로 하는 데이터베이스 오브젝트이다. 저장 공간을 필요로 한다는 듯은 결국 한 개 이상의 익스텐트를 사용함을 뜻한다. 테이블이나 인덱스를 생성할 때, 내부적으로 각각의 세그먼트가 생성된다. 이와 같이 오브젝트들은 세그먼트와 1:1 대응 관계를 가지고 있지만, 파티션은 예외적으로 1:m 관계를 가지게 된다. 즉, 파티션 테이블(또는 인덱스) 를 만들게 되면, 내부적으로 여러 개의 세그먼트를 생성하게 된다. 한 세그먼트는 자신이 속한 테이블 스페이스 내의 여러 데이터 파일에 걸쳐 저장될 수 있다. 즉, 세그먼트에 할당된 익스텐트가 여러 데이터 파일에 흩어져서 저장되는 것이며, 그래야 디스크 경합을 줄이면서 I/O 분산 효과를 언을 수 있다.

 

🐈‍⬛테이블 스페이스

테이블 스페이스는 세그먼트를 담는 콘테이너로, 여러 데이터 파일로 구성되어 있다.

SQL Server의 파일 그룹이 Oracle 테이블 스페이스에 해당된다고 볼 수 있다. 

데이터는 물리적으로 데이터 파일로 저장되지만, 사용자는 데이터 파일을 직접 선택하지 않는다. 즉, 사용자는 세그먼트를 위해서 테이블 스페이스를 지정할 뿐 실제 값을 저장 및 데이터 파일을 선택하고 익스텐트를 할당하는 것은 DBMS의 몫이라고 할 수 있다. 각 세그먼트는 위에서 언급하였듯 정확히 한 테이블 스페이스에만 속하지만, 한 테이블 스페이스에는 여러 세그먼트가 존재할 수 있다. 그리고 특정 세그먼트에 할당된 모든 익스텐트는 해당 세그먼트와 관련된 테이블 스페이스 내에서만 찾아진다. 즉, 한 세그먼트가 여러 테이블 스페이스에 걸쳐서 저장은 불가능한 것이다. 

 

🗂️임시 데이터 파일

임시(Temporary) 데이터 파일은 특별한 용도로 사용되는데, 대량의 정렬 또는 해시 작업을 수행하다 메모리 공간이 부족해질 경우 중간의 결과 집합을 저장하는 것으로 사용된다. 말 그대로 임시로 저장되었다가 자동으로 삭제되기 때문에 Redo 정보를 생성하지 않고, 그 결과로 나중에 파일에 문제가 생겼을 때 복구가 불가능하다. 즉 백업 또한 불가능하다는 것이다. 

Oracle에서는 임시 테이블 스페이스를 여러 개 생성 후, 사용자마다 별도의 임시 테이블 스페이스를 지정해줄 수 있다.

SQL Server에서는 단 하나의 tempdb 데이터베이스를 생성하고, 전역 리소스로 시스템에 연결된 모든 사용자 임시 데이터를 저장한다.

 

🏉로그 파일

DB 버퍼 캐시에 가해지는 모든 변경 사항을 기록하는 것으로, 이 파일을 Oracle에서는 'Redo 로그' 라고 부르며, SQL Server에서는 '트랜잭션 로그' 라고 부른다.

변경된 메모리 버퍼 블록을 디스크 상의 데이터 블록에 기록하는 작업은 Random I/O방식으로 이루어지기 때문에 느리다. 반면, 로그 기록은 Append 방식으로 이루어지기 때문에 상대적으로 그 속도가 굉장히 빠르다. 따라서, 대부분의 DBMS에서는 버퍼 블록에 대한 변경 사항에 대해 일일히 데이터 파일에 기록하는 게 아니라 우선 로그 파일에 Append 방식으로 빠르게 기록하는 방식을 채택한다. 후에 버퍼 블록과 데이터 파일 간 동기화는 적절한 수단(DBWR, Checkpoint)을 이용하여 나중에 배치 방식으로 처리한다. 사용자 갱신 내용이 메모리 상의 버퍼 블록에만 기록된 채로 아직 디스크에 실질적 기록이 되지 않았더라도 Redo 로그를 믿고 빠르게 커밋을 완료한다는 의미에서 이를 'Fast Commit' 매커니즘이라고 한다. 인스턴스 장애가 발생하더라도 로그 파일을 이용해 언제든 복구가 가능하므로 안심하고 커밋을 완료할 수 있는 것이다.

 

- Online Redo Log

캐시에 저장된 변경 사항이 아직 데이터 파일에 기록되지 않은 상태에서, 다양한 이슈로 인스턴스가 비정상 종료가 됐을 때에 사용자는 그때까지의 작업 내용을 모두 잃게 된다. 이러한 트랜잭션에서의 데이터 유실을 방지하기 위해 사용하는 것으로, 마지막 체크포인트 이후부터 사고 발생 직전까지의 수행된 트랜잭션을을 Redo 로그로 재현하는 것이며, 이를 '캐시 복구' 라고 한다. Online Redo 로그는 최소 두 개 이상의 파일로 구성되며, 현재사용 중인 파일이 꽉 차면 다음 파일로 로그 스위칭을 발생시킨다. 그리고 모든 파일이 꽉 차면 다시 첫번째 파일부터 재사용하는 라운드 로빈 방식을 사용한다.

 

- 트랜잭션 로그

트랜잭션 로그는 Oracle의 Online Redo 로그와 대응되는 SQL Server의 로그 파일이다. 주 데이터 파일, 즉 데이터베이스마다 트랜잭션 로그 파일이 하나씩 생성되며, 확장자는 ldf이다. 트랜잭션 로그 파일은 내부적으로 '가상 로그 파일' 이라고 불리는 더 작은 단위의 세그먼트로 나누어지고, 이 개수가 너무 많아지지 않도록(조각화 발생 방지) 옵션을 지정하는 것이 좋다. 

 

- Archived(=Offline) Redo 로그

Archived Redo 로그는 Oracle에서 Online Redo 로그가 재사용되기 전, 다른 위치로 백업해둔 파일을 말한다. 디스크가 깨지는 등의 물리적 저장 매체에 문제가 생겼을 때 데이터베이스 복구를 위해 사용된다. 

 

 

 

 

🛞메모리 구조

 

메모리 구조는 시스템 공유 메모리 영역과 프로세스 전용 메모리 영역으로 구분된다.

 

✨시스템 공유 메모리 영역

시스템 공유 메모리는 그대로 여러 프로세스(또는 스레드)가 동시에 엑세스 할 수 있는 메모리 영역으로, Oracle에서는 'System Clobal Area(SGA)', SQL Server 에서는 'Memory Pool'이라고 부른다. 공유 메모리를 구성하는 캐시 영역은 매우 다양하지만, 모든 DBMS가 공통적으로 사용하는 캐시 영역으로는 DB 버퍼 캐시, 공유 풀, 로그 버퍼가 있다. 공유 메모리 영역은 그 외에 Large Pool, Java Pool 등을 포함하고, 시스템 구조와 제어 구조를 캐싱하는 영역 또한 포함된다. 시스템 공유 메모리 영역은 여러 프로세스에 공유되기에 내부적으로 Latch, buffer Lock, 라이브러리 캐시 Lock/Pin 같은 엑세스 직렬화 메커니즘이 사용된다

 

💡프로세스 전용 메모리 영역

Oracle은 프로세스 기반 아키텍처이기 때문에 자신만의 전용 메모리 영역을 가질 수 있는데, 이를 'Process Global Area(PGA)' 라고 부르며, 데이터를 정렬하고 세션과 커서에 대한 상태 정보를 저장하는 용도로 사용된다.

쓰레드 기반 아키텍처를 사용하는 SQL Server는 프로세스 전용 메모리 영역을 가지지 않는다.

 

🐤 DB Buffer Cache

DB 버퍼 캐시는 데이터 파일로부터 읽어들인 데이터 블록을 담는 캐시 영역이다. 인스턴스에 접속한 모든 사용자 프로세스는 서버 프로세스를 통해서 DB 버퍼 캐시의 버퍼 블록을 동시에 엑세스할 수 있다. 일부 Direct Path Read 메커니즘이 작동하는 경우를 제외하면, 모든 블록 읽기는 버퍼 캐시를 통해 이루어진다. 즉, 읽고자 하는 블록을 먼저 버퍼 캐시에서 찾아보고 없을 때 디스크에서 읽는 것이다. 

디스크에서 읽을 때에도 먼저 버퍼 캐시에 적재한 후에 읽는다. 데이터 변경도 마찬가지로 버퍼 캐시에 적재되어있는 블록을 통해 이루어지며, 변경된 블록(Dirty 버퍼 블록)을 주기적으로 데이터 파일에 기록하는 작업은 DBWR 프로세스의 몫이다. 

디스크 I/O는 물리적으로 엑세스 암이 움직이면서 헤드를 통해 이루어지는 반면, 메모리 I/O는 전기적 신호에 불과하기 때문에 디스크 I/O에 비교할 수 없을 정도로 빠르다. 그렇기 때문에 모든 데이터베이스 시스템에 필수적 요소라고 볼 수 있다.

 

　🍀 버퍼 블록의 상태 

　 　 모든 버퍼 블록은 아래 세 가지의 상태 중 하나에 놓여있다.

　 　 - Free 버퍼 : 인스턴스 기동 후 아직 데이터가 읽히지 않아 비어있는 상태거나, 데이터가 담겼지만 데이터 파일과 서로 동기화된 상태이기에 언제든지 덮어 써도 무방한 버퍼 블록. 데이터 파일로부터 새로운 블록을 로딩하기 위해서는 우선 Free 버퍼를 확보해야 한다. Free 상태인 버퍼에 변경이 발생하면 그 순간 Dirty 버퍼로 상태가 변경된다

　 　 - Dirty 버퍼 : 버퍼에 캐시된 이후 변경이 발생했지만, 아직 디스크에 기록되지 않아 데이터 파일 블록과 동기화가 필요한 버퍼 블록을 말한다. 이 버퍼 블록들이 다른 데이터 블록을 위해 재사용되려면 디스크에 먼저 기록되어야 하며, 기록되는 순간 Free 버퍼로 상태가 변경된다

　 　 -  Pinned 버퍼 : 읽기 또는 쓰기 작업이 현재 진행 중인 버퍼 블록을 말한다.

 

　🛞 LRU 알고리즘

　　버퍼 캐시는 유한한 자원이기 때문에 모든 데이터를 캐싱해둘 수 없다. 그렇기 때문에 모든 DBMS는 사용빈도가 높은 데이터 블록 위주로 버퍼 캐시가 구성되도록 LRU(least recently used) 알고리즘을 사용한다.  모든 블록 헤더를 LRU 체인에 연결해 사용빈도 순으로 위치를 옮겨가다가, Free 버퍼가 필요해질 때면 엑세스 빈도가 낮은 쪽(LRU end) 데이터 블록부터 밀어내는 방식이다

 

🌮 공유 풀(Shared Pool)

공유 풀은 딕셔너리 캐시와 라이브러리 캐시로 구분하며, 버퍼 캐시처럼 LRU 알고리즘을 사용한다. SQL Server에서 같은 역할을 하는 메모리 영역을 프로시저 캐시(Procedure Cache)라고 부른다.

 

- 딕셔너리 캐시

데이터베이스 딕셔너리(Dictionary)는 에티블, 인덱스 같은 오브젝트는 물론 테이블 스페이스, 데이터 파일, 세그먼트, 익스텐트, 사용자, 제약에 관한 메타 정보를 저장한다. 그리고 말 그대로 딕셔너리 정보를 캐싱하는 메모리 영역이다. '주문' 테이블을 예로 들면, 입력한 주문 데이터는 데이터 파일에 저장되었다가 버퍼 캐시를 경유해 읽히지만, 테이블 메타 정보는 딕셔너리에 저장됐다가 딕셔너리 캐시를 경유해 읽힌다.

- 라이브러리 캐시

라이브러리 캐시(Library Cache)는 사용자가 수행한 SQL문과 실행계획, 저장 프로시저를 저장해두는 캐시 영역이다. 

사용자가 명령어를 통해 결과집합을 요구하면, 이를 최적으로 수행하기 위해 내부적으로 생성한 일종의 프로시저와 같다.

사용자가 쿼리 구문을 분석해 문법의 오류와 실행 권한 등을 체크한 뒤, 최적화 과정을 거쳐서 실행 계획을 만들고, SQL 실행 엔진이 이해할 수 있는 포맷팅하는 과정을 거친다. 이러한 과정이 반복 수행될 때마다 해당 작업을 계속해서 재실행하는 것은 비효율적이기 때문에 이와 같은 것을 저장하는 캐시 공간을 만들고, 재사용성을 높일 수 있다.

 

🎁로그 버퍼(Log Buffer)

로그 엔트리의 경우 로그 파일에 바로 기록하는 것이 아니라, 먼저 로그 버퍼에 기록한다.

서버 프로세스가 데이터 블록 버퍼에 변경을 하기 전에, Redo 로그 버퍼에 먼저 기록해두면 주기적으로 LGWR 프로세스가 Redo 로그 파일에 기록한다. 이와 같은 Oracle의 Redo 로그, Redo 로그 버퍼와 대비되는 개념이 SQL Server의 트랜잭션 로그, 로그 캐시이다

변경이 가해진 Dirty 버퍼를 데이터 파일에 기록하기 전, 항상 로그 버퍼를 먼저 로그 파일에 기록해야 하는 것인데, 인스턴스 장애가 발생할 때 로그 파일에 기록된 내용을 재현해 캐시 블록을 복구하고 최종적으로 커밋되지 않은 트랜잭션을 롤백하는 과정에서 로그 파일에 없는 변경 내역이 이미 데이터 파일에 기록되어 있으면 사용자가 최종 커밋하지 않은 트랜잭션이 커밋되는 결과를 초래하기 때문이다.