이미지 출처: Dall-E
데이터와 파일
데이터
컴퓨터 관점에서 보면, 데이터는 결국 수많은 비트들의 집합일 뿐 입니다. 하지만 이러한 비트들이 어떤 의미를 지니고 특정 정보를 표현할 수 있다면, 우리는 그것을 데이터라고 부르게 됩니다.
파일
특히 데이터가 휘발되지 않고 영구적으로 보관될 수 있도록 "파일"이라는 개념이 등장합니다. 파일은 데이터를 스토리지(예: 디스크, SSD)에 저장하여 컴퓨터 전원이 꺼지더라도 데이터가 유지될 수 있도록 합니다.
파일 시스템
"점점 늘어나는 파일들을 효율적으로 관리하려면?"
운영체제는 여러 파일을 효율적으로 관리하기 위해 체계적인 시스템을 구축하는데, 이를 파일 시스템이라고 합니다.
저희가 흔히 컴퓨터에 폴더안에 하위 폴더나 파일을 생성하는 식으로 데이터를 관리하듯이, 파일 시스템도 주로 트리 구조를 사용하여 디렉터리와 하위 디렉터리를 관리하며, 파일 간의 관계를 유지합니다.
(참고: 디렉터리도 실제로는 파일로 간주됩니다. 디렉터리는 하위 파일 및 디렉터리의 메타데이터를 담고 있다는 점에서 특별한 타입의 파일로 분류될 뿐이죠.)
데이터베이스의 등장
"파일 시스템만으로 데이터를 관리하기 어려운 이유"
하지만 API 서버처럼 응용 프로그램 관점에서는 파일 시스템만으로 데이터를 다루기에는 아쉬운 점이 있습니다.
데이터 중복
응용 프로그램마다 여러 파일에 중복된 데이터가 저장되기 쉽습니다. 이는 공간을 비효율적으로 사용할 뿐만 아니라, 데이터 관리 차원에서도 번거로움이 발생합니다.
일관성 부족
여러 데이터가 논리적으로 연결된 경우(예: 회원 데이터와 구매 데이터), 데이터 변경 시 이러한 논리적 관계를 일관되게 유지하기 어렵습니다.
효율성 문제
특정 조건에 맞는 데이터를 빠르게 검색하거나, 여러 데이터를 특정 조건에 맞게 조합하거나 수정하는 등 복잡한 연산을 수행하기 어렵습니다.
따라서 파일시스템처럼 스토리지에 데이터를 물리적으로 저장하고 관리하기 위한 측면이 아닌,
보다 응용 프로그램의 입장에서 데이터들을 효율적으로 사용하기 위한 시스템이 필요했습니다. 이때, 등장한 것이 데이터베이스 관리 시스템(DBMS)입니다.
그리고 DBMS에 의해 관리되는 데이터들의 집합을 "데이터베이스"라고 부릅니다.
DBMS 목적
DBMS는 응용 프로그램이 데이터들을 보다 안정적이고 효율적으로 관리할 수 있도록 합니다. 이를 위해서 DBMS는 다음과 같은 목적을 가집니다.
-
데이터의 중복 최소화
데이터 중복을 줄여 저장 공간을 절약하고, 데이터 일관성을 유지합니다. -
일관성 유지
전체적인 관점에서 데이터간의 일관성을 보장하기 위한 기능들을 제공합니다.
(예: 트랜잭션) -
무결성 유지
데이터의 무결성(integrity)는 데이터베이스 내의 데이터가 특정 조건들을 준수한 형태로 잘 관리되고 있는지를 의미합니다. 제약 조건 등 지켜져야 하는 규칙들을 어긴 데이터들이 존재하지 않도록 합니다. -
독립성 유지
데이터베이스의 논리적 및 물리적 변화가 DB와 통신하는 응용 프로그램(웹 어플리케이션 서버, 데이터 분석 툴 등 DBMS와 통신하는 다른 소프트웨어 프로그램)에는 영향을 주지 않도록 합니다.
이를 테면, 테이블을 추가하거나 컬럼을 삭제하거나, 데이터가 저장되는 디스크가 바뀌는 등의 DBMS와 관련된 변화가 응용 프로그램에 영향을 주지 않음으로서 독립성을 유지합니다. 이는 DBMS의 확장성과 유연성이 높여줍니다.
스키마
데이터베이스는 위와 같은 목적을 달성하기 위해, "스키마"라는 개념을 사용합니다. 스키마는 데이터의 구조와 제약 조건들을 정의해둔 것 입니다.
예를 들어, 이 스키마는 "회원가입 유저"에 대한 정보를 저장할 것이고, 이를 위해 회원 ID, 회원 이메일, 회원 비밀번호가 관리될 것이고...
각 정보들은 어떤 데이터 타입을 가지며...
등등을 미리 설계해두는 것입니다.
데이터베이스의 3단계 구조와 스키마
DBMS의 주요 목적 중 하나인 '데이터 독립성'을 위하여,
미국 표준화 기관인 ANSI/SPARC에서는 3단계 구조로 나눈 데이터베이스 아키텍처를 제안하였습니다. 이는 데이터베이스를 바라보는 관점에 따라 계층을 나눈 것입니다.
외부 사용자 관점 - 외부 스키마(External Schema)
외부 사용자의 관점에서 바라보는 데이터베이스입니다. 사용자는 데이터베이스의 전체 데이터를 보지 않고, 필요한 부분만 바라보게 됩니다.
예를 들어, 쇼핑몰 서비스가 있다고 할때 고객 분석팀에서 필요한 데이터와 배송팀에서 원하는 데이터는 다를 것 입니다. 이처럼 사용자에 따라 외부 스키마는 달라질 수 있습니다.
전체적인 논리 구조 관점 - 개념 스키마(Conceptual Schema)
전체적인 관점에서 데이터간의 논리적 구조와 연관 관계들을 고려한 구조입니다. 이를테면, 고객 데이터와 배송 데이터는 조직 전체의 관점에서 보면 독립적인 데이터들이 아닙니다. 배송 데이터에는 어떤 고객에 대한 배송건인지에 대한 정보를 담고 있어야 하며, 이런 관계에 따라 제약 조건들이 생겨나게 됩니다. 또한, 고객 데이터에는 아무나 접근할 수 없고, 특정 권한을 가진 사용자만 접근할 수 있도록 하는 등의 보안적인 규칙을 정의하는 것도 개념 스키마에서 반영됩니다.
내부 스키마(Internal Schema)
데이터가 실제 저장되는 물리적인 구조 관점에서의 스키마입니다. 필드 크기 등의 데이터의 저장 방법, 인덱스 구조, 레코드 접근 방법 등을 나타냅니다. 내부 스키마는 물리적인 저장 측면에서의 효율성과 성능 최적화를 위한 설계를 제공합니다.
데이터베이스는 이러한 각 구조에서의 변경이 다른 구조에 영향을 주지 않도록 독립성을 보장합니다. 이를 테면, 고객 테이블에 휴대폰 번호 컬럼이 추가되는 것은 논리적인 설계에서의 변동사항입니다. 이 변경이 물리적인 설계에 영향을 주거나, 사용자가 고객 테이블에 접근하는 과정에서의 추가적인 수정을 요구하지 않습니다.
반대로, 실제 데이터가 SSD에서 저장되던 것을 HDD로 옮긴다거나 데이터를 저장하던 자료구조가 바뀐다하더라도 응용 프로그램단에 영향을 주지 않습니다.
관계형 데이터베이스
RDBMS
데이터베이스 관리 시스템은 어떠한 규칙과 체계를 가지고 데이터를 관리해야 합니다. 이때, 유용하게 쓰일 수 있는 규칙 중 하나는 비슷한 데이터끼리 테이블을 구성하고, 이 테이블간의 관계를 기반으로 관리하는 것입니다. 이러한 종류의 DBMS를 관계형 데이터베이스, 즉 RDBMS(Relational Database Management System)라고 합니다.
RDBMS는 쉽게 생각하면, 엑셀처럼 열과 행으로 이루어진 표 형식으로 데이터를 관리합니다. 다만, 이를 RDMBS에서는 이러한 표를 '테이블'이라고 하며, 이런 테이블에 대한 설계도를 "스키마"라고 합니다. 이를 테면, 회원 테이블은 회원 아이디, 회원 이메일, 회원 비밀번호라는 컬럼(=열)로 구성된다라는 식의 설계를 미리 정해두는 것입니다. 테이블과 테이블은 서로 관계를 가질 수 있습니다. 예를 들면, 쇼핑몰 서비스에서 구매 데이터를 저장하는 테이블이 있다고 할때,
구매자는 결국 쇼핑몰의 회원일 것이므로, 회원 테이블에 저장된 회원 데이터와 연관될 수 있습니다.
Relation Schema vs Relation Instance
RDBMS에서 스키마, 즉 테이블에 대한 구조를 나타내는 것을 relational schema라고 합니다. RDBMS에서는 각 테이블이 하나의 릴레이션을 의미하고, 릴레이션 안에는 여러 속성(=컬럼)들이 존재합니다.
그리고, 테이블에는 구조에 맞게 실제 데이터들이 존재할 수 있는데 이를 릴레이션 인스턴스라고 합니다.
Relation Degree
릴레이션 차수는 쉽게 말해 릴레이션 스키마에 속한 속성의 수 입니다.
다시 말해, 테이블 내의 컬럼의 수 입니다. 컬럼 수가 n개 있다면, 릴레이션 차수는 n입니다.
가령 User(UserId, UserEmail)이라는 릴레이션 스키마는 2라는 차수를 가집니다. 컬럼이 많을수록, 높은 차수를 가지고 이는 릴레이션 스키마의 구조적인 복잡도를 의미하기도 합니다.
Cardinality
카디널리티는 릴레이션에 포함된 인스턴스의 개수입니다.즉 테이블에 속한 데이터의 개수입니다. 데이터의 양을 의미하는 개념입니다.
데이터 무결성
앞서 살펴본 DBMS의 주요 특징 중 하나는 데이터 무결성입니다.
데이터 무결성은 데이터들을 체계적으로 관리하기 위해, 지켜져야 하는 조건들을 미리 만들어두고 이를 준수한 데이터들만 존재하도록 합니다.
여기서 "지켜져야 하는 조건"은 주로 데이터와 데이터간의 관계들로 풀어 설명할 수 있는데요. A라는 데이터가 존재하려면, B라는 데이터가 먼저 있어야 한다와 같은 제약조건입니다.
이런 제약 조건들을 관리하기 위해서, 관계형 데이터베이스에는 '키(key)'라는 개념이 등장합니다. 키의 종류에 대해 자세히 살펴보겠습니다.
기본키(Primary Key)
테이블 내의 각 데이터를 식별하는데 쓰이는 컬럼입니다. 이는 식별자의 역할을 가지므로, 각 데이터별로 고유한 값을 가지게 됩니다.
대리키(Surrogate Key)
테이블내의 기본키로 사용하기 위해, 데이터와는 크게 관련이 없는 키를 생성한 경우 이를 대리키라고 할 수 있습니다. 흔히, auto increment로 각 데이터가 생성될 때마다 1씩 값이 증가하는 ID 컬럼어 기본키로 사용하기도 하는데 이 경우가 대리키에 해당한다고 볼 수 있겠습니다.
외래키(Foreign Key)
다른 테이블의 기본키를 참조하는 속성(컬럼) 입니다. 외래키를 통해서, 각 테이블간의 관계를 추적할 수 있습니다. 예를 들어, 수강자 테이블에서 수강자에 대한 정보는 재학생 테이블의 id값을 참조할 수 있는데 이럴 경우 외래키가 사용됩니다.
데이터 무결성의 종류
DBMS의 목적은 데이터들을 효율적이고 안정적으로 관리하는 것이라고 했습니다. 이를 위해서는 지켜져야 하는 체계와 규칙들이 있을 것이고, 이러한 규칙들이 잘 준수될 수 있도록 하는 것이 무결성입니다. 무결성, 즉 지켜져야 하는 규칙들은 여러 측면에서 필요하게 됩니다. 이에 따른 무결성 종류를 살펴보겠습니다.
도메인 무결성 (Domain Integrity)
특정 속성(컬럼)에 대해, 준수해야 하는 규칙을 의미합니다. 예를 들면, 컬럼의 데이터 형식(VARCHAR, INTGER 등), NULL값 허용 여부 등이 있습니다.
개체 무결성 (Entity Integrity)
테이블에서 각 데이터(행)가 고유하게 식별 되로록 하는 것입니다. 이를 위해서는
기본키가 각 데이터(행)별로 고유한 값을 가지고, 각 행을 잘 구별 시키도록 하는 기본키 제약 조건이 필요합니다. 이를 테면, 각 기본키는 고유해야 하며, NULL값을 가질 수 없습니다.
참조 무결성 (Referential Integrity)
외래키가 참조하고 있는 기본키가 유효함을 보장하는 것 입니다. 예를 들면, 참조하고 있는 기본키가 삭제되거나 수정될 수 있는데 이러한 상황에서 외래키 또한 삭제하거나 수정되도록 조치를 취할 수 있습니다. 이런 조건들을 미리 정의해둠으로써, 항상 유효한 키를 외래키가 참조할 수 있도록 하는 것 입니다.
Mysql, MariaDB
대표적인 RDBMS로, 오픈소스 데이터베이스 관리 시스템입니다. 사실 MariaDB는 Mysql 오라클에 인수되어 라이선스 관련 이슈가 생겨나면서, 기존 mysql 개발자들이 새롭게 만든 DBMS입니다. 그러다보니, Mysql과 MariaDB는 꽤나 비슷한 특징들을 공유하고 있습니다. 일반적으로 MariaDB가 조금 더 빠른 성능을 보이나, 보안이나 안정성 측면에서는 아무래도 Oracle에서 직접 관리되고 있는 Mysql이 더 높다고 인식되는 듯 합니다.
실무에서 Mysql, MariaDB를 모두 사용해봤었는데 사실상 큰 차이점을 느끼지는 못했습니다. 위에서 살펴본 RDBMS의 구성요소(예: 테이블, 속성, 키) 및 제약조건 등을 공통적으로 사용하고,
SQL이라는 같은 문법을 사용하다보니 더욱 비슷하게만 느껴졌던 것 같습니다.
제가 백엔드 엔지니어로서 맡았던 프로젝트들의 경우,
1) 일반 쇼핑몰처럼 유저/상품/결제/게시글 등의 관계형 데이터를 다루는 점
2) 특히, 제가 개발했던 관리자 서비스는 각 테이블간의 참조 관계를 기반으로, 테이블간의 데이터를 조합해서 보여줘야 하는 경우가 많았던 점(조건 기반 데이터 검색 및 필터링)
2) 추천 알고리즘이나 챗봇과 같은 유사성 기반의 검색이 필요한 기능이 없었던 점
등에서 RDBMS를 사용하는 것이 적합했다고 생각합니다. 특히, 백엔드 개발에서는 전체적인 구조를 파악하여 여러 서비스 도메인에서 사용되는 데이터간의 관계를 잘 정의하고 그 일관성을 유지하는 것이 중요했는데 이러한 측면에서 테이블 간의 제약 조건 등 RDBMS의 특성이 유용했다고 느꼈습니다.
Reference
