DBMS

초기 파일 시스템은 데이터를 물리적인 파일과 레코드의 집합으로 관리하는 방식이다. 이 시기의 데이터 처리는 응용 프로그램이 직접 파일의 물리적 구조와 저장 위치를 관리해야 했다. 데이터는 순차 파일이나 인덱스 순차 파일과 같은 형태로 저장되었으며, 각 응용 프로그램마다 필요한 데이터에 대한 고유한 파일을 생성하고 유지했다.

이 방식은 데이터 종속성과 데이터 중복이라는 근본적인 문제를 가지고 있었다. 데이터 종속성은 응용 프로그램의 논리적 구조가 저장 장치의 물리적 구조에 의존하는 것을 의미한다. 저장 장치나 파일 형식이 변경되면 이를 사용하는 모든 응용 프로그램을 수정해야 했다. 데이터 중복은 동일한 데이터가 여러 응용 프로그램을 위해 서로 다른 파일에 중복 저장되는 현상이다. 이는 저장 공간의 낭비를 초래했을 뿐만 아니라, 데이터 불일치 문제를 야기했다. 한 파일에서 데이터를 갱신했을 때 다른 파일의 중복 데이터는 갱신되지 않아 일관성이 깨질 수 있었다.

데이터 공유와 통합 또한 제한적이었다. 파일이 특정 응용 프로그램에 종속되어 있기 때문에, 다른 프로그램이 해당 데이터를 사용하기 어려웠다. 데이터 무결성을 보장하기 위한 체계적인 메커니즘이 부족했고, 동시에 여러 사용자가 접근할 때의 충돌을 관리하는 기능도 미비했다. 이러한 한계는 데이터를 독립적인 자원으로 관리하고, 중복을 제거하며, 무결성을 유지할 수 있는 새로운 시스템의 필요성을 촉발시켰다.

1960년대와 1970년대에 주류를 이루던 데이터베이스 관리 시스템의 초기 형태는 계층형 데이터베이스와 네트워크 데이터베이스였다. 이들은 파일 시스템의 한계를 넘어 데이터 간의 논리적 관계를 명시적으로 정의하고 관리할 수 있는 최초의 체계적인 접근법을 제공했다.

계층형 데이터베이스는 데이터를 트리 구조로 조직한다. 각 레코드는 하나의 부모 레코드와 여러 개의 자식 레코드를 가질 수 있지만, 모든 레코드는 루트를 제외하면 반드시 하나의 부모만을 가져야 한다. 이 모델은 IBM의 IMS가 대표적이다. 데이터 접근 경로가 명확하고 성능이 예측 가능하다는 장점이 있었지만, 구조가 경직되어 있어 새로운 관계를 추가하거나 기존 구조를 변경하기가 매우 어려웠다.

이러한 계층형 모델의 제약을 완화하기 위해 등장한 것이 네트워크 데이터베이스 모델이다. CODASYL 컨소시엄에서 제안한 이 모델은 데이터를 그래프 구조로 표현하여, 하나의 레코드가 여러 부모 레코드를 가질 수 있도록 했다. 이는 오너-멤버 관계라는 개념을 통해 구현되었다. 대표적인 구현체로는 IDMS가 있다. 네트워크 모델은 복잡한 다대다 관계를 직접 표현할 수 있어 계층형 모델보다 유연했지만, 그 구조와 질의가 매우 복잡해졌다는 단점이 있었다.

두 모델의 공통적인 특징과 한계는 다음과 같이 정리할 수 있다.

이들 초기 DBMS는 데이터의 물리적 저장 구조와 접근 경로를 응용 프로그램이 직접 알아야 했기 때문에 프로그램-데이터 종속성 문제가 심각했다. 이는 1970년대 후반 관계형 모델이 등장하며 데이터의 논리적 구조와 물리적 구조를 분리하는 패러다임으로 대체되는 계기가 되었다.

1970년대에 에드거 F. 커드는 IBM에서 근무하며 기존의 계층형 데이터베이스와 네트워크 데이터베이스의 복잡한 구조적 한계를 극복하기 위한 새로운 모델을 제안했다. 그는 1970년 논문 "대형 공유 데이터 뱅크를 위한 관계형 모델"에서 데이터를 행과 열로 구성된 테이블의 집합으로 표현하고, 이들 간의 관계를 수학적 집합론에 기반하여 조작하는 관계형 모델을 발표했다. 이 모델은 사용자가 복잡한 물리적 저장 구조를 알 필요 없이 직관적인 논리적 구조로 데이터에 접근할 수 있게 하는 것이 핵심이었다.

초기 관계형 모델은 이론적 우수성에도 불구하고 당시 컴퓨터 하드웨어의 제약으로 인해 실용적인 성능 문제에 직면했다. 관계형 연산을 처리하는 데 필요한 계산 비용이 높았기 때문이다. 이 난관을 극복하는 데 결정적인 역할을 한 것은 IBM의 시스템 R과 캘리포니아 대학교 버클리의 INGRES 프로젝트였다. 이 두 연구 프로젝트는 관계형 데이터를 효율적으로 저장, 검색, 관리하기 위한 핵심 기술들을 실증적으로 개발했다.

이러한 연구 성과를 바탕으로 1980년대에 본격적인 상용 관계형 데이터베이스 관리 시스템이 등장하기 시작했다. 오라클, IBM DB2, 마이크로소프트 SQL 서버의 전신이었던 Sybase, 그리고 MySQL과 포스트그레SQL 같은 오픈소스 시스템들이 시장을 주도하게 되었다. 관계형 DBMS의 성공은 표준화된 SQL의 광범위한 채택과 직관적인 테이블 기반의 데이터 조직 방식 덕분이었다. 이로 인해 기업의 재무, 인사, 거래 데이터 처리 등 구조화된 데이터를 다루는 거의 모든 핵심 비즈니스 영역에서 관계형 DBMS가 사실상의 표준이 되었다.

1990년대 이후, 관계형 DBMS의 지배적 위치는 유지되었지만, 인터넷의 확산과 빅데이터의 등장으로 새로운 요구사항이 생겨났다. 이는 기존 관계형 모델로 처리하기 어려운 대규모의 비정형 데이터, 높은 처리 속도, 수평적 확장성에 대한 필요성에서 비롯되었다. 이러한 변화는 NoSQL 운동을 촉발시켰고, 다양한 데이터 모델을 기반으로 한 새로운 유형의 DBMS가 등장하게 되었다.

