데이터베이스(1) : 데이터베이스의 기초, Introduction

DBMS(Database Management System)

먼저, 데이터베이스를 다룰 때는 DBMS라고 부르는 소프트웨어를 사용해 다루게 된다.

우리는 DBMS로 하여금 데이터를 생성, 복사, 수정, 삭제하며 데이터베이스를 관리할 수 있다!

더불어 DBMS는 필수적으로 인터페이스를 제공해야하는데, 누구나 쉽게 접근이 가능하고 데이터가 '일치' 상태로 유지되어야 하기 때문이다.

소프트웨어라고 하면 그냥 우리가 아는 애플리케이션이나, 프로그램들을 떠올리겠지만,

사실 조금 더 깊은 바닥의 시스템 소프트웨어처럼 항상 실행되고 있는 프로그램을 떠올리는 것이 좋다.

그래서 이후 MySQL이나, MongoDB등을 사용하면 컴퓨터를 키는 것과 동시에 같이 실행되어 백그라운드에서 돌아간다.

실질적으로 유저가 데이터에 접근하려면 API를 통해 DBMS에 요청하면, DBMS가 데이터에 접근해 가져오는 식이다.

왜 직접 접근하지 않고 중간에 DBMS를 사용하는가? 에 대한 대답은 다음과 같다.

 

각 유저, 앱마다 데이터에 접근하는 방식과 세팅이 모두 다르고 파일을 읽고 쓰고 업로드하는 것도 모두 제각각이기 때문.

그래서 DBMS를 통해 접근하게 바꾸어 접근 방법을 간단하고, 통일되게끔 만들어 주는 것이다.

 

DBMS는 크게 세 가지의 중요한 것들을 관리한다.

 

1. 데이터

2. 데이터베이스 엔진

3. 스키마

 

1번은 너무 자명하니 넘어가고, 2번 데이터베이스 엔진은 데이터를 접근, 잠금, 수정 할 수 있게 해주는 도구이다.

3번의 스키마는 직역하면 모양틀 정도로 해석할 수 있는데, 이는 데이터베이스의 논리적인 구조를 이야기한다.

더불어 DBMS는 수많은 데이터를 관리하기 때문에, 항상 모니터링과 백업, 리커버리가 가능해야한다.

데이터라는 특성 상 개인정보나, 빠져나가면 안되는 정보들이 저장되어 있다면, 당연히 블랙해커들이 노릴 것이다.

따라서 이를 모니터링하고, 공격을 감지하면 DB를 다운시키거나 이전으로 롤백시키는 등의 작업이 존재해야한다.

 

데이터베이스를 사용하는 예시에는 어떤 것들이 있을까?

당장 생각해도 떠오르는 것은 많다. 학교에서 학생들의 정보를 저장할 때, 은행, 공항, 커머스 등등..

다양한 분야에서 해당 분야에 필요한 기능을 추가하고, 그에 맞게 데이터를 가공해 데이터베이스에 저장해 사용한다!

 

DBMS가 존재하기 전 데이터베이스의 문제점

DBMS가 존재하기 이전에는, 기업에서 정보를 저장한다면 그냥 파일 시스템 상에 저장하게 될 것이다.

그러면 각각 개인이 데이터베이스 파일을 가지고 있게 되고, 이런 경우 다양한 문제점이 발생한다.

1. 데이터의 중복과 불일치 : 데이터베이스가 여러 개의 파일로 나누어져 여러 명의 유저에게 저장되어있다면, 
   필요없는 데이터가 중복되고, 이는 곧 데이터의 불일치를 야기한다.
   
   
2. 데이터 접근이 어려움 : 1번 때문에, 어느 파일이 가장 최신 데이터베이스 현황인지 알 수 없다.
   
   
3. 데이터 고립(Isolation) : 저장은 했지만 쓰이지 않는 데이터는 고립되어 유용한 정보가 있지만 안쓰게 될 수도 있다.
   
   
4. 무결성 문제(Integrity Problem) : 무결성 제약조건을 만족하지 못하는 상황이 발생한다( 추후에 더 알아볼 것 )

그래서 DBMS가 등장하게 됐고, 따라서 DBMS가 필수적으로 갖추어야 할 조건 두 가지가 있다.

