데이터베이스의 기본
데이터베이스(DB, DataBase)는 일정한 규칙, 규약을 통해 구조화되어 저장되는 데이터의 모음이다. 해당 데이터베이스를 관리, 제어하는 통합 시스템을 DBMS(DataBase Management System)라고 하며, 데이터베이스 안 데이터들은 특정 DBMS마다 정의된 쿼리 언어(query language)를 통해 삽입, 삭제, 수정, 조회 등을 수행할 수 있다. 데이터베이스는 실시간 접근과 공유가 가능하다.
데이터베이스 위에 DBMS가 있고 그 위에 응용 프로그램이 있으며, 이러한 구조를 기반으로 데이터를 주고받는다. 예를 들어 MySQL이라는 DBMS가 있고 그 위에 응용 프로그램에 속하는 Spring boot에서 해당 데이터베이스 안에 있는 데이터 관련 로직을 구축할 수 있는 것이다.
엔터티(Entity)
엔터티는 여러 개의 속성을 지닌 명사를 의미한다. 예를 들어 회원이라는 엔터티가 있다면, 회원의 이름, 아이디, 주소, 전화번호의 속성을 갖는다.
속성은 서비스 요구사항에 맞춰 정해진다. 예를 들어 주소라는 속성이 서비스 요구 사항과 무관한 속성이라면 주소라는 속성은 사라지게 된다.
약한 엔터티와 강한 엔터티
엔터티는 종속성에 따라 약한 엔터티와 강한 엔터티로 나뉜다. 예를 들어 A가 혼자서는 존재하지 못하고 B의 존재 여부에 따라 종속적이라면 A는 약한 엔터티이고 B는 강한 엔터티가 된다.
릴레이션(Relation)
릴레이션은 데이터베이스에서 정보를 구분하여 저장하는 기본 단위이다. 엔터티에 관한 데이터를 데이터베이스는 릴레이션 하나에 담아 관리한다.
회원이라는 엔터티가 데이터베이스에서 관리될 때는 릴레이션으로 변화한다. 릴레이션은 관계형 데이터베이스에서는 '테이블' 이라고 하며, NoSQL 데이터베이스에서는 '컬렉션' 이라고 한다.
테이블과 컬렉션
테이터베이스 종류는 크게 관계형 데이터베이스와 NoSQL 데이터베이스로 나눌 수 있다. 대표적인 관계형 데이터베이스인 MySQL과 대표적인 NoSQL 데이터베이스인 MongoDB를 예로 들면, MySQL의 구조는 레코드-테이블-데이터베이스로 이루어져 있고 MongoDB는 도큐먼트-컬렉션-데이터베이스로 이루어져 있다.
레코드가 쌓여 테이블이 되고 테이블이 쌓여 데이터베이스가 된다.
속성(Attribute)
속성은 릴레이션에서 관리하는 구체적이며 고유한 이름을 갖는 정보이다. 예를 들어 '차' 라는 엔터티의 속성을 뽑아 보면 차 넘버, 바퀴 수, 색깔, 차종 등이 있다. 이 중에서 서비스 요구 사항을 기반으로 관리해야 할 필요가 있는 속성들만 엔터티의 속성이 된다.
도메인(Domain)
도메인이란 릴레이션에 포함된 각각의 속성들이 가질 수 있는 값의 집합을 말한다. 예를 들어 성별이라는 속성이 있다면 이 속성이 가질 수 있는 값은 {남, 여}라는 집합이 된다.
필드와 레코드
[member]
| name | ID | address | phonenumber |
회원이라는 엔터티는 member라는 테이블로 속성인 이름, 아이디 등을 가지고 있으며 name, ID, address 등의 필드를 가진다. 이 테이블에 쌓이는 행(row) 단위의 데이터를 레코드라고 한다. 또한, 레코드를 튜플이라고도 한다.
필드 타입
필드는 타입을 갖는다. 예를 들어 이름은 문자열이고 전화번호는 숫자이다. 이러한 타입들은 DBMS마다 다르다. 아래 타입은 모두 MySQL 기준이다.
숫자 타입
숫자 타입으로는 TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 등이 있다.
날짜 타입
날짜 타입으로는 DATE, DATETIME, TIMESTAMP 등이 있다.
DATE
날짜 부분은 있지만 시간 부분은 없는 값에 사용된다. 지원되는 범위는 1000-01-01 ~ 9999-12-31dlek. 3바이트 용량을 가진다.
DATETIME
날짜 및 시간 부분을 모두 포함하는 값에 사용된다. 지원되는 범위는 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59이다. 8바이트의 용량을 가진다.
TIMESTAMP
날짜 및 시간 부분을 모두 포함하는 값에 사용된다. 1970-01-01 00:00:01 ~ 2038:01-19 03:14:07까지 지원한다. 4바이트의 용량을 가진다.
문자 타입
문자 타입으로는 CHAR, VARCHAR, TEXT, BLOB, ENUM, SET이 있다.
CHAR와 VARCHAR
CHAR 또는 VARCHAR 모두 그 안에 수를 입력해서 몇 자까지 입력할지 정한다. 예를 들어 CHAR(30)이라면 최대 30글자까지 입력할 수 있다.
CHAR는 고정 길이 문자열이며 길이는 0~255 사이의 값을 가진다. 레코드를 저장할 때 무조건 선언한 길이 값으로 '고정'해서 저장된다. 예를 들어 CHAR(100)으로 선언한 후 10글자를 저장해도 100바이트로 저장되게 된다.
VARCHAR는 가변 길이 문자열이다. 길이는 0~65,535 사이의 값으로 저장할 수 있으며, 입력된 데이터에 따라 용량을 가변시켜 저장한다. 예를 들어 VARCHAR(10000)으로 선언했음에도 10글자를 저장하면 10글자에 해당하는 바이트 + 길이기록용 1바이트로 저장하게 된다.
그렇기 때문에 CHAR의 경우 유동적이지 않은 길이를 가진 데이터의 경우 효율적이며, 유동적인 길이를 가진 데이터는 VARCHAR로 저장하는 것이 좋다.
TEXT와 BLOB
두 개의 타입 모두 큰 데이터를 저장할 때 쓰는 타입이다.
TEXT는 큰 문자열 저장에 주로 쓰며 주로 게시판의 본문을 저장할 때 쓴다.
BLOB은 이미지, 동영상 등 큰 데이터 저장에 쓴다. 그러나 보통은 아마존의 이미지 호스팅 서비스인 S3를 이용하는 등 서버에 필요한 파일을 올리고 파일에 관한 경로를 VARCHAR로 저장한다.
ENUM과 SET
ENUM과 SET은 모두 문자열을 열거한 타입이다.
ENUM은 ENUM('x-small', 'small', 'medium', 'large', 'x-large') 과 같은 형태로 쓰이며, 이 중에서 하나만 선택하는 단일 선택만 가능하고 ENUM 리스트에 없는 잘못된 값을 삽입하면 빈 문자열이 대신 삽입된다. ENUM을 이용하면 x-small 등이 0, 1 등으로 매핑되어 메모리를 적게 사용하는 이점을 얻는다. ENUM은 최대 65,535개의 요소들을 넣을 수 있다.
SET은 ENUM과 비슷하지만 여러 개의 데이터를 선택할 수 있고 비트 단위의 연산을 할 수 있으며 최대 64개의 요소만 넣을 수 있다는 점이 다르다.
ENUM이나 SET을 쓸 경우 공간적으로 이점을 볼 수 있지만 애플리케이션의 수정에 따라 데이터베이스의 ENUM이나 SET에서 정의한 목록을 수정해야 한다는 단점이 있다.
관계
데이터베이스에 테이블은 여러 개가 있고 이러한 테이블은 서로의 관계가 정의되어 있다. 이러한 관계를 관계화살표로 나타낸다.
1:1 관계
예를 들어 유저당 유저 이메일이 한 개씩 있다면, 이 경우 1:1 관계가 된다.
1:N 관계
예를 들어 한 유저당 여러 개의 상품을 장바구니에 넣을 수 있다면, 이 경우 1:N 관계가 된다. 물론 하나도 넣지 않는 0개의 경우도 있으니 0도 포함되는 Many-선택 화살표를 통해 표현해야 한다.
N:M 관계
예를 들어 학생과 강의의 관계를 정의하면, 학생도 강의를 많이 들을 수 있고 강의도 여러 명의 학생을 포함할 수 있다. 이 경우 N:M이 된다.
이 때 N:M은 테이블 두 개를 직접적으로 연결해서 구축하지 않고 1:N, 1:M이라는 관계를 갖는 테이블 두 개로 나눠서 설정한다.
키
테이블 간의 관계를 더 명확하게 하고 테이블 자체의 인덱스를 위해 설정된 장치로 기본키, 외래키, 후보키, 슈퍼키, 대체키가 있다.
슈퍼키는 유일성이 있고 그 안에 포함된 후보키는 최소성까지 갖춘 키이다. 후보키 중에서는 기본키로 선택되지 못한 키는 대체키가 된다. 유일성은 중복되는 값은 없으며, 최소성은 필드를 조합하지 않고 최소 필드만 써서 형성할 수 있는 것을 말한다.
기본키(Primary Key, PK)
유일성과 최소성을 만족하는 키로, 테이블의 데이터 중 고유하게 존재하는 속성이며 기본키에 해당하는 데이터는 중복되어서는 안된다.
| ID(pk) | name |
| 1 | 김씨 |
| 2 | 박씨 |
| 3 | 오씨 |
여기서 기본키는 ID가 된다. 물론 {ID, name}이라는 복합키를 기본키로 설정할 수 있지만 그렇게 되면 최소성을 만족하지 못한다.
기본키는 자연키와 인조키 중에 골라 설정한다.
자연키
예를 들어 유저 테이블을 만든다고 가정하면 주민등록번호, 이름, 성별 등의 속성이 있다. 이 중 이름, 성별 등은 중복된 값이 들어올 수 있으므로 부적절하고 남는 것은 주민등록번호이다. 이런 식으로 중복된 값들을 제외하며 중복되지 않는 것을 '자연스레' 뽑다가 나오는 키를 자연키라고 한다. 자연키는 언젠가는 변하는 속성을 가진다.
인조키
예를 들어 유저 테이블을 만든다고 가정하면 주민등록번호, 이름, 성별 등의 속성이 있다. 여기에 인위적으로 유저 아이디를 부여한다. 이를 통해 고유 식별자가 생긴다. 오라클은 sequence, MySQL은 auto increment 등으로 설정한다. 이렇게 인위적으로 생성한 키를 인좈키라고 한다. 자연키와는 대조적으로 변하지 않는다. 따라서 보통 기본키는 인조키로 설정한다.
외래키(Foreign Key, FK)
다른 테이블의 기본키를 그대로 참조하는 값으로 개체와의 관계를 식별하는 데 사용한다.
[client]
| ID | name |
| a_1 | 김씨 |
| a_2 | 박씨 |
[product]
| ID | user_id | name |
| PDT_0001 | a_1 | 아우디 |
| PDT_0002 | a_2 | 벤츠 |
외래키는 중복되어도 괜찮다. 표를 보면 client 테이블의 기본키인 ID가 product 테이블의 user_id라는 외래키로 설정될 수 있음을 보여준다. 또한, user_id는 a_1라는 값이 중복되는 것을 볼 수 있다.
후보키(Candidate Key)
기본키가 될 수 있는 후보들이며 유일성과 최소성을 동시에 만족하는 키이다.
대체키(Alternate Key)
후보키가 두 개 이상일 경우 어느 하나를 기본키로 지정하고 남은 후보키들이다.
슈퍼키(Super key)
각 레코드를 유일하게 식별할 수 있는 유일성을 갖춘 키이다.
ERD와 정규화 과정
ERD(Entity Relationship Diagram)는 데이터베이스를 구축할 때 가장 기초적인 뼈대 역할을 하며, 릴레이션 간의 관계를 정의한 것이다. 서비스를 구축한다면 가장 먼저 신경써야 할 부분이다.
ERD의 중요성
ERD는 시스템 요구사항을 기반으로 작성되며 이 ERD를 기반으로 데이터베이스를 구축한다. 데이터베이스를 구축한 후에도 디버깅 또는 비즈니스 프로세스 재설계가 필요한 경우에 설계도 역할을 담당하기도 한다.
하지만 ERD는 관계형 구조로 표현할 수 있는 데이터를 구성하는 데 유용할 수 있지만 비정형 데이터를 충분히 표현할 수 없다는 단점이 있다.
비정형 데이터는 비구조화 데이터로, 미리 정의된 데이터 모델이 없거나 미리 정의된 방식으로 정리되지 않은 정보이다.
비정형 데이터는 데이터 구조가 없어 비정형 데이터 자체만으로는 내용에 대한 질의 처리(query processing)를 할 수 없다. 따라서 데이터의 특징을 추출하여 반정형, 또는 정형 데이터로 변환하는 전처리(preprocessing)가 필요하다. 데이터 분석 또는 인공지능 모델의 개발 목적과 입력 데이터의 종류에 따라 매우 다양한 방법의 전처리를 사용한다. 텍스트 형태의 데이터는 전처리를 위해 자연어 처리(Natural Language Processing) 기법을 주로 사용한다. 동영상, 오디오, 사진 등 미디어 파일은 필터를 이용하여 노이즈(noise)를 제거하거나 데이터 범위를 변환하는 방법으로 전처리하며, 주로 기계 학습(ML: Machine Learning)을 위한 입력 데이터로 활용한다. 비정형 데이터는 지속적으로 생성되는 데이터 중 가장 큰 비중을 차지하고 있으며, 데이터가 생성되는 시간대의 다양한 사회적, 문화적, 공간적 현상들을 반영하고 있기 때문에 마케팅, 비즈니스 인텔리전스(BI) 등의 분야에서 매우 중요하다.
정규화 과정
정규화 과정은 릴레이션 간의 잘못된 종속 관계로 인해 데이터베이스 이상 현상이 일어나서 이를 해결하거나, 저장 공간을 효율적으로 사용하기 위해 릴레이션을 여러 개로 분리하는 과정이다.
데이터베이스 이상 현상이란 삽입 이상, 삭제 이상, 갱신 이상이 있다. 데이터를 삽입해야 하는데 하나의 필드 값이 NULL이 되면 안 되어서 삽입이 어렵거나 삭제할 때 필요한 데이터가 같이 삭제되거나 일부만 변경하여 데이터가 불일치하는 현상을 말한다.
정규화 과정은 정규형 원칙을 기반으로 정규형을 만들어가는 과정이며, 정규화된 정도는 정규형(NF, Normal Form)으로 표현한다. 기본 정규형인 제1정규형, 제2정규형, 제3정규형, 보이스/코드 정규형이 있고 고급 정규형인 제4정규형, 제5정규형이 있다.
정규형 원칙
정규형의 원칙이란 같은 의미를 표현하는 릴레이션이지만 좀 더 좋은 구조로 만들어야 하고, 자료의 중복성은 감소해야 하고, 독립적인 관계는 별개의 릴레이션으로 표현해야 하며, 각각의 릴레이션은 독립적인 표현이 가능해야 하는 것을 말한다.
제1정규형
릴레이션의 모든 도메인이 더 이상 분해될 수 없는 원자 값(automic value)만으로 구성되어야 한다. 릴레이션의 속성 값 중에서 한 개의 기본키에 대해 두 개 이상의 값을 가지는 반복 집합이 있어서는 안된다. 반복 집합이 있다면 제거해야 한다.
제2정규형
릴레이션이 제1정규형이며 부분 함수의 종속성을 제거한 형태이다.
부분 함수의 종속성 제거란 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속적인 것을 말한다.
{학번, 과목코드}를 기본키로 가지는 테이블에서 완전 종속된 학번 릴레이션과 {학번, 과목코드}에 따른 성적 릴레이션으로 분리된 거을 볼 수 있다.
이 때 동등한 릴레이션으로 분해해야 하고, 정보 손실이 발생하지 않는 무손실 분해로 분해되어야 한다.
제3정규형
제2정규형이고 기본키가 아닌 모든 속성이 이행적 함수 종속(transitive FD)을 만족하지 않는 상태를 말한다.
이행적 함수 종속
이행적 함수 종속이란 A->B와 B->C가 존재하면 논리적으로 A->C가 성립하는데, 이 때 집합 C가 집합 A에 이행적으로 함수 종속이 되었다고 한다.
예를 들어 {유저ID, 등급, 할인율}을 필드로 가진 테이블에서 유저ID에 따라 등급이 다르고 등급에 따라 할인율이 다르다면 할인율은 유저 ID에 이행적으로 함수 종속된 것이다. 따라서 {유저ID, 등급}, {등급, 할인율}로 분해해야 한다.
보이스/코드 정규형(BCNF)
보이스/코드 정규형은 제3정규형이고, 결정자가 후보키가 아닌 함수 종속 관계를 제거하여 릴레이션의 함수 종속 관계에서 모든 결정자가 후보키인 상태이다.
결정자는 함수 종속 관계에서 종속자(dependent)를 결정짓는 요소, 'X->Y'일 때 X는 결정자, Y는 종속자이다.
이렇게 정규형 과정을 거쳐 테이블을 나눈다고 해서 성능이 100% 좋아지는 것은 아니다. 성능이 좋아질 수도 나빠질 수도 있다. 테이블을 나누게 되면 어떠한 쿼리는 조인을 해야 하는 경우도 발생해서 오히려 느려질 수도 있기 때문에 서비스에 따라 정규화 또는 비정규화 과정을 진행해야 한다.
트랜잭션과 무결성
트랜잭션
트랜잭션은 데이터베이스에서 하나의 논리적 기능을 수행하기 위한 작업의 단위이며, 여러 개의 쿼리들을 하나로 묶는 단위를 말한다. 이에 대한 특징은 원자성, 일관성, 독립성, 지속성이 있으며 이를 한꺼번에 ACID 특징이라고 한다.
원자성(Atomicity)
all or nothing
원자성은 트랜잭션과 관련된 일이 모두 수행되었거나 되지 않았거나를 보장하는 특징이다. 예를 들어 트랜잭션을 커밋했는데, 문제가 발생하여 롤백하는 경우 그 이후에 모두 수행되지 않음을 보장하는 것이다.
만약 1000만원을 가진 김씨가 0원을 가진 박씨에게 500만 원을 이체한다면, 그 결과 김씨는 500만 원 박씨는 500만 원을 가진다. 해당 결과는 다음과 같은 operation 단위들로 이루어진 과정을 거친다.
1. 김씨의 잔고를 조회한다.
2. 김씨에게서 500만 원을 뺀다.
3. 박씨에게 500만 원을 넣는다.
1~3의 operation 중 데이터베이스 사용자는 이 세 가지의 과정을 볼 수도 참여할 수도 없다. 다만 과정이 끝난 이후의 상황인 김씨 500만 원, 박씨 500만 원인 상황만 보는 것이다.
여기서 이 작업을 '취소'한다고 했을 때 김씨는 다시 1000만 원, 박씨는 0원을 가져야 한다. 일부 operation만 적용된 김씨 500만 원, 박씨 0원이 되지 않는 것을 의미한다. 그래서 all or nothing인 것이다.
또한, 트랜잭션 단위로 여러 로직들을 묶을 때 외부 API를 호출하면 안된다. 만약 있다면 롤백이 일어났을 때 어떻게 해야 할 것인지에 대한 해결 방법이 있어야 하고 트랜잭션 전파를 신경 써서 관리해야 한다.
커밋과 롤백
커밋(commit)은 여러 쿼리가 성공적으로 처리되었다고 확정하는 명령어이다. 트랜잭션 단위로 수행되며 변경된 내용이 모두 영구적으로 저장되는 것을 말한다. "커밋이 수행되었다." 를 "하나의 트랜잭션이 성공적으로 수행되었다." 라고도 말한다.
하지만 에러나 여러 이슈로 트랜잭션 전으로 돌려야 하는 상황이 있다. 이 때 사용하는 것이 롤백(rollback)이다. 롤백이란 트랜잭션으로 처리한 하나의 묶음 과정을 일어나기 전으로 돌리는 일(취소)을 말한다.
이러한 커밋과 롤백 덕에 데이터 무결성이 보장된다. 또한, 데이터 변경 전에 변경 사항을 쉽게 확인할 수 있고 해당 작업을 그룹화할 수 있다.
트랜잭션 전파
트랜잭션을 수행할 때 커넥션 단위로 수행하기 때문에 커넥션 객체를 넘겨서 수행해야 한다. 하지만 이를 매번 넘겨주기가 어렵고 귀찮기도 하다. 이를 넘겨서 수행하지 않고 여러 트랜잭션 관련 메서드의 호출을 하나의 트랜잭션에 묶이도록 하는 것을 트랜잭션 전파라고 한다.
@Service
@Transactional(readOnly = true)
public class MemberService {
private final MemberRepository memberRepository;
public MemberService(MemberRepository memberRepository) {
this.memberRepository = memberRepository;
}
}
코드처럼 Spring 프레임워크에서는 @Transactional 애너테이션을 통해 여러 쿼리 관련 코드들을 하나의 트랜잭션으로 처리한다. 정상적으로 기능이 수행되면 트랜잭션을 커밋하고 예외가 발생하면 트랜잭션을 롤백한다.
일관성(Consistency)
일관성은 '허용된 방식'으로만 데이터를 변경해야 하는 것을 의미한다. 데이터베이스에 기록된 모든 데이터는 여러 가지 조건, 규칙에 따라 유효함을 가져야 한다. 예를 들어 김씨는 1000만 원이 있고 박씨는 0원이 있다면 박씨는 김씨에게 500만 원을 입금할 수 없다. 마이너스 통장을 제외하고 0원으로부터 500만 원이 나오는 것은 불가능하다는 제약이 있기 때문이다.
격리성(Isolation)
격리성은 트랜잭션 수행 시 서로 끼어들지 못하는 것을 말한다. 복수의 병렬 트랜잭션은 서로 격리되어 마치 순차적으로 실행되는 것처럼 작동되어야 하고, 데이터베이스는 여러 사용자가 같은 데이터에 접근할 수 있어야 한다. 순차적으로만 하면 쉽게 되겠지만 그렇게 하면 성능이 떨어진다.
격리성은 여러 개의 격리 수준으로 나뉘어 격리성을 보장한다.
격리 수준은 SERIALIZABLE, REPEATABLE_READ, READ_COMMITTED, READ_UNCOMMITTED가 있으며 위로 갈수록 동시성이 강해지지만 격리성은 약해지고, 아래로 갈수록 동시성은 약해지고 격리성은 강해진다. 예를 들어 SEREALIZABLE은 격리성이 강한데 반해, 동시성은 약하다. 또한, 각 단계마다 나타나는 현상이 있다.
REPEATABLE_READ는 팬텀 리드, READ_COMMITTED는 팬텀 리드, 반복 가능하지 않은 조회가 발생하며, READ_UNCOMMITTED는 팬텀 리드, 반복 가능하지 않은 조회, 더티 리드가 발생할 수도 있다.
격리 수준에 따라 발생하는 현상
격리 수준에 따라 발생하는 현상은 팬텀 리드, 반복 가능하지 않은 조회, 더티 리드가 있다.
- 팬텀 리드(phantom read)
팬텀 리드는 한 트랜잭션 내에서 동일한 쿼리를 보냈을 때 해당 조회 결과가 다른 경우를 말한다.
예를 들어 사용자 A가 회원 테이블에서 age가 12 이상인 회원들을 조회하는 쿼리를 보냈다. 이 결과로 세 개의 레코드가 조회한다고 하자. 그다음 사용자 B가 age가 15인 회원 레코드를 삽입한다. 그러면 그다음 세 개가 아닌 네 개의 레코드가 조회된다.
- 반복 가능하지 않은 조회(non-repeatable read)
반복 가능하지 않은 조회는 한 트랜잭션 내의 같은 행에 두 번 이상 조회가 발생했는데, 그 값이 다른 경우를 가리킨다.
예를 들어 사용자 A가 큰돌의 보석 개수가 100개라는 값을 가진 데이터였는데, 그 이후 사용자 B가 그 값을 1로 변경해서 커밋했다고 하면 사용자 A는 100이 아닌 1을 읽게 된다.
팬텀 리드와 다른 점은 반복 가능하지 않은 조회는 행 값이 달라질 수도 있는데, 팬텀 리드는 다른 행이 선택될 수도 있다는 것을 의미한다.
- 더티 리드(dirty read)
더티 리드는 반복 가능하지 않은 조회와 유사하며 한 트랜잭션이 실행 중일 때 다른 트랜잭션에 의해 수정되었지만 아직 '커밋되지 않은' 행의 데이터를 읽을 수 있을 때 발생한다.
예를 들어 사용자 A가 큰돌의 보석 개수 100을 1로 변경한 내용이 '커밋되지 않은' 상태라도 그 이후 사용자 B가 조회한 결과 1로 나오는 경우를 말한다.
격리 수준
- SEREALIZABLE
SEREALIZABLE은 말 그대로 트랜잭션을 순차적으로 진행시키는 것이다. 여러 트랜잭션이 동시에 같은 행에 접근할 수 없다. 이 수준은 매우 엄격한 수준으로 해당 행에 대해 격리시키고, 이후 트랜잭션이 이 행에 대해 일어난다면 기다려야 한다. 그렇기 때문에 교착 상태가 일어날 확률도 많고 가장 성능이 떨어지는 격리 수준이다.
- REPEATABLE_READ
REPEATABLE_READ는 하나의 트랜잭션이 수정한 행을 다른 트랜잭션이 수정할 수 없도록 막아주지만 새로운 행을 추가하는 것은 막지 않는다. 따라서 이후에 추가된 행이 발견될 수 있다. 이는 MySQL8.0의 innoDB 기본값이다.
- READ_COMMITTED
READ_COMMITTED는 가장 많이 사용되는 격리 수준이며 PostgreSQL, SQL Server, Oracle에서 기본값으로 설정되어 있다. READ_UNCOMMITTED와는 달리 다른 트랜잭션이 커밋하지 않은 정보는 읽을 수 없다. 즉, 커밋 완료된 데이터에 대해서만 조회를 허용한다. 하지만 어떤 트랜잭션이 접근한 행을 다른 트랜잭션이 수정할 수 있다. 예를 들어 트랜잭션 A가 수정한 행을 트랜잭션 B가 수정할 수도 있다. 이 때문에 트랜잭션 A가 같은 행을 다시 읽을 때 다른 내용이 발견될 수 있다.
- READ_UNCOMMITTED
READ_UNCOMMITTED는 가장 낮은 격리 수준으로, 하나의 트랜잭션이 커밋되기 전에 다른 트랜잭션에 노출되는 문제가 있지만 가장 빠르다. 데이터 무결성을 위해 되도록 사용하지 않는 것이 이상적이나, 몇몇 행이 제대로 조회되지 않더라도 괜찮은 거대한 양의 데이터를 '어림잡아' 집계하는 데는 사용하면 좋다.
지속성(Durability)
지속성은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 하는 것을 의미한다. 이는 데이터베이스에 시스템 장애가 발생해도 원래 상태로 복구하는 회복 기능이 있어야 함을 뜻하며, 데이터베이스는 이를 위해 체크섬, 저널링, 롤백 등의 기능을 제공한다.
- 체크섬은 중복 검사의 한 형태로, 오류 정정을 통해 송신된 자료의 무결성을 보호하는 단순한 방법이다.
- 저널링은 파일 시스템 또는 데이터베이스 시스템에 변경 사항을 반영(commit)하기 전에 로깅하는 것, 트랜잭션 등 변경 사항에 대한 로그를 남기는 것이다.
무결성
무결성이란 데이터의 정확성, 일관성, 유효성을 유지하는 것이다. 무결성이 유지되어야 데이터베이스에 저장된 데이터 값과 그 값에 해당하는 현실 세계의 값이 일치하는지에 대한 신뢰가 생긴다. 무결성의 종류는 다음과 같다.
| 이름 | 설명 |
| 개체 무결성 | 기본키로 선택된 필드는 빈 값을 허용하지 않는다. |
| 참조 무결성 | 서로 참조 관계에 있는 두 테이블의 데이터는 항상 일관된 값을 유지한다. |
| 고유 무결성 | 특정 속성에 대해 고유한 값을 가지도록 조건이 주어진 경우 그 속성 값은 모두 고유한 값을 가진다. |
| NULL 무결성 | 특정 속성 값에 NULL이 올 수 없다는 조건이 주어진 경우 그 속성 값은 NULL이 될 수 없다는 제약 조건이다. |
데이터베이스의 종류
관계형 데이터베이스(RDBMS)
관계형 데이터베이스는 행과 열을 가지는 표 형식 데이터를 저장하는 형태의 데이터베이스를 가리키며 SQL이라는 쿼리 언어를 써서 조작한다. MySQL, PostgreSQL, Oracle, SQL Server, MSSQL 등이 있다. 관계형 데이터베이스의 경우 표준 SQL은 지키기는 하지만 각 제품에 특화시킨 SQL을 사용한다. 예를 들어 Oracle의 경우 PL/SQL이라고 하며 SQL Server에서는 T-SQL, MySQL은 SQL을 쓴다.
MySQL
MySQL은 대부분의 운영체제와 호환되며 현재 가장 많이 사용하는 데이터베이스이다.
2023년 기준 PostgreSQL이 1위를 차지했으나, MySQL도 많이 사용하고 있다.
https://survey.stackoverflow.co/2023/#most-popular-technologies-database
Stack Overflow Developer Survey 2023
In May 2023 over 90,000 developers responded to our annual survey about how they learn and level up, which tools they're using, and which ones they want.
survey.stackoverflow.co
MySQL은 메타, 트위터 등 많은 기업에서 사용되고 있다.
C, C++로 만들어졌으며 MyISAM 인덱스 압축 기술, B-트리 기반의 인덱스, 스레드 기반의 메모리 할당 시스템, 매우 빠른 조인, 최대 64개의 인덱스를 제공한다. 대용량 데이터베이스를 위해 설계되어 있고 롤백, 커밋, 이중 암호 지원 보안 등의 기능을 제공하며 많은 서비스에서 사용한다.
데이터베이스의 심장과도 같은 역할을 하는 곳이 바로 스토리지 엔진인데, 모듈식 아키텍처로 쉽게 스토리지 엔진을 바꿀 수 있으며 데이터 웨어하우징, 트랜잭션 처리, 고가용성 처리에 강점을 두고 있다. 스토리지 엔진 위에는 커넥터 API 및 서비스 계층을 통해 MySQL 데이터베이스와 쉽게 상호 작용할 수 있다.
또한, MySQL은 쿼리 캐시를 지원해서 입력된 쿼리 문에 대한 전체 결과 집합을 저장하기 때문에 사용자가 작성한 쿼리가 캐시에 있는 쿼리와 동일하면 서버는 단순히 구문 분석, 최적화 및 실행을 건너뛰고 캐시의 출력만 표시한다.
PostgreSQL
PostgreSQL도 MySQL만큼 개발자들이 선호하는 데이터베이스 기술로 널리 인정받고 있다.
디스크 조각이 차지하는 영역을 회수할 수 있는 장치인 VACUUM이 특징이다. 최대 테이블의 크기는 32TB이며 SQL뿐만 아니라 JSON을 이용해서 데이터에 접근할 수 있다. 지정 시간에 복구하는 기능, 로깅, 접근 제어, 중첩된 트랜잭션, 백업 등을 할 수 있다.
NoSQL 데이터베이스
NoSQL(Not only SQL)이라는 슬로건에서 생겨난 데이터베이스이다. SQL을 사용하지 않는 데이터베이스를 말하며, 대표적으로 MongoDB와 redis 등이 있다.
MongoDB
MongoDB는 JSON을 통해 데이터에 접근할 수 있고, Binary JSON 형태(BJSON)로 데이터가 저장되며 와이어드타이거 엔진이 기본 스토리지 엔진으로 장착된 키-값 데이터 모델에서 확장된 도큐먼트 기반의 데이터베이스이다. 확장성이 뛰어나며 빅데이터를 저장할 때 성능이 좋고 고가용성과 샤딩, 레플리카셋을 지원한다. 또한, 스키마를 정해 놓지 않고 데이터를 삽입할 수 있기 때문에 다양한 도메인의 데이터베이스를 기반으로 분석하거나 로깅 등을 구현할 때 강점을 보인다.
또한, MongoDB는 도큐먼트를 생성할 때마다 다른 컬렉션에서 중복된 값을 지니기 힘든 유니크한 값인 ObjectID가 생성된다. 이는 기본키로 유닉스 기반의 타임스탬프(4바이트), 랜덤 값(5바이트), 카운터(3바이트)로 이루어져 있다.
Redis
redis는 인메모리 데이터베이스이자 키-값 데이터 모델 기반의 데이터베이스이다.
기본적인 데이터 타입은 문자열(string)이며 최대 512MB까지 저장할 수 있다. 이외에도 셋(set), 해시(hash) 등을 지원한다.
pub/sub 기능을 통해 채팅 시스템, 다른 데이터베이스 앞단에 두어 사용하는 캐싱 계층, 단순한 키-값이 필요한 세션 정보 관리, 정렬된 셋(sorted set) 자료 구조를 이용한 실시간 순위표 서비스에 사용한다.
인덱스
인덱스의 필요성
인덱스는 데이터를 빠르게 찾을 수 있는 하나의 장치이다. 예를 들어 책의 마지막 장에 있는 찾아보기이다. 책의 본문이 있고 그 본문 안에 내가 찾고자 하는 '항목'을 찾아보기를 통해 빠르게 찾을 수 있다. 마찬가지로 인덱스를 설정하면 테이블 안에 내가 찾고자 하는 데이터를 빠르게 찾을 수 있다.
B-트리
인덱스는 보통 B-트리라는 자료 구조로 이루어져 있다. 이는 루트 노드, 리프 노드, 그리고 루트 노드와 리프 노드 사이의 브랜치 노드로 나뉜다.
트리 탐색은 맨 위 루트부터 탐색이 일어나며 브랜치 노드를 거쳐 리프 노드까지 내려온다. 31을 찾는다면, '31보다 같거나 클 때까지 <='를 기반으로 처음 루트 노드에서는 20, 31 이후 아래 노드로 내려와 10, 30, 33 등 정렬된 값을 기반으로 탐색한다. 이렇게 루트 노드부터 시작하여 마지막 리프 노드에 도달해서 31이 가리키는 데이터 포인터를 통해 결괏값을 반환하게 된다.
인덱스가 효율적인 이유와 대수확장성
인덱스가 효율적인 이유는 효율적인 단계를 거쳐 모든 요소에 접근할 수 있는 균형 잡힌 트리 구조와 트리 깊이의 대수확장성 때문이다.
대수확장성이란 트리 깊이가 리프 노드 수에 비해 매우 느리게 성장하는 것이다. 기본적으로 인덱스가 한 깊이씩 증가할 때마다 최대 인덱스 항목의 수는 4배씩 증가한다.
표처럼 트리 깊이는 열 개짜리로, 100만 개의 레코드를 검색할 수 있다는 의미이다. 실제 인덱스는 이것보다 훨씬 효율적이다.
인덱스 만드는 방법
인덱스를 만드는 방법은 데이터베이스마다 다르며 MySQL과 MongoDB를 기준으로 설명한다.
MySQL
MySQL의 경우 클러스터형 인덱스와 세컨더리 인덱스가 있으며, 클러스터형 인덱스는 테이블당 하나를 설정할 수 있다. primary key 옵션으로 기본키를 만들면 클러스터형 인덱스를 생성할 수 있고, 기본키로 만들지 않고 unique not null 옵션을 붙이면 클러스터형 인덱스로 만들 수 있다.
create index... 명령어를 기반으로 만들면 세컨더리 인덱스를 만들 수 있다. 하나의 인덱스만 생성할 것이라면 클러스터형 인덱스를 만드는 것이 세컨더리 인덱스를 만드는 것보다 성능이 좋다.
세컨더리 인덱스는 보조 인덱스로 여러 개의 필드 값을 기반으로 쿼리를 많이 보낼 때 생성해야 하는 인덱스이다. 예를 들어 age라는 하나의 필드만으로 쿼리를 보낸다면 클러스터형 인덱스만 필요하다. 하지만 age, name, email 등 다양한 필드를 기반으로 쿼리를 보낼 때는 세컨더리 인덱스를 사용해야 한다.
MongoDB
MongoDB의 경우 도큐먼트를 만들면 자동으로 ObjectID가 형성되며, 해당 키가 기본키로 설정된다. 그리고 세컨더리키도 부가적으로 설정해서 기본키와 세컨더리키를 같이 쓰는 복합 인덱스 설정이 가능하다.
인덱스 최적화 기법
인덱스 최적화 기법은 데이터베이스마다 조금씩 다르지만 기본적인 골조는 똑같다. 따라서 설명은 MongoDB를 기준으로 하되, 이를 기반으로 다른 데이터베이스에 적용하면 된다.
인덱스는 비용이다
먼저 인덱스는 두 번 탐색하도록 강요한다. 인덱스 리스트, 그다음 컬렉션 순으로 탐색하기 때문이며, 관련 읽기 비용이 들게 된다.
또한, 컬렉션이 수정되었을 때 인덱스도 수정되어야 한다. 이 때 B-트리의 높이를 균형있게 조절하는 비용도 들고, 데이터를 효율적으로 조회할 수 있도록 분산시키는 비용도 들게 된다.
따라서 쿼리에 있는 필드에 인덱스를 무작정 다 설정하는 것은 답이 아니다. 또한, 컬렉션에서 가져와야 하는 양이 많을수록 인덱스를 사용하는 것은 비효율적이다.
항상 테스팅하라
인덱스 최적화 기법은 서비스 특징에 따라 달라진다. 서비스에서 사용하는 객체의 깊이, 테이블의 양 등이 다르기 때문이다. 따라서 항상 테스팅하는 것이 중요하다. explain() 함수를 통해 인덱스를 만들고 쿼리를 보낸 이후에 테스팅을 하며 걸리는 시간을 최소화해야 한다.
EXPLAIN
SELECT * FROM t1
JOIN t2 ON t1.c1 = t2.c1
복합 인덱스는 같음, 정렬, 다중 값, 카디널리티 순이다
보통 여러 필드를 기반으로 조회를 할 때 복합 인덱스를 생성하는데, 이 인덱스를 생성할 때는 순서가 있고 생성 순서에 따라 인덱스 성능이 달라진다. 같음, 정렬, 다중 값, 카디널리티 순으로 생성해야 한다.
1. 어떠한 값과 같음을 비교하는 == 이나 equals이라는 쿼리가 있다면 제일 먼저 인덱스로 정한다.
2. 정렬에 쓰는 필드라면 그다음 인덱스로 정한다.
3. 다중 값을 출력해야 하는 필드, 즉 쿼리 자체가 < 이거나 > 등 많은 값을 출력해야 하는 쿼리에 쓰는 필드라면 나중에 인덱스를 설정한다.
4. 유니크한 값의 정도(고유한 값의 수)를 카디널리티라고 한다. 이 카디널리티가 높은 순서를 기반으로 인덱스를 생성해야 한다. 예를 들어 age와 email이 있다면 카디널리티가 더 높은 email 필드에 대한 인덱스를 먼저 생성해야 한다.
조인의 종류
조인(join)이란 하나의 테이블이 아닌 두 개 이상의 테이블을 묶어서 하나의 결과물을 만드는 것을 말한다. MySQL에서는 JOIN이라는 쿼리로, MongoDB에서는 lookup이라는 쿼리로 이를 처리한다.
참고로 MongoDB를 사용할 때 lookup은 지양해야 한다. MongoDB는 조인 연산(lookup)에 대해 관계형 데이터베이스보다 성능이 떨어진다고 여러 벤치마크 테스트에서 알려져 있다.
따라서 여러 테이블을 조인하는 작업이 많을 경우 MongoDB보다는 관계형 데이터베이스를 써야 한다.
조인의 원리
조인은 조인의 원리를 기반으로 이루어진다. 조인의 원리는 중첩 루프 조인, 정렬 병합 조인, 해시 조인이 있다. 조인은 이 원리를 기반으로 조인을 한다.
중첩 루프 조인(NLJ, Nested Loop Join)
중첩 루프 조인은 중첩 for 문과 같은 원리로 조건에 맞는 조인을 하는 방법이며, 랜덤 접근에 대한 비용이 많이 증가하므로 대용량 테이블에서는 사용하지 않는다.
예를 들어 "t1, t2 테이블을 조인한다." 라고 했을 때 첫 번째 테이블에서 행을 한 번에 하나씩 읽고 그다음 테이블에서도 행을 하나씩 읽어 조건에 맞는 레코드를 찾아 결괏값을 반환한다.
중첩 루프 조인에서 발전한 조인할 테이블을 작은 블록으로 나눠서 블록 하나씩 조인하는 블록 중첩 루프(BNL, Block Nested Loop)라는 방식도 있다.
정렬 병합 조인
정렬 병합 조인이란 각각의 테이블을 조인할 필드 기준으로 정렬하고 정렬이 끝난 이후에 조인 작업을 수행하는 조인이다. 조인할 때 쓸 적절한 인덱스가 없고 대용량 테이블들을 조인하고 조인 조건으로 <, > 등 범위 비교 연산자가 있을 때 쓴다.
해시 조인
해시 조인은 해시 테이블을 기반으로 조인하는 방법이다. 두 개의 테이블을 조인한다고 했을 때 하나의 테이블이 온전히 메모리에 들어간다면 보통 중첩 루프 조인보다 더 효율적이다.(메모리에 올릴 수 없을 정도로 크면 디스크를 사용하는 비용이 발생한다.) 또한, 동등(=) 조인에서만 사용할 수 있다.
MySQL의 경우 MySQL8.0.18 릴리스와 함께 이 기능을 사용할 수 있게 되었으며 이를 기반으로 해시 조인 단계는 빌드 단계, 프로브 단계로 나뉜다.
빌드 단계
빌드 단계는 입력 테이블 중 하나를 기반으로 메모리 내 해시 테이블을 빌드하는 단계이다.
예를 들어 person과 countries라는 테이블을 조인한다고 했을 때 둘 중에 바이트가 더 작은 테이블을 기반으로 해서 테이블을 빌드한다.
또한, 조인에 사용되는 필드가 해시 테이블의 키로 사용된다. 이 때 countries가 더 작다면, 'countries.countries_id'가 키로 사용된다.
프로브 단계
프로브 단계 동안 레코드 읽기를 시작하며, 각 레코드에서 'person.countries_id'에 해시 테이블을 기반으로 일치하는 레코드를 찾아 결괏값으로 반환한다.
이를 통해 각 테이블은 한 번씩만 읽게 되어 중첩해서 두 개의 테이블을 읽는 중첩 루프 조인보다 보통은 성능이 더 좋다. 사용 가능한 메모리양은 시스템 변수 join_buffer_size에 의해 제어되며, 런타임 시 조정할 수 있다.