현대의 DBMS 생태계는 특정 문제 영역에 최적화된 다양한 시스템들로 구성된다. 주요 유형은 다음과 같이 구분할 수 있다.

또한, 단일 시스템의 한계를 극복하기 위해 다중 모델 데이터베이스가 등장했다. 이는 하나의 DBMS가 문서, 그래프, 키-값 등 여러 데이터 모델을 동시에 지원하는 시스템이다. 예를 들어, ArangoDB는 문서, 그래프, 키-값 모델을, Microsoft Azure Cosmos DB는 문서, 키-값, 그래프, 컬럼 패밀리 모델을 통합하여 지원한다.

현대 애플리케이션은 종종 폴리글랏 퍼시스턴스 접근 방식을 채택한다. 이는 작업에 가장 적합한 여러 종류의 DBMS를 조합하여 사용하는 아키텍처 패턴이다. 예를 들어, 사용자 프로필은 문서 데이터베이스에, 주문 내역은 관계형 데이터베이스에, 소셜 연결은 그래프 데이터베이스에 저장하는 방식이다.

저장 관리자는 DBMS의 핵심 구성 요소 중 하나로, 데이터베이스의 실제 데이터와 메타데이터를 디스크와 같은 비휘발성 저장 장치에 효율적으로 저장하고 접근하는 역할을 담당한다. 이 구성 요소는 상위의 논리적 데이터 구조와 하위의 물리적 저장 장치 사이의 추상화 계층을 제공하여, 응용 프로그램이나 사용자가 복잡한 저장 장치의 세부 사항을 알지 못해도 데이터에 접근할 수 있게 한다. 주요 책임은 데이터의 무결성과 보안을 유지하면서 데이터 저장 공간을 관리하고, 데이터 입출력 성능을 최적화하는 것이다.

저장 관리자의 주요 기능은 다음과 같다. 첫째, 데이터 파일과 인덱스 파일을 관리하여 데이터를 물리적으로 구성한다. 둘째, 버퍼 관리자를 통해 자주 사용되는 데이터를 메모리에 캐싱하여 디스크 접근 횟수를 줄이고 성능을 향상시킨다. 셋째, 데이터의 무결성을 보장하기 위해 데이터 사전에 저장된 메타데이터를 관리한다. 또한, 저장 공간 할당 및 회수, 디스크 블록의 효율적 배치, 데이터 압축 및 암호화와 같은 기능도 수행한다.

저장 관리자는 다양한 데이터 구조와 기법을 활용한다. 대표적인 예로 B-트리나 B+ 트리 인덱스는 데이터 검색 속도를 높인다. 데이터는 일반적으로 고정 길이 또는 가변 길이 레코드로 구성되며, 이러한 레코드들은 페이지 또는 블록 단위로 디스크에 저장된다. 저장 관리자는 이러한 페이지들을 버퍼 풀에 유지하며, 교체 알고리즘(예: LRU)을 사용하여 효율적으로 관리한다. 데이터베이스의 크기가 증가함에 따라, 저장 관리자는 데이터를 여러 디스크에 분산시키는 기법도 처리한다.

질의 처리기는 사용자나 응용 프로그램이 제출한 질의를 효율적으로 실행하기 위한 계획을 수립하고 실행하는 DBMS의 핵심 구성 요소이다. 이 모듈은 SQL과 같은 질의 언어로 작성된 선언적 명령을 데이터베이스가 실제로 처리할 수 있는 일련의 저수준 연산으로 변환하는 역할을 담당한다. 질의 처리 과정은 일반적으로 구문 분석, 최적화, 실행이라는 세 단계로 나눌 수 있다.

첫 번째 단계인 구문 분석에서는 질의 문장의 구문적 정확성을 검사하고, 데이터베이스 내에 참조된 테이블과 열이 실제로 존재하는지 확인한다. 이 단계의 결과는 주로 쿼리 트리나 구문 트리 형태의 중간 표현으로 생성된다. 다음으로 질의 최적화 단계에서는 이 중간 표현을 바탕으로 동일한 결과를 산출하는 다양한 실행 계획을 생성하고, 그중 가장 비용이 적게 드는 계획을 선택한다. 최적화기는 인덱스 사용 여부, 조인 알고리즘 선택(예: 중첩 루프 조인, 해시 조인), 연산 수행 순서 등을 결정하며, 이를 위해 데이터 통계(예: 테이블 크기, 열 값 분포)를 참조한다.

마지막 실행 단계에서는 선택된 실행 계획이 저장 관리자 및 기타 하위 시스템과 상호작용하며 물리적으로 수행된다. 실행 엔진은 계획에 명시된 순서대로 데이터 접근, 필터링, 정렬, 그룹화, 조인 등의 연산을 수행하여 최종 결과 집합을 사용자에게 반환한다. 이 전체 과정의 효율성은 데이터베이스의 전반적인 성능에 직접적인 영향을 미치므로, 질의 처리기는 DBMS 설계에서 가장 정교하게 다루어지는 부분 중 하나이다.

트랜잭션 관리자는 데이터베이스 관리 시스템에서 트랜잭션의 실행을 관리하고 제어하는 핵심 구성 요소이다. 이 모듈은 데이터베이스의 상태를 항상 일관되게 유지하는 것을 최우선 목표로 한다. 주요 책임은 트랜잭션의 시작과 종료를 관리하고, ACID 속성을 보장하기 위한 동시성 제어와 회복 기법을 실행하는 것이다.

동시성 제어를 위해 트랜잭션 관리자는 여러 트랜잭션이 동시에 실행될 때 발생할 수 있는 문제를 방지한다. 대표적인 문제로는 더티 리드, 반복 불가능한 읽기, 팬텀 읽기 등이 있다. 이를 해결하기 위해 락킹 기법이나 타임스탬프 순서화 같은 프로토콜을 사용하여 트랜잭션 간의 간섭을 조정한다. 예를 들어, 공유 락과 배타 락을 사용하여 데이터 항목에 대한 접근을 제어한다.