1. 업데이트의 원자성(Atomicity) : 만약 어떤 행동이 실행되다가 중간에 멈췄다면, 그 결과는 반영하지 않아야한다.
   즉, 온전히 실행되었을 때만 데이터베이스에 반영되고, 그게 아니면 아예 반영하지 않아야 한다.
   
   예를 들자면, 계좌이체와 같다. 나는 보냈는데, 중간에서 오류가 나서 상대방 측에서 입금이 안됐다고 가정해보자.
   이때 이게 그대로 데이터베이스에 반영되면 나는 돈이 허공에서 사라진 것이다. 따라서 이런 경우는 반영을 하지 않아야한다. 내 계좌에서 돈이 빠지고, 상대방 계좌에 정상적으로 들어가는 것이 확인된 후에 반영을 하는 것이다.
   
   
2. 다중 유저의 동시 접근 지원 : 데이터베이스는 한 명만 다루는 것이 아니라, 수 많은 유저가 동시에 접속하게 된다.
   따라서 한 번에 한 명만 지원하는게 아니라, 여러 명이 데이터에 접근할 수 있도록 해야한다. 이때 주의할 점은,
   하나의 정보에 대해 동시 접근은 불가능해야 한다는 것이다. 이는 곧 불일치를 야기하는데, 예를 들자면
   내가 100으로 바꾸려고 한 데이터 A를 누가 동시에 50으로 바꿔버리면 내 행동은 의미가 없어지는 것이기 때문이다.

View of Data

딱히 한국어로 표현할 방법을 찾지 못해 원문 표현을 그대로 적었다. 사실 데이터베이스라고 하면,

이미 정돈되고 잘 저장되어있는 데이터 목록을 보는 것을 생각할 것이다. 이는 추상화된 데이터를 우리가 보는 것으로,

실제로 어떻게 저장되고, 파일 시스템에서 어떻게 호출되고 동작하는지는 우리가 알 수 없는 것이다.

이것이 데이터베이스 시스템의 가장 주요 목적이기도하다. 굳이 알 필요 없는 정보는 추상화 시켜주는 것이다.

 

그래서 Data models 단계와 Data abstraction 단계로 나뉘게 된다.

Data models

데이터 모델은 우리가 데이터베이스를 사용할 때 보게되는 부분으로, 데이터, 데이터 관계, 제약조건 등이 이에 해당한다.

이 포스트에서는 앞으로 Relational model만 다룰 예정이다.

 

Relational model은 데이터를 나타내는 일종의 형태중 하나로, 우리가 잘 아는 표를 사용해서 나타내는 모델이다.

가장 흔하고 많이 사용되는 방식으로, 앞으로는 해당 데이터 모델을 위주로 공부할 것이다.

후에 ER(Entity-Relationship) data model에 대해서도 다루지만, 우선은 Relational model을 먼저 배울 것이다.

ER모델은 조금 더 고차원적인 데이터 모델로, 일종의 마인드맵과 같은 느낌을 준다.

하나의 엔티티를 설정하고, 그 엔티티가 가지고 있는 성질(Attribute)를 이어주는 식이다.

그 외에도 네트워크 모델, 우선순위 모델 등등 다양한 데이터 모델이 존재한다!

Data Abstraction

데이터 추상화는 크게 세 단계로 나눌 수 있다.

 

1. Physical level : 실제로 저장 장치(SSD, HDD)에 어떻게 저장되고 불러와 지는가?(bit 단위 이동)

2. Logical level : 데이터가 어떤 관계를 가지면서 데이터베이스에 저장이 되어있는지를 묘사

3. View level : DBMS 프로그램이 데이터에 대한 디테일(자료형, 제약조건 등)은 숨긴 채 유저에게 데이터를 제공,
                        혹은 유저의 권한에 따라 볼 수 있는 데이터를 제한함(각 직원들의 월급 등)

그나마 비슷한 형태이다.

 

따라서 우리는 Physical, Logical schema는 직접적으로 확인할 수 없고, 대신 Istance만 보게 되는 것이다.

이때 Instance란, 실제 특정시간 데이터베이스의 내용(데이터)으로, 우리가 수정하고 접근할 수 있는 정보들이다.