시스템 장애 발생 시 데이터의 무결성을 보장하기 위한 회복 기능도 담당한다. 이를 위해 로그 파일에 모든 트랜잭션의 변경 이력을 기록한다. 시스템에 장애가 발생하면, 이 로그를 기반으로 재실행 또는 취소 작업을 수행하여 데이터베이스를 장애 발생 전의 일관된 상태로 복구한다. 체크포인트 기법은 회복 과정의 효율성을 높이기 위해 주기적으로 사용된다.

트랜잭션 관리자의 작동은 일반적으로 다음과 같은 단계를 따른다.

관계형 DBMS는 에드거 F. 커드가 1970년에 제안한 관계형 모델을 기반으로 하는 데이터베이스 관리 시스템이다. 이 모델은 데이터를 행과 열로 구성된 테이블의 집합으로 표현하며, 각 테이블은 고유한 이름을 가진다. 테이블 간의 관계는 기본 키와 외래 키를 통해 설정된다. 이 접근법은 데이터의 논리적 구조와 물리적 저장 방식을 분리하여, 사용자가 복잡한 저장 구조를 알지 못해도 선언적인 SQL을 사용하여 데이터를 쉽게 조작할 수 있게 한다.

RDBMS의 핵심 강점은 데이터 무결성과 일관성을 보장하는 데 있다. ACID 속성을 준수하는 트랜잭션 처리를 통해 신뢰할 수 있는 데이터 운영 환경을 제공한다. 또한, 정규화 과정을 통해 데이터 중복을 최소화하고 이상 현상을 방지할 수 있다. 1980년대부터 본격적으로 상용화된 이후, 오라클 데이터베이스, IBM DB2, 마이크로소프트 SQL 서버, MySQL, PostgreSQL 등이 대표적인 RDBMS 제품이다.

다음은 주요 관계형 데이터베이스 관리 시스템과 그 특징을 비교한 표이다.

전통적으로 온라인 트랜잭션 처리 시스템의 핵심으로 자리 잡았으나, 대규모 분산 처리와 비정형 데이터 처리에는 한계가 지적되어 왔다. 이에 따라 NoSQL 데이터베이스가 등장하는 계기가 되기도 했다. 그러나 여전히 구조화된 데이터를 안정적으로 관리하는 데 있어 가장 보편적이고 신뢰할 수 있는 시스템으로 평가받는다.

NoSQL DBMS는 전통적인 관계형 DBMS의 고정된 스키마와 SQL 사용을 따르지 않는 데이터베이스 관리 시스템의 광범위한 범주를 가리킨다. "Not Only SQL"의 약자로 해석되며, 대규모 분산 데이터 처리, 유연한 스키마, 높은 가용성 및 수평적 확장성에 중점을 둔다. 이 유형의 DBMS는 빅데이터와 실시간 웹 애플리케이션의 등장과 함께 주목받기 시작했다.

NoSQL DBMS는 주로 처리하는 데이터 모델에 따라 몇 가지 주요 유형으로 분류된다. 각 유형은 특정한 사용 사례에 최적화되어 있다.

이러한 시스템은 일반적으로 ACID 트랜잭션의 엄격한 요구사항보다는 BASE 모델[2]을 따르는 경우가 많다. 또한, 데이터를 여러 서버에 분산하여 저장하고 처리하는 수평적 확장을 통해 시스템 성능을 향상시키는 데 주력한다. NoSQL DBMS의 선택은 애플리케이션의 데이터 구조, 읽기/쓰기 패턴, 일관성 요구사항, 확장성 필요성 등에 따라 결정된다.

객체지향 DBMS는 객체지향 프로그래밍 패러다임과 데이터베이스 기술을 통합한 시스템이다. 이 유형의 DBMS는 데이터를 객체 형태로 저장하며, 각 객체는 속성(데이터)과 메서드(행동)를 함께 캡슐화한다. 이는 관계형 DBMS에서 데이터를 평평한 테이블 형태로 저장하는 방식과 대비된다. 객체지향 DBMS의 주요 목표는 복잡한 데이터 구조와 관계를 더 직관적이고 효율적으로 표현하고 관리하는 것이다.

객체지향 DBMS는 객체 식별자, 상속, 다형성, 캡슐화 등 객체지향 프로그래밍의 핵심 개념을 지원한다. 객체 식별자는 각 객체에 고유한 식별자를 부여하여, 객체 간의 관계를 포인터와 유사한 방식으로 직접 참조할 수 있게 한다. 상속을 통해 새로운 객체 클래스를 정의할 때 기존 클래스의 속성과 메서드를 재사용할 수 있어 데이터 모델의 확장성과 재사용성을 높인다.

이러한 DBMS는 특히 복잡한 데이터 관계와 비정형 데이터를 처리해야 하는 분야에서 강점을 보인다. 주요 응용 분야는 다음과 같다.

그러나 객체지향 DBMS는 SQL과 같은 표준화된 질의 언어의 부재, 관계형 모델에 비해 상대적으로 복잡한 학습 곡선, 그리고 기존 관계형 시스템에 비해 제한적인 시장 점유율과 도구 생태계 등의 한계를 지니고 있다. 이로 인해 대규모 상업적 트랜잭션 처리보다는 특정 니치 시장에서 주로 사용된다. 이후 객체-관계형 DBMS가 발전하여 관계형 시스템의 장점과 객체지향 기능을 결합하려는 시도가 이루어지기도 했다.

클라우드 DBMS는 클라우드 컴퓨팅 인프라를 통해 서비스 형태로 제공되는 데이터베이스 관리 시스템이다. 사용자는 물리적 하드웨어를 직접 구매하거나 관리할 필요 없이, 인터넷을 통해 데이터베이스 서비스를 온디맨드 방식으로 이용한다. 주요 클라우드 제공업체로는 AWS, Microsoft Azure, Google Cloud Platform 등이 있으며, 이들은 자체적으로 관리되는 완전 관리형 데이터베이스 서비스를 제공한다.

클라우드 DBMS의 주요 장점은 탄력적인 확장성과 비용 효율성이다. 사용량에 따라 컴퓨팅 자원과 저장 공간을 신속하게 확장하거나 축소할 수 있어 트래픽 변동에 유연하게 대응할 수 있다. 비용 모델은 일반적으로 선결제 없이 실제 사용한 만큼만 지불하는 종량제를 기반으로 한다. 또한, 백업, 패치 적용, 장애 조치와 같은 운영 및 유지보수 작업이 클라우드 공급자에 의해 자동화되어 관리 부담이 크게 줄어든다.

클라우드 DBMS는 다양한 배포 모델과 데이터 모델을 지원한다. 배포 측면에서는 단일 클라우드에 배포되는 퍼블릭 클라우드 서비스가 가장 일반적이지만, 프라이빗 클라우드나 하이브리드 클라우드 형태로도 제공된다. 데이터 모델 측면에서는 전통적인 관계형 DBMS 서비스 외에도 NoSQL 데이터베이스, 인메모리 데이터베이스, 그래프 데이터베이스 등 특화된 서비스를 선택할 수 있다.

그러나 데이터의 물리적 위치에 대한 규제 준수 문제, 장기적 사용 시 비용 증가 가능성, 특정 벤더에 대한 종속성 등이 고려해야 할 주요 과제이다.

개체-관계 모델은 데이터 모델링의 개념적 설계 단계에서 널리 사용되는 고수준의 모델이다. 이 모델은 현실 세계의 정보를 개체와 그들 간의 관계로 추상화하여 표현한다. 주로 데이터베이스 설계의 초기 단계에서 시스템 요구사항을 분석하고, 사용자와 설계자가 공유할 수 있는 청사진을 만드는 데 활용된다.

모델의 핵심 구성 요소는 개체, 속성, 관계이다. 개체는 데이터베이스에 표현하려는 독립적인 실체(예: 고객, 주문, 상품)를 의미하며, 개체 타입으로 분류된다. 각 개체 타입은 속성(예: 고객ID, 이름, 주소)을 가지며, 키 속성을 통해 고유하게 식별된다. 관계는 두 개 이상의 개체 타입 간의 의미 있는 연관성을 나타낸다(예: '고객'이 '주문'을 '한다'). 관계는 일대일, 일대다, 다대다와 같은 카디널리티 비율과 참여 제약 조건으로 세부적으로 정의된다.

개체-관계 모델은 시각적으로 이해하기 쉬운 개체-관계 다이어그램을 통해 표현된다. ERD에서는 일반적으로 사각형이 개체 타입, 마름모가 관계, 타원이 속성을 나타낸다. 이 다이어그램은 이후 논리적 설계 단계에서 관계형 모델의 테이블과 열, 외래 키로 체계적으로 변환된다.

관계형 모델은 데이터베이스의 데이터를 관계의 집합으로 표현하는 논리적 데이터 모델이다. 1970년 에드거 F. 커드가 제안한 이 모델은 수학의 집합론과 술어 논리에 기반을 두고 있으며, 데이터를 행과 열로 구성된 테이블 형태로 구조화한다. 각 테이블은 특정 엔터티 유형을 나타내며, 행은 하나의 레코드(튜플)를, 열은 레코드의 속성(도메인)을 정의한다. 이 모델의 핵심은 데이터 간의 관계가 값(주로 기본 키와 외래 키)에 의해 맺어진다는 점이다.

관계형 모델의 주요 구성 요소는 관계(테이블), 속성(열), 튜플(행), 도메인(속성이 가질 수 있는 값의 집합), 키 등이다. 기본 키는 테이블 내 각 행을 고유하게 식별하는 속성 또는 속성의 집합이다. 외래 키는 한 테이블의 속성이 다른 테이블의 기본 키를 참조하여 테이블 간의 관계를 설정한다. 이러한 구조는 데이터의 중복을 최소화하고 데이터 무결성을 유지하는 데 기여한다.

이 모델은 강력한 이론적 기반 위에 구축된 관계 대수와 관계 해석을 제공한다. 관계 대수는 절차적 질의 언어로, 선택, 투영, 조인, 합집합 등의 연산자를 사용하여 새로운 관계를 생성한다. 관계 해석은 비절차적 언어로, 원하는 결과가 만족해야 하는 조건을 선언적으로 기술한다. 이러한 수학적 토대는 SQL의 설계와 발전에 직접적인 영향을 미쳤다.

관계형 모델의 장점은 구조의 단순성과 명확성, 데이터 독립성, 강력한 수학적 기반에 있다. 사용자는 복잡한 물리적 저장 구조를 알 필요 없이 직관적인 테이블 형태로 데이터를 조작할 수 있다. 그러나 성능상의 이유로 완전히 순수한 관계형 모델을 구현한 시스템은 거의 없으며, 대부분의 현대 RDBMS는 관계형 모델을 근간으로 하되 다양한 확장과 최적화를 포함하고 있다.

문서 모델은 데이터를 문서 형태로 구조화하는 비관계형 데이터 모델이다. 각 문서는 일반적으로 JSON이나 XML과 같은 반구조화된 형식을 사용하며, 관련된 데이터를 하나의 단위로 캡슐화한다. 문서는 키-값 쌍의 집합, 중첩된 문서, 또는 배열을 포함할 수 있어 복잡한 계층적 데이터를 자연스럽게 표현하는 데 적합하다. 이 모델은 스키마가 유연하거나 동적이며, 각 문서가 서로 다른 구조를 가질 수 있는 애플리케이션에 널리 사용된다.

이 모델의 주요 특징은 데이터의 정규화가 필요하지 않다는 점이다. 예를 들어, 사용자 프로필과 그 사용자의 주문 내역을 하나의 문서에 함께 저장할 수 있다. 이는 관계형 모델에서 여러 테이블을 조인해야 하는 정보를 단일 조회로 가져올 수 있게 하여 읽기 성능을 향상시킬 수 있다. 대표적인 NoSQL DBMS인 MongoDB와 CouchDB가 이 모델을 구현한다.

문서 모델은 다음과 같은 장단점을 가진다.

문서 모델은 콘텐츠 관리 시스템, 사용자 프로필 저장, 카탈로그 관리, 실시간 분석 등 데이터 구조가 문서 중심이거나 빠르게 진화하는 애플리케이션에서 효과적이다. 그러나 데이터 간의 관계가 매우 복잡하거나 강력한 ACID 트랜잭션이 필수적인 경우에는 관계형 모델이 더 적합할 수 있다.