이후 인스턴스라는 말을 굉장히 자주 사용하게되니 잘 기억해두자!

Database Design

일반적인 구조의 데이터베이스를 디자인하는 과정은 다음과 같다.

• Logical design - DB의 schema를 결정하는 과정
  
  해당 과정은 이 프로젝트에서 어떤 데이터베이스 구조가 '좋은' 구조인지를 찾는 과정이다.
  주로 두 개의 의사결정 과정이 포함되는데,
  
  1. Business decision : 어떤 attribute를 포함해야 하는가로, DB에 적합한 데이터(성질)을 골라내는 과정이다.
  2. Computer science decision : 데이터베이스를 구성하는 사람들의 입장에서는 어떤 schema를 사용하는지,
  혹은 데이터를 어떤 자료형으로 저장할 것인지가 이에 해당한다.
  
  
• Physical design - 실제 저장공간을 어떻게 할당할 것인가

Database Engine

데이터베이스 시스템은 그 기능에따라 부분적으로 나누어져 있다. 크게 세 가지로 나눌 수 있는데,

 

1. Storage manager

2. Query processor

3. Transaction management 이다. 하나씩 알아보자.

Storage manager

실제 데이터를 저장하고 관리하는 역할로, 결국 OS 파일 시스템과 직접적으로 소통하는 모듈이라고 할 수 있다.

효율적으로 데이터에 접근, 저장, 수정할 수 있도록 해주며 쿼리를 시스템에 입력해주는 역할도 한다.

해당 모듈의 세부 기능에는 권한 및 무결성 관리, 트랜잭션 관리, 파일 관리, 버퍼 관리 등이 있다.

 

그 중에서도 파일을 관리하는 부분을 더 깊게 들여다보면, 데이터를 크게 세 가지로 분류해서 나눈다.

첫 째는 실제 데이터가 들어있는 데이터 파일로, 순수하게 데이터베이스에 저장된 데이터 그 자체이다.

둘 째는 데이터 딕셔너리(Data dictionary)로, 데이터베이스의 구조에 대한 메타데이터를 나타낸다.

쉽게 이야기하면, 데이터베이스의 스키마에 대한 정보, 위치에 대한 정보를 나타내주는 부분이다.

마지막은 인덱스로, 인덱스는 데이터베이스에서 필수적인 요소는 아니지만 데이터의 효율적인 접근을 위해 필요하다.

우리가 아는 배열에서의 인덱스와 똑같다. 몇 번 인덱스에 어떤 정보가 있는지 안다면 접근이 쉬운 점을 생각하자.

Query Processor

쿼리 프로세서는 우리가 데이터베이스에 접근하기 위해서 쿼리를 입력하면 이 쿼리를 처리해주는 모듈이다.

우선 쿼리가 무엇인지 간략하게 설명하자면, 일종의 명령어라고 생각하면 된다.

우리가 코딩할 때 특정 규칙을 지켜서 코드를 짜듯이, 쿼리 또한 특정 규칙을 지키며 작성해야 한다.

쿼리 언어는 데이터베이스마다 다르지만, 우리가 아는 컴퓨터 언어처럼 기본적인 틀은 모두 비슷하다.

 

그래서 쿼리 프로세서를 더 설명하자면, 컴파일러와 하는 일이 비슷하다고 생각하면 편하다.

쿼리 언어를 해석하고, 쿼리에서 요구하는 바를 컴파일해 DB엔진이 이해할 수 있도록 해준다.

추가로 여러 개의 쿼리가 동시에 들어올 때, 그 순서를 효율적으로 조절해 쿼리 실행을 최적화해준다.

일반적으로 데이터를 읽는 쿼리와 쓰는 쿼리가 있으면, 읽는 것을 먼저 하고 그 다음에 쓰는게 더 빠르다고 알려져있다.

Transaction Management

트랜잭션이란 하나의 논리적인 기능(function)을 수행하기 위한 일종의 연산 집합이다. 말만 들으면 이해가 안되니,

위에서도 이야기한 계좌 이체를 생각해보자. 내가 '송금'이라는 기능을 사용하려면, 다음과 같은 과정이 필요할 것이다.

 

1. 뱅킹 어플에 접속해 송금 계좌를 입력한다.