키-값 모델은 NoSQL 데이터베이스의 한 유형으로, 데이터를 단순한 키와 값의 쌍으로 저장하는 데이터 모델이다. 각 키는 고유한 식별자 역할을 하며, 이 키를 사용하여 연관된 값을 저장하거나 검색한다. 값은 문자열, 숫자, 객체, 리스트 등 다양한 형태의 데이터를 담을 수 있다. 이 모델은 복잡한 질의나 조인 연산보다는 특정 키에 대한 빠른 읽기와 쓰기 작업에 최적화되어 있다.

키-값 저장소의 구조는 매우 단순하다. 일반적으로 스키마가 고정되어 있지 않으며, 각 키-값 쌍은 독립적으로 존재한다. 이는 데이터 구조가 유연하고 수평적 확장이 용이하다는 장점을 제공한다. 주요 연산은 키를 통한 값의 삽입(Put), 조회(Get), 삭제(Delete)로 제한되는 경우가 많다. 복잡한 조건 검색은 지원하지 않거나 제한적으로 지원한다.

이 모델은 특정 유스케이스에서 매우 높은 성능을 발휘한다. 대표적인 적용 분야로는 세션 저장, 사용자 프로필 관리, 장바구니 데이터, 실시간 추천 시스템, 그리고 캐싱 등이 있다. 이러한 애플리케이션들은 대량의 간단한 데이터를 매우 빠른 속도로 처리해야 하는 요구사항을 가지고 있다.

주요 키-값 저장소 제품으로는 Redis, Amazon DynamoDB, Riak, etcd 등이 있다. 이들 시스템은 내구성, 일관성 수준, 메모리 내 저장 여부 등에서 차이를 보인다. 예를 들어, Redis는 주로 인메모리 저장소로 사용되며 다양한 데이터 구조를 지원하는 반면, Amazon DynamoDB는 완전 관리형 서비스로 높은 가용성과 확장성을 제공한다.

SQL은 관계형 데이터베이스 관리 시스템에서 데이터를 정의, 조작, 제어하기 위해 사용되는 표준화된 질의 언어이다. 1970년대 IBM 연구소에서 개발된 SEQUEL에서 기원하였으며, 이후 ANSI와 ISO에 의해 국제 표준으로 채택되었다. SQL은 선언형 언어의 특성을 가지며, 사용자는 원하는 데이터가 무엇인지를 기술하기만 하면 되고, 데이터를 어떻게 검색할 것인지는 DBMS의 질의 처리기가 결정한다.

SQL의 문장은 크게 세 가지 범주로 나뉜다. 첫째, 데이터 정의 언어는 데이터베이스의 구조를 생성하거나 변경한다. 주요 명령어로는 CREATE, ALTER, DROP이 있다. 둘째, 데이터 조작 언어는 데이터에 대한 조회, 삽입, 수정, 삭제 작업을 수행한다. SELECT, INSERT, UPDATE, DELETE 명령어가 이에 해당한다. 셋째, 데이터 제어 언어는 데이터에 대한 접근 권한과 트랜잭션을 관리한다. GRANT, REVOKE, COMMIT, ROLLBACK 등이 여기에 속한다.

가장 핵심적인 명령어인 SELECT 문은 다양한 절과 결합하여 강력한 데이터 검색 기능을 제공한다. 주요 절은 다음과 같다.

표준 SQL은 지속적으로 발전하여 새로운 기능을 추가하고 있다. SQL:1999부터는 재귀 질의와 윈도우 함수를 지원하기 시작했으며, SQL:2003에서는 XML 관련 기능이, SQL:2008에서는 MERGE 문이 도입되었다. 최신 표준에서는 JSON 데이터 처리와 시계열 데이터 분석을 위한 확장도 포함하고 있다. 이러한 표준 확장에도 불구하고, 오라클, MySQL, PostgreSQL, Microsoft SQL Server 등 주요 상용 및 오픈소스 RDBMS들은 각자의 고유한 확장 기능과 문법적 차이점을 가지고 있다.

NoSQL 질의 언어는 관계형 데이터베이스의 표준 질의 언어인 SQL과는 구별되는, 다양한 NoSQL 데이터베이스 관리 시스템에서 데이터를 조작하고 검색하기 위해 사용되는 언어 또는 인터페이스를 총칭한다. NoSQL 시스템의 데이터 모델이 각기 다르기 때문에, 이를 위한 질의 접근 방식도 문서, 키-값, 컬럼 패밀리, 그래프 등 모델에 따라 특화되어 발전했다.

주요 NoSQL 데이터베이스별 질의 언어 또는 API는 다음과 같은 특징을 가진다.

* 문서 지향 데이터베이스: MongoDB는 풍부한 쿼리 연산자를 제공하는 자체적인 질의 언어를 사용한다. 쿼리는 JSON과 유사한 BSON 문서 형태로 작성되며, find(), aggregate() 같은 메서드를 통해 필드 검색, 범위 쿼리, 집계 파이프라인 실행이 가능하다.

* 키-값 저장소: Redis나 Amazon DynamoDB와 같은 시스템은 주로 간단한 명령어 집합을 통해 데이터에 접근한다. GET, SET, DEL과 같은 기본적인 명령어가 핵심이며, 복잡한 조인이나 조건부 검색보다는 키를 통한 빠른 조회와 저장에 최적화되어 있다.

* 컬럼 패밀리 저장소: Apache Cassandra는 고유한 CQL을 사용한다. CQL은 문법적으로 SQL과 유사하게 보이도록 설계되어 학습 곡선을 낮췄지만, 내부 아키텍처의 차이로 인해 조인이나 서브쿼리와 같은 일부 관계형 기능은 지원하지 않는다.

* 그래프 데이터베이스: Neo4j는 그래프 패턴 매칭에 특화된 선언적 질의 언어인 Cypher를 사용한다. 노드, 관계, 속성을 ASCII-art 형태의 직관적인 구문으로 표현하여, 예를 들어 (a:Person)-[:KNOWS]->(b:Person)과 같이 특정 관계를 가진 엔티티를 쉽게 찾을 수 있다.

이러한 NoSQL 질의 언어들의 공통적인 특징은 대부분 특정 데이터 모델과 저장 구조에 밀접하게 결합되어 있다는 점이다. 따라서 범용성보다는 해당 시스템의 성능 특성과 데이터 구조를 최대한 활용하는 데 초점이 맞춰져 있다. 또한, 많은 NoSQL 질의 인터페이스가 RESTful API나 특정 프로그래밍 언어용 클라이언트 라이브러리를 통해 제공되기도 한다.

원자성은 트랜잭션이 더 이상 분해할 수 없는 하나의 작업 단위로 처리되어야 함을 의미한다. 이 속성에 따르면, 트랜잭션을 구성하는 모든 연산은 완전히 성공하거나, 아니면 전혀 실행되지 않은 상태로 되돌려져야 한다. 부분적인 성공은 허용되지 않는다.

예를 들어, 은행 계좌 이체 트랜잭션은 '출금'과 '입금'이라는 두 개의 연산으로 구성된다. 원자성이 보장되지 않으면, 출금 연산만 성공하고 입금 연산이 실패하는 상황이 발생할 수 있다. 이는 자금이 사라지는 심각한 데이터 불일치를 초래한다. 원자성은 이러한 상황을 방지하여, 두 연산이 모두 성공적으로 완료되거나, 실패할 경우 출금 연산조차 원래 상태로 롤백되도록 한다.

DBMS는 일반적으로 커밋과 롤백 명령을 통해 원자성을 구현한다. 커밋은 트랜잭션의 모든 변경 사항을 최종적으로 데이터베이스에 반영하는 작업이다. 반면, 트랜잭션 실행 중 오류가 발생하면 롤백이 수행되어, 트랜잭션이 시작되기 전의 상태로 모든 변경 사항을 취소한다. 이를 통해 'All-or-Nothing'의 원칙이 지켜진다.

일관성은 트랜잭션이 데이터베이스의 사전 정의된 규칙과 제약 조건을 위반하지 않는 상태로 데이터베이스를 한 일관성 상태에서 다른 일관성 상태로 이동시킴을 보장하는 속성이다. 이는 ACID 속성 중 하나로, 트랜잭션의 실행 전후로 데이터베이스가 논리적으로 올바른 상태를 유지해야 함을 의미한다.

데이터베이스의 일관성은 무결성 제약 조건에 의해 정의된다. 이러한 제약 조건에는 기본키, 외래키, 고유 제약, 널 제약, 체크 제약 등이 포함된다. 예를 들어, 계좌 이체 트랜잭션에서 출금 계좌의 잔액과 입금 계좌의 잔액의 합계는 트랜잭션 시작 전과 완료 후에 동일해야 한다. 트랜잭션이 이러한 비즈니스 규칙을 위반한다면, 일관성 속성은 트랜잭션이 실패하고 데이터베이스가 원래 상태로 롤백되도록 요구한다.

일관성은 주로 애플리케이션(트랜잭션을 작성하는 코드)과 DBMS의 무결성 제약 조건 검사 기능이 공동으로 책임진다. 애플리케이션은 비즈니스 로직을 통해 올바른 상태 전이를 보장해야 하며, DBMS는 선언된 제약 조건을 자동으로 검증하여 이를 지원한다. 따라서 일관성은 단순히 데이터의 형식적 정확성을 넘어, 데이터가 현실 세계의 의미를 올바르게 반영하도록 하는 핵심 개념이다.

고립성은 트랜잭션이 동시에 실행되는 다른 트랜잭션의 중간 상태로부터 격리되어, 마치 순차적으로 실행되는 것처럼 동작하도록 보장하는 속성이다. 이는 여러 트랜잭션이 동시에 같은 데이터에 접근하고 변경할 때 발생할 수 있는 문제를 방지한다. 주요 문제로는 더티 리드, 반복 불가능한 읽기, 팬텀 읽기 등이 있다.

고립성의 수준은 시스템에 따라 조정될 수 있으며, 일반적으로 네 가지 표준 격리 수준으로 정의된다. 격리 수준이 높을수록 데이터의 일관성은 강화되지만, 동시성과 성능은 저하되는 트레이드오프 관계가 있다. 일반적인 격리 수준은 다음과 같다.

가장 높은 수준인 직렬 가능성은 트랜잭션들을 순차적으로 실행한 결과와 동일한 결과를 보장하지만, 동시 처리 성능에 큰 제약을 준다. 대부분의 상용 RDBMS는 기본 격리 수준으로 READ COMMITTED 또는 REPEATABLE READ를 사용한다. 고립성을 구현하는 주요 기법으로는 락킹과 타임스탬프 순서화가 있으며, 이를 통해 데이터 접근에 대한 충돌을 관리하고 일관된 뷰를 제공한다.

지속성은 트랜잭션이 성공적으로 완료되면, 그 트랜잭션에 의해 수행된 모든 데이터 변경 사항이 영구적으로 저장되어야 함을 보장하는 속성이다. 시스템 장애(예: 정전, 하드웨어 고장, 운영체제 충돌)가 발생하더라도, 커밋된 트랜잭션의 결과는 손실되지 않고 데이터베이스에 남아 있어야 한다. 이는 데이터의 신뢰성과 영구성을 위한 핵심적인 요구 사항이다.

지속성을 구현하기 위해 DBMS는 주로 로그 기반 회복 기법을 사용한다. 이 기법에서는 모든 데이터 변경 연산(갱신, 삽입, 삭제)이 실제 디스크의 데이터베이스에 반영되기 전에, 먼저 안정적인 저장 장치(주로 디스크)에 기록된 로그 파일에 그 내용이 기록된다. 이 원칙을 WAL(Write-Ahead Logging)이라고 한다[5]. 시스템 장애 후 재시작 시, DBMS는 이 로그 파일을 검사하여 커밋되었지만 데이터베이스에 완전히 반영되지 않은 트랜잭션은 재실행(Redo)하고, 커밋되지 않은 트랜잭션의 변경 사항은 취소(Undo)함으로써 데이터베이스를 일관된 상태로 복구한다.

따라서 지속성은 단순히 데이터를 디스크에 저장하는 것을 넘어서, 체계적인 로깅과 회복 프로토콜을 통해 보장된다. 이는 ACID 트랜잭션의 다른 속성인 원자성, 일관성, 고립성이 유지된 상태의 최종 결과가 영구히 보존되도록 하는 최종적인 안전장치 역할을 한다.