2. 송금 금액을 설정하고 송금한다.

3. 내 계좌에서 돈이 빠져나간다.

4. 상대방 계좌에 돈이 입금된다.

5. 이체가 종료된다.

 

하지만 이 과정이 진행 중에 3번에서 오류가 나서 진행이 중단되었다고 생각해보자. 만약에 송금이 정상적으로 되었다면

송금 전과 후의 나와 상대방 계좌의 금액의 합은 일정해야한다. 이것을 데이터가 일치(consistent)한다고 한다.

그러나 오류가 나 내 계좌에서 돈이 빠져나갔지만 상대방 계좌에 입금되지 않는다면, 이는 불일치(inconsistent)이다.

이런 트랜잭션 과정에서의 문제를 관리해주는 것이 Transaction management의 역할이다.

도중에 문제가 생기면 다시 원 상태로 복구하거나, 롤백해 다시 시작하는 기능이 필수적이라고 할 수 있다.

 

트랜잭션 과정에 대해서 더 자세히 알아보자.

Transaction의 과정이다

 

가장 먼저 트랜잭션이 실행되면 Active 상태에 들어간다. 이는 모든 트랜잭션의 처음 상태이다.

 

이후 트랜잭션에 있는 모든 연산(operation)이 완료되고 아직 DB에는 반영이 안된 상태를 Partially Committed라고 한다.

트랜잭션에 있는 연산은 모두 수행이 되었지만, 검사 등을 안거쳐서 아직 완벽하게 끝나지는 않은 상태이다.

 

만약 데이터베이스 복구 시스템에서 체크하는 도중 하나라도 문제가 생기면, 그 트랜잭션은 Failed 상태가 된다.

트랜잭션이 이 상태에 들어가면 더 이상 진행되지 못한다.

 

Failed 상태에 진입한 트랜잭션은 Aborted 상태로 넘어가는데, 이 부분에서는 트랜잭션을 복구하는 과정이 포함된다.

그 전에 수행된 모든 연산을 전부 롤백시키고, 다시 Begin 하기 직전의 상태로 돌린다. 이때 두 가지의 선택지가 주어진다.

1. Re-start the transaction

2. Kill the transaction 으로, 그냥 재시작하냐 아니면 아예 실행하지 않냐의 차이이다.

 

만약 Partially committed에 있는 트랜잭션이 데이터베이스 복구 시스템의 검증과, 데이터 무결성 등을 모두 통과했다면

데이터베이스에 트랜잭션의 결과가 반영되고, 이 상태를 committed라고 한다.

 

이렇게 단계별로 보면 매우 쉬워보인다. 그러나 현실의 데이터베이스에서는 초당 몇 천개, 몇 만개의 트랜잭션이 접근한다.

모든 트랜잭션에 대해서 이 과정을 수행하는 것은 매우 어려운 일이고, 항상 오류 없이 체크해내야 하기 때문에

사실 트랜잭션 관리는 매우 어렵고 중요한 모듈에 속한다.

MySQL의 전반적인 구조도이다.

위의 그림은 가장 대표적인 DBMS인 MySQL의 구조도로, 클라이언트를 통해 서버에 접근하고,

쿼리를 작성해 요청하면 데이터베이스 엔진을 통해 실제 파일 시스템에 접근해 정보를 리턴해주는 방식이다.

Database Administrator

그래서 이런 데이터베이스 시스템을 총괄하는 관리자를 DBA라고 부른다.

데이터베이스의 스키마를 정의하고, 구조와 접근 함수를 만들고, 하드웨어적 요소를 수정하는 등의 일을 한다.

그 외에도 점검루틴 유지, 주기적인 백업, 모니터링 등의 업무를 하기도 한다.

DB를 전공했을 경우 하나의 선택지가 될 것이다. 물론 바로 DBA가 될 수는 없겠지만..

 

 

첫 포스트부터 알 수 없는 용어가 남발해서 당황스럽겠지만, 추후 다시 설명할 일이 많을 것이다.

지금은 약간 Introduction 느낌으로 생각해주면 좋을 것 같다!

다음 포스트에서는 대다수 데이터베이스의 논리적 구조인 Relational model에 대해 알아볼 것이다.