락킹 기법은 DBMS에서 여러 트랜잭션이 동시에 같은 데이터에 접근할 때 발생할 수 있는 충돌을 방지하고 고립성을 보장하기 위한 핵심적인 동시성 제어 방법이다. 기본 원리는 트랜잭션이 데이터 항목(예: 테이블의 행)을 읽거나 수정하기 전에 해당 항목에 대한 잠금(락)을 요청하고 획득하도록 하는 것이다. 잠금을 획득한 트랜잭션만이 그 데이터를 조작할 수 있으며, 작업이 끝나면 잠금을 해제하여 다른 트랜잭션이 사용할 수 있게 한다.

잠금에는 주요한 두 가지 모드가 존재한다. 공유 잠금은 데이터를 읽기만 할 때 사용되며, 여러 트랜잭션이 동시에 같은 데이터 항목에 대한 공유 잠금을 보유하는 것이 허용된다. 배타 잠금은 데이터를 쓰거나 수정할 때 필요하며, 한 트랜잭션이 배타 잠금을 보유하면 다른 트랜잭션은 그 데이터에 대한 공유 또는 배타 잠금을 모두 획득할 수 없다. 이 규칙은 '더러운 읽기'와 같은 문제를 방지한다.

잠금 기법을 사용할 때 주의해야 할 주요 문제는 교착 상태이다. 두 개 이상의 트랜잭션이 각자 보유한 잠금 때문에 상대방이 필요한 잠금을 무한정 기다리는 상태에 빠질 수 있다. DBMS는 교착 상태를 탐지하고, 희생자를 선정하여 롤백하는 방식으로 해결하거나, 트랜잭션이 시작될 때 모든 필요한 잠금을 한꺼번에 요청하는 예방 방식을 사용하기도 한다.

락킹의 세부 정책은 잠금의 단위(행, 페이지, 테이블 등), 잠금 유지 시간, 잠금 호환성 매트릭스에 따라 달라진다. 대부분의 상용 RDBMS는 이러한 락킹 메커니즘을 내부적으로 구현하여 개발자에게 투명하게 동시성 제어를 제공한다.

타임스탬프 순서화는 동시성 제어를 위한 비락킹 기법 중 하나이다. 이 기법에서는 각 트랜잭션이 시스템에 진입할 때 고유한 타임스탬프를 부여받는다. 타임스탬프는 일반적으로 트랜잭션의 시작 시간을 기준으로 생성되며, 트랜잭션 간의 시간적 순서를 결정하는 역할을 한다. 기본 원칙은 트랜잭션의 실행 순서가 타임스탬프의 순서와 일치하도록 보장하는 것이다. 이를 통해 데이터베이스의 직렬 가능성을 유지하면서도 교착 상태가 발생하지 않는다는 장점을 가진다.

이 기법의 핵심은 각 데이터 항목에 대해 두 개의 타임스탬프 값을 기록하고 비교하는 데 있다. 각 데이터 항목은 마지막으로 읽은 트랜잭션의 타임스탬프를 나타내는 읽기 타임스탬프(R-timestamp)와 마지막으로 쓴 트랜잭션의 타임스탬프를 나타내는 쓰기 타임스탬프(W-timestamp)를 유지한다. 트랜잭션이 데이터를 읽거나 쓰려고 할 때, 자신의 타임스탬프와 데이터 항목의 타임스탬프 값을 비교하여 연산의 허용 여부를 결정한다.

표와 같이, 읽기 연산을 요청할 때 트랜잭션의 타임스탬프(TS)가 데이터의 쓰기 타임스탬프보다 작으면, 이는 미래의 값(더 늦은 타임스탬프를 가진 트랜잭션에 의해 기록된 값)을 읽으려는 시도로 간주되어 연산이 거부된다. 쓰기 연산의 경우도 유사하게, 자신보다 늦게 읽거나 쓴 트랜잭션이 이미 존재하면 연산이 거부된다. 연산이 거부된 트랜잭션은 중단되고 새로운 타임스탬프와 함께 재시작된다.

타임스탬프 순서화는 락을 사용하지 않아 교착 상태를 방지할 수 있지만, 트랜잭션 재시작으로 인한 오버헤드가 발생할 수 있다. 또한 다중 버전 동시성 제어(MVCC)와 같은 더 발전된 기법의 기반이 되기도 한다. 이 기법은 읽기 작업이 많은 환경이나 트랜잭션 충돌이 빈번하지 않은 경우에 유용하게 적용된다.

로그 기반 회복은 DBMS에서 트랜잭션의 원자성과 지속성을 보장하기 위해 시스템 로그를 활용하는 주요 회복 기법이다. 이 기법은 데이터베이스에 대한 모든 변경 사항을 시간 순서대로 로그 파일에 기록해 두고, 시스템 장애 발생 시 이 로그를 이용해 데이터베이스를 일관된 상태로 복구한다.

로그 기록은 일반적으로 WAL (Write-Ahead Logging) 프로토콜을 따른다. 이 프로토콜에 따르면, 트랜잭션이 데이터베이스 자체를 수정하기 전에 반드시 해당 변경에 대한 로그 레코드를 안정적인 저장 장치에 먼저 기록해야 한다[6]. 주요 로그 레코드 유형으로는 트랜잭션 시작을 나타내는 <T_i start>, 갱신 내용을 기록하는 <T_i, X, V1, V2>(트랜잭션 T_i가 데이터 항목 X를 값 V1에서 V2로 변경), 트랜잭션 커밋을 나타내는 <T_i commit>, 그리고 트랜잭션 중단을 나타내는 <T_i abort>가 있다.

장애 발생 후 시스템 재시작 시, 회복 관리자는 로그 파일을 스캔하며 두 가지 주요 절차를 실행한다. 첫째는 재실행(Redo) 절차로, 커밋된 트랜잭션의 모든 갱신 사항을 로그 기록 순서대로 다시 적용하여 지속성을 보장한다. 둘째는 취소(Undo) 절차로, 장애 발생 시점에 완료되지 않은(커밋 또는 중단 로그 레코드가 없는) 트랜잭션들의 갱신 사항을 역순으로 원래 값으로 되돌려 원자성을 보장한다. 이를 효율적으로 수행하기 위해 체크포인트 기법이 함께 사용되는 경우가 많다.

로그 기반 회복은 구현이 비교적 단순하고 강력한 장애 복구 능력을 제공한다는 장점이 있다. 그러나 모든 변경 사항을 로깅해야 하므로 시스템에 일정한 오버헤드가 발생하며, 로그 파일이 매우 커질 수 있다는 단점도 존재한다.

체크포인트는 DBMS의 회복 기법 중 하나로, 시스템 장애 발생 시 로그 전체를 처음부터 재수행하지 않고, 특정 시점부터만 재수행하거나 취소함으로써 회복 시간을 단축하는 기법이다. 체크포인트를 설정하는 시점에는 현재 메모리(버퍼)에 있는 모든 변경된 데이터 페이지를 안정적인 저장 장치(디스크)에 강제로 기록하고, 이 정보를 로그 파일에도 함께 기록한다. 이렇게 생성된 체크포인트 레코드는 시스템이 마지막으로 일관된 상태를 가졌던 지점을 표시한다.

체크포인트 수행 절차는 일반적으로 다음과 같은 단계로 이루어진다.

1. 현재 실행 중인 모든 트랜잭션의 목록을 기록한다.

2. 모든 수정된 버퍼 페이지를 디스크에 물리적으로 기록한다.

3. 로그 파일에 <CHECKPOINT> 레코드를 기록한다.

장애가 발생했을 때, 회복 관리자는 로그 파일을 역방향으로 검색하여 가장 최근의 체크포인트를 찾는다. 체크포인트 이후에 시작된 트랜잭션만 재수행(REDO)하거나, 체크포인트 시점에 이미 활성 상태였지만 완료되지 않은 트랜잭션은 취소(UNDO)하는 작업을 수행한다. 이 방법은 체크포인트 이전에 커밋된 트랜잭션의 변경 사항은 이미 디스크에 기록되었음을 보장하므로, 로그의 처음부터 전체 재수행할 필요가 없게 만든다.

체크포인트의 주기는 시스템 성능과 회복 시간 사이의 트레이드오프를 결정한다. 체크포인트를 너무 자주 수행하면 디스크 I/O 부하가 증가하여 일반적인 처리 성능이 저하될 수 있다. 반대로, 체크포인트 간격이 너무 길면 장애 시 처리해야 할 로그의 양이 많아져 회복 시간이 길어지는 단점이 있다. 따라서 시스템의 안정성 요구사항과 성능 목표에 따라 적절한 체크포인트 주기를 설정하는 것이 중요하다.

인덱싱은 데이터베이스의 성능을 최적화하기 위한 핵심 기법 중 하나이다. 데이터베이스 테이블에서 특정 데이터를 빠르게 찾기 위해 별도의 자료 구조인 인덱스를 생성하고 관리하는 과정을 의미한다. 책의 색인과 유사한 역할을 하여, 전체 데이터를 순차적으로 검색(풀 테이블 스캔)하지 않고도 효율적으로 원하는 레코드의 위치를 찾아낼 수 있다.

인덱스는 일반적으로 B-트리나 B+트리와 같은 균형 트리 구조를 사용하여 구현된다. 이 구조는 데이터의 삽입, 삭제, 검색 연산을 로그 시간에 처리할 수 있도록 보장한다. 인덱스를 생성할 때는 하나 이상의 테이블 컬럼을 지정하며, 이를 인덱스 키라고 부른다. 인덱스는 테이블과 별도로 저장되지만, 물리적으로 테이블의 레코드 위치를 가리키는 포인터를 포함하고 있다.

인덱싱은 검색 속도를 획기적으로 향상시키지만, 무분별한 사용은 오히려 성능을 저하시킬 수 있다. 인덱스 자체도 저장 공간을 차지하며, 데이터가 추가, 수정, 삭제될 때마다 인덱스 구조도 함께 갱신되어야 하기 때문에 오버헤드가 발생한다[7]. 따라서 자주 검색 조건으로 사용되지만, 변경 빈도는 상대적으로 낮은 컬럼을 신중하게 선정하여 인덱스를 생성하는 것이 중요하다. 데이터베이스 관리 시스템의 질의 최적화기는 사용 가능한 인덱스를 평가하여 가장 효율적인 데이터 접근 경로를 선택하는 역할을 한다.

질의 최적화는 DBMS의 질의 처리기가 사용자가 제출한 SQL 질의를 가장 효율적으로 실행할 수 있는 계획을 선택하는 과정이다. 동일한 결과를 반환하는 여러 실행 경로 중에서 예상 비용(주로 디스크 입출력 및 CPU 시간)이 가장 낮은 경로를 찾는 것이 핵심 목표이다. 이 과정은 질의 처리의 성능을 결정하는 가장 중요한 요소 중 하나이다.

질의 최적화기는 일반적으로 논리적 최적화와 물리적 최적화 단계로 나뉜다. 논리적 최적화는 질의의 내부 표현(예: 관계 대수 표현식)을 변환하여 효율성을 높인다. 대표적인 기법으로는 불필요한 연산 제거, 조인 순서 변경, 조건식의 이동 및 단순화 등이 있다. 물리적 최적화는 논리적 계획을 실제 데이터 접근 방법(예: 어떤 인덱스를 사용할지, 조인 알고리즘을 어떻게 선택할지)에 매핑한다. 이를 위해 최적화기는 시스템 카탈로그에 저장된 테이블 크기, 인덱스 통계 정보 등을 활용하여 각 실행 계획의 비용을 추정한다.

최적화의 효율성은 통계 정보의 정확성에 크게 의존한다. 따라서 현대 DBMS는 주기적으로 테이블과 인덱스에 대한 통계 정보(레코드 수, 컬럼 값의 분포, 인덱스 깊이 등)를 수집하고 갱신한다. 비용 기반 최적화는 이러한 통계를 바탕으로 다양한 실행 계획의 예상 비용을 계산하고 비교한다. 간단한 질의의 경우 가능한 모든 계획을 탐색할 수 있지만, 여러 테이블이 복잡하게 조인되는 질의의 경우 탐색 공간이 너무 커지므로 휴리스틱이나 동적 프로그래밍 기법을 사용하여 최적에 가까운 계획을 합리적인 시간 내에 찾는다.

결과적으로, 질의 최적화는 사용자가 데이터 접근 방법의 세부 사항을 고려하지 않고 선언적인 SQL 문만 작성해도 DBMS가 자동으로 고성능의 실행 코드를 생성할 수 있게 하는 핵심 메커니즘이다.