DB: 두 판 사이의 차이

기술노트
(CS 용어 정리 - DB 추가)
 
(CS 용어 정리 - DB 추가)
 
1번째 줄: 1번째 줄:
== DB ==
==== 데이터베이스(DB, DataBase)란? ====
> 일정한 규칙, 혹은 규약을 통해 구조화되어 저장되는 데이터의 모음


=== 인덱스 ===
해당 데이터베이스를 제어, 관리하는 통합 시스템을 DBMS(DataBase Management System)라고 하며, 데이터베이스 안에 있는 데이터들은 특정 DBMS마다 정의된 쿼리 언어(query language)를 통해 삽입, 삭제, 수정, 조회 등을 수행할 수 있다.


인덱스는 데이터를 테이블에 검색 작업을 할때 성능을 높여주는 자료구조이다. 특정 컬럼에 인덱스를 생성하면, 해당 컬럼의 데이터들을 정렬하여 별도의 메모리 공간에 데이터의 물리적 주소와 함께 저장된다.
==== 엔티티(entity)란? ====
쿼리문에 "인덱스 생성 컬럼을 WHERE 조건으로 거는 "의 작업을 하면 *옵티마이저에서 판단하여 생성된 인덱스를 탈 수가 있다. 만약 인덱스를 타게 되면 아래의 그림과 같이
>사람, 장소, 물건, 사건, 개념 여러 개의 속성을 지닌 명사
인덱스를 타게 되고 먼저 인덱스에 저장되어 있는 데이터의 물리적 주소로 가서 데이터를 가져오는 식으로 동작을 하여 검색 속도의 향상을 가져올 수 있다.


또한 인덱스 생성시,  데이터를 오름차순으로 정렬하기 때문에 정렬된 주소체계라고 표현할 수 있다.
'''약한 엔티티와 강한 엔티티'''
예를 들어 A가 혼자서는 존재하지 못하고 B의 존재 여부에 따라 종속적이라면 A는 약한 엔티티이고 B는 강한 엔티티가 된다.


> 옵티마이저 : 옵티마이저는 가장 효율적인 방법으로 SQL을 수행할 최적의 처리 경로를 생성해주는 DBMS의 핵심 엔진이다.
==== 릴레이션(relation)란? ====
> 컴퓨터의 두뇌가 CPU인 것처럼 DBMS의 두뇌는 '''옵티마이저'''라고 할 수 있다.
>데이터베이스에서 정보를 구분하여 저장하는 기본 단위


![index](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbPb8pb%2FbtrePWRO9HY%2FqrzMfX84KAAuFgkyZkKtKK%2Fimg.png)
엔티티에 관한 데이터를 데이터베이스는 릴레이션 하나에 담아서 관리한다.


==== 인덱스의 사용이유 ====
릴레이션은 관계형 데이터베이스에서는 '테이블'이라고 하며, NoSQL 데이터베이스에서는 '컬렉션'이라고 한다.
인덱스의 가장 큰 특징으로는 모든 데이터들이 정렬되어 있다는 점이다. 이 특징으로 조건 검색이라는 영역에서 굉장한 장점이 된다.


1. 조건 검색 WHERE 효율
'''테이블과 컬렉션'''
  - 테이블을 만들고 안에 데이터가 쌓이게 되면 테이블의 레코드(row : 행)는 내부적으로 순서가 없이 뒤죽박죽으로 저장이 된다.
데이터 베이스의 종류는 크게 관계형 데이터베이스와 NoSQL 데이터베이스로 나눌 수 있다. 이 중 대표적인 관계형 데이터베이스인 MySQL과 대표적인 NoSQL 데이터베이스인 MongoDB를 예로 들면, MySQL의 구조는 레코드-테이블-데이터베이스로 이루어져 있고 MongoDB 데이터베이스의 구조는 도큐먼트-컬렉션-데이터베이스로 이루어져 있다.
  - 이렇게 되면 WHERE절에 특정 조건에 맞는 데이터들을 찾아낼 때도 레코드의 처음부터 끝까지 다 읽어서 검색 조건과 맞는지 비교해야 한다. 이것을 풀 테이블 스캔 (Full Table Scan), 줄여서 풀 스캔(Full Scan)이라고 한다.  
  - 만 인덱스 테이블 스캔(Index Table Scan) 시 인덱스 테이블은 데이터들이 정렬되어 저장되어 있기 때문에 해당 조건(WHERE)에 맞는 데이터들을 빠르게 찾아낼 수 있는 것이다


2. 정렬 ORDER BY 효율
==== 속성(attribute)이란? ====
  - 인덱스는 기본적으로 정렬이 되어오기 때문에 정렬 과정을 피할 수 있다.
>릴레이션에서 관리하는 구체적이며 고유한 이름을 갖는 정보


3. MIN,MAX 효율 처리
에를 들어 '차'라는 엔티티의 속성을 뽑아보면, 차 넘버, 바퀴 수, 차 색깔, 차종 등이 있다. 이 중에서 서비스의 요구 사항을 기반으로 관리해야 할 필요가 있는 속성들만 엔티티의 속성이 된다.


==== 인덱스의 단점 ====
==== 도메인(domain)이란? ====
>릴레이션에 포함된 각각의 속성들이 가질 수 있는 값의 집합


1. 인덱스는 DML에 취약하다.
예를 들어 성별이라는 속성이 있다면 이 속성이 가질 수 있는 값은 {남, 여}라는 집합이 된다.
  - INSERT, UPDATE, DELETE를 통해 데이터가 추가되거나 값이 바뀐다면 인덱스 테이블 내에 있는 값들을 다시 정렬을 해야 한다.
  - 그에 따른 추가 시간 소모


2. 무조건 인덱스 스캔이 좋은 것이 아니다.
==== 필드와 레코드 ====
    - 인덱스는 테이블의 전체 데이터 중에서 10~15% 이하의 데이터를 처리하는 경우에만 효율적이고 그 이상의 데이터를 처리할 땐 인덱스를 사용하지 않는 것이 더 낫다.
앞에서 설명한 것들을 바탕으로 데이터베이스에서 필드와 레코드로 구성된 테이블을 만들 수 있다.
    - 100개의 데이터가 있는 테이블과 100만 개의 데이터가 들어 있는 테이블이 있다고 하자. 100만 개의 데이터가 들어있는 테이블이라면 풀 스캔보다는 인덱스 스캔이 유리하겠지만, 100개의 데이터가 들어있는 테이블은 굳이 인덱스 스캔 없이 풀 스캔이 빠를 것이다
![](https://velog.velcdn.com/images/cnj9912/post/c16b36f4-fe86-4a9c-905a-326b1fdf9bc4/image.png)


3. 속도 향상을 위해선 인덱스를 많이 만들지 않는 것이 좋다.
고객이란 엔티티는 고객코드, 이름, 전화번호 등의 필드를 가진다. 그리고 이 테이블에 쌓이는 행(row) 단위의 데이터를 레코드라고 한다. 또한 레코드를 튜플이라고도 한다.
    - 인덱스를 관리하기 위해서는 데이터베이스의 약 10%에 해당하는 저장공간이 추가로 필요하다


4. 전체적인 데이터베이스 성능 부하를 초래한다.
==== 관계 ====
  - 데이터베이스 서버에 성능 문제가 발생하면 가장 빨리 생각하는 해결책이 인덱스 추가 생성이다.
데이터베이스에 테이블은 하나만 있는 것이 아니다. 여러 개의 테이블이 있고 이러한 테이블은 서로의 관계가 정의되어 있다.
    문제가 발생할 때마다 인덱스를 생성하면서 인덱스가 쌓여가는 것은 하나의 쿼리문을 빠르게는 만들 수 있지만,
![](https://velog.velcdn.com/images/cnj9912/post/3edc6d9e-66cf-4ce2-9ece-ae2a48fb24f8/image.png)
    전체적인 데이터베이스의 성능 부하를 초래한다.


=== 인덱스의 종류 ===
'''1:1 관계'''
1:1 관계는 테이블을 두 개의 테이블로 나눠 테이블의 구조를 더 이해하기 쉽게 만들어 준다.


==== HashTable ====
예를 들어, 일반적으로 컴퓨터 1대에 1개의 마우스가 있으므로 1:1 관계라고 할 수 있다.


Key-Value 형태로 저장시키는 해쉬테이블을 이용한 자료구조로 빠른 데이터 탐색이 가능하다.
'''1:N 관계'''
두 개의 서로 다른 타입의 두 개체들 A와 B가 있을 때, A 개체가 B 개체 여러 개와 연결될 수 있지만 B 개체는 1개의 A 개체만 연결될 수 있는 관계이다.


하지만, 해쉬 충돌과 등호 연산에 최적화되어 있는 자료구조의 특성상 추천되지 않는다.
예를 들어, 컴퓨터는 1개 이상의 USB 드라이브를 인식할 수 있지만 USB 드라이브는 1대의 컴퓨터랑만 연결할 수 있으므로 컴퓨터와 USB 드라이브는 1:N 관계라 할 수 있다.


==== B-TREE ====
'''N:M 관계'''
학생과 강의의 관계를 정의하면, 학생도 강의를 많이 들을 수 있고 강의도 여러 명의 학생을 포함할 수 있기 때문에 N:M 관계가 된다.


트리구조로 구성되어 있는 자료구조로, DB 인덱스가 아니어도 검색이 유용한 구조로 자주 사용된다.
==== 키 ====
테이블 간의 관계를 조금 더 명확하게 하고 테이블 자체의 인덱스를 위해 설정된 장치로 기본키, 외래키, 후보키, 슈퍼키, 대체키가 있다.
![](https://velog.velcdn.com/images/cnj9912/post/e081c051-4589-465b-9573-70f3e73c7ac9/image.png)


![](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FqycZ2%2FbtqBQnr4QYG%2F7J8KpnmNaJiTjgS0K9TEIK%2Fimg.png)
슈퍼키는 유일성이 있고 그 안에 포함된 후보키는 최소성까지 갖춘 키이다. 후보키 중에서 기본키로 선택되지 못한 키는 대체키가 된다. 유일성은 중복되는 값은 없으며, 최소성은 필드를 조합하지 않고 최소 필드만 써서 키를 형성할 수 있는 것을 말한다.


여기서 B-Tree의 핵심은 데이터가 항상 정렬된 상태라는 점이다.
'''기본키'''
기본키(Primary Key)는 줄여서 PK 또는 프라이머리키라고 많이 부르며, 유일성과 최소성을 만족하는 키이다.


B-TREE의 구조는 크게 3가지로 나뉜다.
이는 테이블의 데이터 중 고유하게 존재하는 속성이며 기본키에 해당하는 데이터는 중복되어서는 안된다.


1. ROOT
'''외래키'''
2. BRANCH
외래키(Foreign Key)는 FK라고도 하며, 다른 테이블의 기본키를 그대로 참조하는 값으로 개체와의 관계를 식별하는 데 사용한다.
3. LEAF


![](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2Fcikell%2FbtqBRvDU1xF%2FCdIhvg8XEhHKaP23vE4Ju1%2Fimg.jpg)
외래키는 중복되어도 상관없다.


위의 사진을 보면 Binary Search Tree(이분 탐색 트리)와 비슷한 구조를 가지고 있으나 자식 노드로 2개 이상의 노드를 가질 있다는 점에서 차이가존재한다.
'''후보키'''
검색 방법은 `Key`값을 이용하여 찾고자하는 데이터를 찾는다.
후보키(candidate key)는 기본키가 될 있는 후보들이며 유일성과 최소성을 동시에 만족하는 키이다.


==== B-TREE의 검색방법 ====
'''대체키'''
대체키(alternate key)는 후보키가 두 개 이상일 경우 어느 하나를 기본키로 지정하고 남은 후보키들을 말한다.


1. 인덱스 레인지 스캔
'''슈퍼키'''
슈퍼키(super key)는 각 레코드를 유일하게 식별할 수 있는 유일성을 갖춘 키이다.


* 데이터를 이미 정렬 상태로 넣기 때문에 예를 들어 범위 검색을 통해 찾고자하는 값이 4이상이라면 아래의 그림과 같은 방법으로 4번 인덱스(1번 리프노드)는 거치지 않게된다.
==== ERD(Entity Relationship Diagram)란? ====
* B-TREE의 검색방법중 가장 빠른 속도를 보장하며 B-Tree의 필요한 영역을 스캔하는 데 어떤 작업이 필요한지만 이해할 수 있으면 충분하다.
>데이터베이스를 구축할 때 가장 기초적인 뼈대 역할을 하며, 릴레이션 간의 관계들을 정의한 것


![index_Range_Scan](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Ft1.daumcdn.net%2Fcfile%2Ftistory%2F2252D637592E6F432C)
만약 서비스를 구축한다면 가장 먼저 신경 써야 할 부분이며 이 부분을 신경 쓰지 않고 서비스를 구축한다면 단단하지 않은 골조로 건물을 짓는 것이나 다름없다.


* 인덱스 레인지 스캔은 검색해야 할 인덱스의 범위가 결정됐을 때 사용하는 방식
==== ERD의 중요성 ====
* 루트 노드에서부터 비교를 시작해 브랜치 노드를 거치고 최종적으로 리프 노드까지 찾아 들어가야만 비로소 실제로 원하는 시작 지점을 찾을 수 있다.
ERD는 시스템의 요구 사항을 기반으로 작성되며 이 ERD를 기반으로 데이터베이스를 구축한다. 데이터 베이스를 구축한 이후에도 디버깅 또는 비즈니스 프로세스 재설계가 필요한 경우에 설계도 역할을 담당하기도 한다.
* 만약 스캔하다가 리프 노드의 끝까지 읽으면 리프 노드 간의 링크를 이용해 다음 리프 노드를 찾아서 다시 스캔합니다. 그리고 최종적으로 스캔을 멈춰야 할 위치에 다다르면 지금까지 읽은 레코드를 사용자에게 반환하고 쿼리를 끝낸다.
* 만약 3건의 레코드가 검색 조건에 일치했다고 가정하면 데이터 레코드를 읽기 위해 랜덤 I/O가 최대 3번이 필요하게 됩니다. 그래서 인덱스를 통해 데이터 레코드를 읽는 작업은 비용이 많이 드는 작업으로 분류됨.  
* 인덱스를 통해 읽어야 할 데이터 레코드가 20~25%를 넘으면 인덱스를 통한 읽기보다 테이블의 데이터를 직접 읽는 것이 더 효율적인 처리 방식이 되는 것


2. 인덱스 풀 스캔
하지만 ERD는 관계형 구조로 표혈할 수 있는 데이터를 구성하는 데 유용할 수 있지만 비정형 데이터를 충분히 표현할 수 없다는 단점이 있다.
>'''비정형 데이터'''
비구조화 데이터를 말하며, 미리 정의된 데이터 모델이 없거나 미리 정의된 방식으로 정리되지 않은 정보를 말한다.


* 인덱스 레인지 스캔과 마찬가지로 인덱스를 사용하지만 인덱스 레인지 스캔과는 달리 인덱스의 처음부터 끝까지 모두 일근 방식을 인덱스 풀스캔이라고 함
==== 정규화 과정 ====
* 대표적으로 쿼리의 조건절에 사용된 컬럼이 인덱스의 첫번째 컬럼이 아닌 경우 인덱스 풀스캔방식이 사용됩니다. 예를 들어 인덱스는 (A, B, C) 컬럼의 순서대로 만들어져 있지만 쿼리의 조건절은 B 컬럼이나 C 컬럼으로 검색하는 경
정규화 과정은 릴레이션 간의 잘못된 종속 관계로 인해 데이터베이스 이상 현상이 일어나서 이를 해결하거나, 저장 공간을 효율적으로 사용하기 위해 릴레이션을 여러 개로 분리하는 과정이다.
* 일반적으로 인덱스의 크기는 테이블의 크기보다 작으므로 직접 테이블을 처음부터 끝까지 읽는 것보다는 인덱스만 읽는 것이 효율적
* 쿼리가 인덱스에 명시된 컬럼만으로 조건을 처리할 수 있는 경우 주로 이 방식이 사용


![](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Ft1.daumcdn.net%2Fcfile%2Ftistory%2F236F1C3C592E6F580A)
데이터베이스 이상 현상이란 회원이 한 개의 등급을 가져야 하는데 세 개의 등급을 갖거나 삭제할 때 필요한 데이터가 같이 삭제되고, 데이터를 삽입해야 하는데 하나의 필드 값이 NULL이 되면 안되어서 삽입하기 어려운 현상을 말한다.


3. 루스 인덱스 스캔
정규화 과정은 정규형 원칙을 기반으로 정규형을 만들어가는 과정이며, 정규화된 정도는 정규형(NF, Normal Form)으로 표현한다. 기본 정규형인 제1정규형, 제2정규형, 제3정규형, 보이스/코드 정규형이 있고 고급 정규형인 제4정규형, 제5정규형이 있다. 이 중 기본 정규형인 제1정규형, 제2정규형, 제3정규형, 보이스/코드 정규형을 알아보겠다.


* 일반적으로 GROUP BY 또는 집합 함수 가운데 MAX() 또는 MIN() 함수에 대해 최적화를 하는 경우에 사용
'''정규형 원칙'''
정규형의 원칙이란 같은 의미를 표현하는 릴레이션이지만 좀 더 좋은 구조로 만들어야 하고, 자료의 중복성은 감소해야 하고, 독립적인 관계는 별개의 릴레이션으로 표현해야 하며, 각각의 릴레이션은 독립적인 표현이 가능해야 하는 것을 말한다.


==== B-TREE는 왜 빠른가? ====
'''제1정규형'''
B-TREE의 장점은 한 가지 '어떤 값에 대해서도 같은 시간에 결과를 얻을 수 있다'인데, 이를 ''''균일성''''이라고 한다.
릴레이션의 모든 도메인이 더 이상 분해될 수 없는 원자 값(atomic value)만으로 구성되어야 한다. 릴레이션의 속성 값 중에서 한 개의 기본키에 두해 두 개 이상의 값을 가지는 반복 집합이 있어서는 안 된다. 만약에 반복 집합이 있다면 제거해야 한다.
(트리 높이가 다른 경우, 약간의 차이는 있겠지만 O(logN)이라는 시간 복잡도를 구할 수 있다.)
![](https://velog.velcdn.com/images/cnj9912/post/aed0cfdc-eccb-4e24-bbe1-f2be459785c9/image.png)


==== B-TREE는 균형 트리 구조 ====
예를 들어 위처럼 릴레이션이 이루어져 있다면, 제1 정규형을 만족하지 못한다. 학번이 100인 학생의 과목 번호와 성적이 2개로 이루어져 있기 때문이다. 따라서 제1 정규형이 되려면 다음과 같이 속성 값을 분리해주어야 한다.
![](https://velog.velcdn.com/images/cnj9912/post/75a16d5b-ead9-40b7-84c3-0698233c3844/image.png)


![](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2Fb9BMy3%2FbtqBTL7abid%2FXsBqjuQU9fMG9CdDakMMa1%2Fimg.png)
'''제2정규형'''
릴레이션이 제1정규형이며 부분 함수의 종속성을 제거한 형태를 말한다.


'균형 트리'란 루트로부터 리프까지의 거리가 일정한 트리 구조를 뜻하는 것으로, 트리 중에서 특히 성능이 안정화 되어있다.  
부분 함수의 종속성 제거란 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속적인 것을 말한다.
![](https://velog.velcdn.com/images/cnj9912/post/632bd8c5-5bbe-4250-8d60-660d70e7ab2a/image.png)


그러나, B-tree 처음 생성 당시는 균형 트리이지만 테이블 갱신(INSERT/UPDATE/DELETE)의 반복을 통해 서서히 균형이 깨지고, 성능도 악화된다.  
위 그림처럼 각 속성들이 모두 완전 함수 종속이 되도록 릴레이션을 분리시켜준다. 따라서 아래와 같이 릴레이션이 형성된다.


어느 정도 자동으로 균형을 회복하는 기능이 있지만, 갱신 빈도가 높은 테이블에 작성되는 인덱스 같은 경우 인덱스 재구성을 해서 트리의 균형을 되찾는 작업이 필요하다.  
![](https://velog.velcdn.com/images/cnj9912/post/9006b4f1-ede4-4096-9e3d-18cf03b729b6/image.png)


==== B+TREE ====
이 때 주의할 점은 릴레이션을 분해할 때 동등한 릴레이션을 분해해야 하고, 정보 손실이 발생하지 않는 무손실 분해로 분해되어야 한다는 것이다.


기존 B-TREE는 한 데이터의 검색은 효율적이지만, 모든 데이터를 순회하는데에 모든 노드를 순회해야하는 비효율적 구조를 띄고 있기에 단점을 개선시킨 B+TREE가 생겼다.
'''제3정규형'''
제2정규형이고 기본키가 아닌 모든 속성이 이행적 함수 종속(transitive FD)을 만족하지 않는 상태를 말한다.


B+Tree는 오직 leaf node에만 데이터를 저장하고 leaf node가 아닌 node에서는 자식 포인터만 저장한다
>'''이행적 함수 종속'''
그리고 leaf node끼리는 Linked list로 연결되어있다.
A -> B와 B -> C가 존재하면 논리적으로 A -> C가 성립하는데, 이때 집합 C가 집합 A에 이행적으로 함수 종속이 되었다고 한다.


또, B+Tree에서는 반드시 leaf node에만 데이터가 저장되기 때문에 중간 node에서 key를 올바르게 찾아가기 위해서 key가 중복될 수 있다.  
![](https://velog.velcdn.com/images/cnj9912/post/6c2c94d6-e340-4299-ad9f-0be41a0ca2ea/image.png)


![B+TREE](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FSvp6z%2FbtrdEi9c2DR%2FR4Dnmqkl8RWcqQPBACI9fK%2Fimg.png)
이렇게 이행적 함수 종속 관계에 있는 속성을 분리한다. 테이블로 나타내면 아래와 같다.


==== B+TREE 장점 ====
![](https://velog.velcdn.com/images/cnj9912/post/608eee97-9762-4f49-ac1b-78c579df0fc1/image.png)
1. leaf node를 제외하고 데이터를 저장하지 않기 때문에 메모리를 더 확보할 수 있다. 따라서 하나의 node에 더 많은 포인터를 가질 수 있기 때문에 트리의 높이가 더 낮아지므로 검색 속도를 높일 수 있다.


2. Full scan을 하는 경우 B+Tree는 leaf node에만 데이터가 저장되어 있고, leaf node끼리 linked list로 연결되어 있기 때문에 선형 시간이 소모된다. 반면 B-Tree는 모든 node를 확인해야 한다.
'''보이스/코드 정규형'''
보이스/코드 정규형(BCNF)은 제3정규형이고, 결정자가 후보키가 아닌 함수 종속 관계를 제거하여 릴레이션의 함수 종속 관계에서 모든 결정자가 후보키인 상태를 말한다.
>'''결정자'''
함수 종속 관계에서 특정 종속자(dependent)를 결정짓는 요소, 'X -> Y'일 때 X는 결정자, Y는 종속자이다.


3. B-TREE와 비교하여, B-Tree의 경우 최상의 경우 특정 key를 root node에서 찾을 수 있지만, B+Tree의 경우 반드시 특정 key에 접근하기 위해서 leaf node까지 가야 하는 단점이 있다.
아래와 같은 제3 정규형을 만족하는 릴레이션이 있다고 가정하자. 한 교수당 하나의 수업만 맡는다고 가정한다.


해시 테이블에서 언급했듯이 인덱스 컬럼은 부등호를 이용한 순차 검색 연산이 자주 발생할 수 있다. 따라서 B+Tree의 Linked list를 이용하면 순차 검색을 효율적으로 할 수 있게 된다.
![](https://velog.velcdn.com/images/cnj9912/post/499ecc11-9c94-48fc-92b4-9bb2b268d4d2/image.png)


모든 결정자는 항상 후보키가 되도록 릴레이션을 분해해주면 강한 제3 정규형, 즉 BCNF를 만족하게 된다.
![](https://velog.velcdn.com/images/cnj9912/post/0d251558-4cb8-4e12-992b-d6b1c0a65e58/image.png)


=== 트랜잭션이란? ===
> 데이터베이스에서 하나의 논리적 기능을 수행하기 위한 작업의 단위


B+Tree의 검색 과정은 B-Tree와 동일하다.
데이터베이스에 접근하는 방법은 쿼리이므로, 즉 여러 개의 쿼리들을 하나로 묶는 단위를 말한다. 이에 대한 특징은 원자성, 일관성, 독립성, 지속성이 있으며 이를 한꺼번에 ACID 특징이라고 한다.


반면 B+Tree의 삽입과 삭제 과정은 약간의 차이가 있다. 기본적으로 B+Tree의 삽입과 삭제는 항상 leaf node에서 일어난다.
==== 원자성 ====
"all or nothing"


==== 인덱스가 효율적인 이유와 대수 확장성 ====
원자성(atomicity)은 트랜잭션과 관련된 일이 모두 수행되었거나 되지 않았거나를 보장하는 특징이다. 예를 들어 트랜잭션을 커밋했는데, 문제가 발생하여 롤백하는 경우 그 이후에 모두 수행되지 않음을 보장하는 것을 말한다.
인덱스가 효율적인 이유는 효율적인 단계를 거쳐 모든 요소에 접근할 수 있는 균형잡힌 트리 구조와 트리 깊이의 대수확장성 떄문이다.


다만 B-TREE의 경우 비균형 트리가 될 수 있으며, 깊이 또한 키값의 크기에 따라 달라진다.
또한, 트랜잭션 단위로 여러 로직들을 묶을 때 외부 API를 호출하는 것이 있으면 안 된다. 만약 있다면 롤백이 일어났을 때 어떻게 해야 할 것인지에 대한 해결 방법이 있어야 하고 트랜잭션 전파를 신경 써서 관리해야 한다.


키값이 16바이트인 경우 최대 2억 32바이트인 경우 5천만개로 줄어든다.
'''커밋과 롤백'''
커밋(commit)은 여러 쿼리가 성공적으로 처리되었다고 확정하는 명령어이다. 트랜잭션 단위로 수행되며 변경된 내용이 모두 영구적으로 저장되는 것을 말한다. "커밋이 수행되었다."를 "하나의 트랜잭션이 성공적으로 수행되었다."라고도 말한다.


대수확장성이란 트리 깊이가 리프 노드 수에 비해 매우 느리게 성장하는 것을 의미한다.
update, insert, delete의 쿼리가 하나의 트랜잭션 단위로 수행되고 이후에 데이터베이스에 영구 저장된다.
기본적으로 인덱스가 한깊이 씩 증가할 때마다, 최대 인덱스 항목의 수는 4배씩 증가한다.


=== 인덱스 생성방법 ===
하지만 에러나 여러 이슈 때문에 트랜잭션 전으로 돌려야 한다면 어떻게 해야 할까?


'''MySQL'''
이때 사용하는 것이 롤백이다. 롤백이란 트랜잭션으로 처리한 하나의 묶음 과정을 일어나기 전으로 돌리는 일(취소)을 말한다.
MySQL의 경우 클러스터형 인덱스와 세컨더리 인덱스가 존재한다.


'''클러스터형 인덱스'''
이러한 커밋과 롤백 덕에 데이터의 무결성이 보장된다. 또한, 데이터 변경 전에 변경 사항을 쉽게 확인할 수 있고 해당 작업을 그룹화할 수 있다.
* 하나의 키를 기반으로 물리적으로 테이블의 데이터 행을 정렬 및 저장한다.
* 클러스터 인덱스는 데이터를 가리키는 포인터가 아닌 데이터를 저장한 블록의 포인터를 저장한다.
* 테이블 당 하나만 생성가능
* 인덱스 자체의 리프 노드가 곧 데이터다. 즉 테이블 자체가 인덱스이다.
* 데이터 입력, 수정, 삭제 시 항상 정렬 상태를 유지한다.


'''비클러스터형 인덱스(세컨더리 인덱스)'''
'''트랜잭션 전파'''
* 테이블당 약 240개의 인덱스를 만들 수 있다.
트랜잭션을 수행할 때 커넥션 단위로 수행하기 때문에 커넥션 객체를 넘겨서 수행해야 한다. 하지만 이를 매번 넘겨주기가 어렵기도 하고 귀찮다. 이를 넘겨서 수행하지 않고 여러 트랜잭션 관련 메서드의 호출을 하나의 트랜잭션에 묶이도록 하는 것을 트랙잭션 전파라고 한다.
* 인덱스 페이지는 로그파일에 저장된다.
* 레코드의 원본은 정렬되지 않고, 인덱스 페이지만 정렬된다.
* 인덱스 자체의 리프 페이지는 데이터가 아니라 데이터가 위치하는 포인터(RID)이기 때문에 클러스터형보다 검색 속도는 더 느리지만 데이터의 입력, 수정, 삭제는 더 빠르다.
* 인덱스를 생성할 때 데이터 페이지는 그냥 둔 상태에서 별도의 인덱스 페이지를 따로 만들기 때문에 용량을 더 차지한다
* 3% 이내에서 사용해야 좋은 선택도를 가진다.


==== 클러스터 인덱스와 비 클러스터 인덱스 비교 ====
<syntaxhighlight>java
@Service
@Transactional(readOnly = true)
public class MemberService {
private final MemberRepository memberRepository;
   
    public MemberService(MemberRepository memberRepository) {
    this.memberRepository = memberRepository;
    }
}
</syntaxhighlight>


|기준|클러스터 인덱스|비 클러스터 인덱스|
앞의 코드처럼 Spring 프레임워크에서는 `@Transactional` 애너테이션을 통해 여러 쿼리 관련 코드들을 하나의 트랜잭션으로 처리한다.
|----|-------|--------|
|속도|빠르다|느리다|
|사용 메모리|적다|많다
|인덱스|인덱스가 주요 데이터|인덱스가 데이터의 사본(Copy)|
|개수|한 테이블에 한 개|한 테이블에 여러 개(최대 약 250개)|
|리프 노드|리프 노드 자체가 데이터|리프 노드는 데이터가 저장되는 위치|
|저장값|데이터를 저장한 블록의 포인터|값과 데이터의 위치를 가리키는 포인터|
|정렬|인덱스 순서와 물리적 순서가 일치|인덱스 순서와 물리적 순서가 불일치|


=== 조인의 종류 ===
==== 일관성 ====
일관성(consistency)은 '허용된 방식'으로만 데이터를 변경해야 하는 것을 의미한다. 데이터베이스에 기록된 모든 데이터는 여러 가지 조건, 규칙에 따라 유효함을 가져야 한다. 예를 들어 홍철이는 1000만 원이 있고 범석이는 0원이 있다고 치자. 범석이가 나한테 500만 원을 입금할 수 있을까? 불가능하다. 0원으로부터 500만 원이 나오는 것은 불가능하다.


조인은 두 개이상의 테이블을 묶어 하나의 결과 집합으로 만들어내는 것입니다., 서로 다른 테이블에서 데이터를 가져올 때 사용하는 것이 조인(Join)입니다.
==== 격리성 ====
격리성(isolation)은 트랜잭션 수행 시 서로 끼어들지 못하는 것을 말한다. 복수의 병렬 트랜잭션은 서로 격리되어 마치 순차적으로 실행되는 것처럼 작동되어야 하고, 데이터베이스는 여러 사용자가 같은 데이터에 접근할 수 있어야 한다.


이러한 Join은 총 3가지의 join이 주로 사용됩니다.
격리성은 여러 개의 격리 수준으로 나뉘어 격리성을 보장한다.
![](https://velog.velcdn.com/images/cnj9912/post/b3629745-2f4d-4475-8d04-2d774c7d4e51/image.png)


==== Inner Join(내부 조인) ====
격리 수준은 SERIALIZABLE, REPEATABLE_READ, READ_COMMITTED, READ_UNCOMMITTED가 있으며 위로 갈수록 동시성이 강해지지만 격리성은 약해지고, 아래로 갈수록 동시성은 약해지고 격리서은 강해진다.


* 조인 중 가장 흔히 사용되는 조인입니다. 기본적으로 아래와 같은 쿼리문을 사용할 때도 Inner JOIN이 사용됩니다.
REPEATABLE_READ는 팬텀 리드, READ_COMMITTED는 팬텀 리드, 반복 가능하지 않은 조회가 발생하며, READ_UNCOMMITTED는 팬텀 리드, 반복 가능하지 않은 조회, 더티 리드가 발생할 수도 있다.


USE shopDB
'''격리 수준에 따라 발생하는 현상'''
SELECT *
FROM buyTBL
JOIN userTBL
ON buyTBL.userID = userTBL.userID
WHERE buyTBL.userID = 'LEE';
Inner Join은 대부분 두 table의 교집합을 얘기합니다. 예시로 A와 B가 있다면 A와 B의 교집합을 가져옵니다.


A    B
* 팬텀 리드
* -
  팬텀리드(phantom read)는 한 트랜잭션 내에서 동일한 쿼리를 보냈을 때 해당 조회 결과가 다른 경우를 말한다.
1    3
  예를 들어 사용자 A가 회원 테이블에서 age가 12 이상인 회원들을 조회하는 쿼리를 보낸다고 했을 때, 이 결과로 세 개의 테이블이 조회된다고 해보자. 그 다음 사용자 B가 age가 15인 회원 레코드를 삽입한다. 그러면 그다음 세 개가 아닌 네 개의 테이블이 조회되는 것이다.
2    4
3    5
4    6
위와 같은 테이블이 있다면 Inner Join 작업 수행시 3과 4만이 해당하므로 (3,4)만 결과값으로 도출됩니다.


==== Outer Join ====
* 반복 가능하지 않은 조회
반대되는 개념인 Outer Join은 합집합을 가져오게된다. Outer Join에는 총 3가지의 종류가 존재한다.
  반복 가능하지 않은 조회(non-repeatable read)는 한 트랜잭션 내의 같은 행에 두 번 이상 조회가 발생했는데, 그 값이 다른 경우를 가리킨다. 예를 들어 사용자 A가 큰돌의 보석 개수가 100개라는 값을 가진 데이터였는데, 그 이후 사용자 B가 그 값을 1로 변경해서 커밋했다고 하면 사용자 A는 100이 아닌 1을 읽게 된다.


Left, Right, Full이다.
* 더티 리드
  더티 리드(dirty read)는 반복 가능하지 않은 조회와 유사하며 한 트랜잭션이 실행 중일 때 다른 트랜잭션에 의해 수정되었지만 아직 '커밋되지 않은' 행의 데이터를 읽을 수 있을 때 발생한다. 예를 들어 사용자 A가 큰돌의 보석 개수 100을 1로 변경한 내용이 '커밋되지 않은' 상태라도 그 이후 사용자 B가 조회한 결과가 1로 나오는 경우를 말한다.


Left와 Right는 A와 B를 기준으로 Join할 때 Left Join의 경우 A를 기준으로 합집합을 만든다는 것이고, Right Join의 경우 B를 기준으로 합집합을 만드는 것이다. Full outer Join의 경우 A와 B의 컬럼을 모두 출력하는 합집합을 만든다.
'''격리 수준'''


LEFT outer Join
* SERIALIZABLE
select * from a LEFT OUTER JOIN b on a.a = b.b;
  SERIALIZABLE은 말 그대로 트랜잭션을 순차적으로 진행시키는 것을 말한다. 여러 트랜잭션이 동시에 같은 행에 접근할 수 없다. 이 수준은 매우 엄격한 수준으로 해당 행에 대해 격리시키고, 이후 트랜잭션이 이 행에 대해 일어난다면 기다려야 한다. 그렇기 때문에 교착 상태가 일어날 확률도 많고 가장 성능이 떨어지는 격리 수준이다.
select a.'',b.''  from a,b where a.a = b.b(+);


a |  b
* REPEATABLE_READ
--+-----
  REPEATABLE_READ는 하나의 트랜잭션이 수정한 행을 다른 트랜잭션이 수정할 수 없도록 막아주지만 새로운 행을 ㅜㅊ가하는 것은 막지 않는다. 따라서 이후에 추가된 행이 발견될 수도 있다.
1 | null
2 | null
3 |    3
4 |    4
Right outer Join
select * from a RIGHT OUTER JOIN b on a.a = b.b;
select a.'',b.''  from a,b where a.a(+) = b.b;


a    |  b
* READ_COMMITTED
-----+----
  READ_COMMITTED는 가장 많이 사용되는 격리 수준이며 MySQL8.0, PostgreSQL, SQL Server, 오라클에서 기본값으로 설정되어 있다. READ_UNCOMMITTED와는 달리 다른 트랜잭션이 커밋하지 않은 정보는 읽을 수 없다. 즉, 커밋 완료된 데이터에 대해서만 조회를 허용한다.
3    |  3
  하지만 어떤 트랜잭션이 접근한 행을 다른 트랜잭션이 수정할 수 있다. 예를 들어 트랜잭션 A가 수정한 행을 트랜잭션 B가 수정할 수도 있다. 이 때문에 트랜잭션 A가 같은 행을 다시 읽을 때 다른 내용이 발견될 수도 있다.
4    |  4
null |  5
null |  6
Full outer Join
select * from a FULL OUTER JOIN b on a.a = b.b;


a   |  b
* READ_UNCOMMITTED
-----+-----
   READ_UNCOMMITTED는 가장 낮은 격리 수준으로, 하나의 트랜잭션이 커밋되기 이전에 다른 트랜잭션에 노출되는 문제가 있지만 가장 빠르다. 이는 데이터 무결서을 위해 되도록이면 사용하지 않는 것이 이상적이나, 몇몇 행이 제대로 조회되지 않더라도 괜찮은 거대한 양의 데이터를 '어림잡아' 집계하는 데는 사용하면 좋다.
1 | null
2 | null
3 |    3
4 |    4
null |    6
null |    5
흔히들 알고있는 inner와 outer외에도 CROSS JOIN(상호 조인)이 있습니다.


==== 지속성 ====
지속성(durability)은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 하는 것을 의미한다. 이는 데이터베이스에 시스템 장애가 발생해도 원래 상태로 복구하는 회복 기능이 있어야 함을 뜻하며, 데이터 베이스는 이를 위해 체크섬, 저널링, 롤백 등의 기능을 제공한다.


==== CROSS JOIN ====
> - '''체크섬'''
CROSS JOIN은 한쪽 테이블의 행 하나당 다른 쪽 테이블의 모든 행을 하나씩 모든 행들을 각각 조인합니다.
    중복 검사의 한 형태로, 오류 정정을 통해 송신된 자료의 무결성을 보호하는 단순한 방법
* '''저널링'''
  파일 시스템 또는 시스템에 변경 사항을 반영(commit)하기 전에 로깅하는 것, 트랜잭션 등 변경 사항에 대한 로그를 남기는 것


, A 테이블의 1번 행을 B 테이블의 1번 행에 조인 시키고, 다음은 A 테이블의 1번 행을 B 테이블의 2번 행에 조인시키고 ...생략... 이를 모든 A 테이블의 행에 각각 모든 B 테이블의 행들에 조인합니다. CROSS JOIN의 결과 행의 개수는 [A 테이블 행의 개수 X B 테이블 행의 개수]가 됩니다.
=== 무결성이란? ===
무결성이란 데이터의 정확성, 일관성, 유효성을 유지하는 것을 말하며, 무결성이 유지되어야 데이터베이스에 저장된 데이터 값과 그 값에 해당하는 현실 세계의 실제 값이 일치하는지에 대한 신뢰가 생긴다. 무결성의 종류는 다음과 같다.


CROSS JOIN은 카티션 곱(Catesian Product)이라고도 부릅니다
|이름|설명|
|:|:|
|개체 무결성|기본키로 선택된 필드는 빈 값을 허용하지 않는다.|
|참조 무결성|서로 참조 관계에 있는 두 테이블의 데이터는 항상 일관된 값을 유지해야 한다.|
|고유 무결성|특정 속성에 대해 고유한 값을 가지도록 조건이 주어진 경우 그 속성 값은 모두 고유한 값을 가진다.|
|NULL 무결성|특정 속성 값에 NULL이 올 수 없다는 조건이 주어진 경우 그 속성 값은 NULL이 될 수 없다는 제약 조건이다.|


SELECT * FROM ATable
=== 관계형 데이터베이스 ===
CROSS JOIN BTable;
관계형 데이터베이스(RDBMS)는 행과 열을 가지는 표 형식 데이터를 저장하는 형태의 데이터베이스를 가리키며 SQL이라는 언어를 써서 조작한다. MySQL, PostgreSQL, 오라클, SQL Server, MSSQL 등이 있다. 참고로 관계형 데이터베이스의 경우 표준 SQL은 지키기는 하지만, 각각의 제품에 특화시킨 SQL을 사용한다. 예를 들어 오라클의 경우 PL/SQL이라고 하며 SQL Server에서는 T-SQL, MySQL은 SQL을 쓴다.
기본적인 CROSS JOIN 구문입니다. INNER과 OUTER 조인과 달리 ON 구문은 사용하지 않습니다. SELECT * FROM ATable, BTable; 형식으로 작성할 수도 있는데 호환성 등의 이유로 권장되지 않습니다.


SELF JOIN(자체 조인)은 자신에게 조인하는 것입니다. 같은 테이블에 두 번 참조해야 하는 경우도 있습니다.
==== MySQL ====
MySQL은 대부분의 운영체제와 호환되며 현재 가장 많이 사용하는 데이터베이스이다.


C, C++로 만들어졌으며 MyISAM 인덱스 압축 기술, B-트리 기반의 인덱스, 스레드 기반의 메모리 할당 시스템, 매우 빠른 조인, 최대 64개의 인덱스를 제공한다. 대용량 데이터베이스를 위해 설계되어 있고 롤백, 커밋, 이중 암호 지원 보안 등의 기능을 제공하며 많은 서비스에서 사용한다.


=== 조인 수행원리 ===
MySQL의 스토리지 엔진 아키텍처는 다음과 같다.


조인이란 두 개 이상의 테이블을 하나의 집합으로 만드는 연산이다.
![](https://velog.velcdn.com/images/cnj9912/post/36351d98-60bb-4bf7-aaa2-2252c58e348f/image.png)
SQL문에서 FROM 절에 두 개 이상의 테이블이 나열될 경우 조인이 수행된다. 조인 연산은 두 테이블 사이에서 수행된다. FROM 절에 A, B, C라는 세 개의 테이블이 존재하더라도 세 개의 테이블이 동시에 조인이 수행되는 것은 아니다. 세 개의 테이블 중에서 먼저 두 개의 테이블에 대해 조인이 수행된다. 그리고 먼저 수행된 조인 결과와 나머지 테이블 사이에서 조인이 수행된다. 이러한 작업은 FROM 절에 나열된 모든 테이블을 조인할 때까지 반복 수행한다. 예를 들어, A, B, C 세 개의 테이블을 조인할 때를 가정으로 설명하면 다음과 같다. 먼저 A와 B 두 테이블을 먼저 조인하면 해당 조인 결과와 나머지 C 테이블을 조인한다(A → B → C). 만약, A와 C 테이블을 먼저 조인한다면 해당 조인 결과와 나머지 B 테이블을 조인한다(A → C → B). 테이블 또는 조인 결과를 이용하여 조인을 수행할 때 조인 단계별로 다른 조인 기법을 사용할 수 있다. 예를 들어, A와 B 테이블을 조인할 때는 NL Join 기법을 사용하고 해당 조인 결과와 C 테이블을 조인할 때는 Hash Join 기법을 사용할 수 있다. 조인 기법은 두 개의 테이블을 조인할 때 사용할 수 있는 방법이다. 여기서는 조인 기법 중에서 자주 사용되는
NL Join, Hash Join, Sort Merge Join에 대해서 조인 원리를 간단하게 설명한다.


==== NL Join ====
데이터베이스의 심장과도 같은 역할을 하는 곳이 바로 스토리지 엔진인데, 모듈식 아키텍처로 쉽게 스토리지 엔진을 바꿀 수 있으며 데이터 웨어하우징, 트랜잭션 처리, 고가용성 처리에 강점을 두고 있다. 스토리지 엔진 위에는 커넥터 API 및 서비스 계층을 통해 MySQL 데이터베이스와 쉽게 상호 작용할 수 있다.


NL Join은 프로그래밍에서 사용하는 중첩된 반복문과 유사한 방식으로 조인을 수행한다. 반복문의 외부에 있는 테이블을 선행 테이블 또는 외부 테이블(Outer Table)이라고 하고, 반복문의 내부에 있는 테이블을 후행 테이블 또는 내부 테이블(Inner Table)이라고 한다.
또한, MySQL은 쿼리 캐시를 지원해서 입력된 쿼리 문에 대한 전체 결과 집합을 저장하기 때문에 사용자가 작성한 쿼리가 캐시에 있는 쿼리와 동일하면 서버는 단순히 구문 분석, 최적화 및 실행을 건너뛰고 캐시의 출력만 표시한다.


==== PostgreSQL ====
PosrgreSQL은 MySQL 다음으로 개발자들이 선호하는 데이터베이스 기술이다
![](https://velog.velcdn.com/images/cnj9912/post/44faf8a5-c2ab-44f7-b17e-034ce8130fd1/image.png)


FOR 선행 테이블 읽음 → 외부 테이블(Outer Table) FOR 후행 테이블 읽음 → 내부 테이블(Inner Table) (선행 테이블과 후행 테이블 조인)
디스크 조각이 차지하는 영역을 회수할 수 있는 장치인 VACUUM이 특징이다. 최대 테이블의 크기는 32TB이며 SQL뿐만 아니라 JSON을 이용해서 데이터에 접근할 수 있다. 지정 시간에 복구하는 기능, 로깅, 접근 제어, 중첩된 트랜잭션, 백업 등을 할 수 있다.


먼저 선행 테이블의 조건을 만족하는 행을 추출하여 후행 테이블을 읽으면서 조인을 수행한다. 이 작업은 선행 테이블의 조건을 만족하는 모든 행의 수만큼 반복 수행한다. NL Join에서는 선행 테이블의 조건을 만족하는 행의 수가 많으면(처리 주관 범위가 넓으면), 그 만큼 후행 테이블의 조인 작업은 반복 수행된다. 따라서 결과 행의 수가 적은(처리 주관 범위가 좁은) 테이블을 조인 순서상 선행 테이블로 선택하는 것이 전체 일량을 줄일 수 있다.
=== NoSQL 데이터베이스 ===
NL Join은 랜덤 방식으로 데이터를 액세스하기 때문에 처리 범위가 좁은 것이 유리하다.
NoSQL(Not only SQL)이라는 슬로건에서 생겨난 데이터베이스이다. SQL을 사용하지 않는 데이터베이스를 말하며, 대표적을 MongoDB와 redis 등이 있다.


'''NL Join의 작업 방법은 다음과 같다.'''
==== MongoDB ====
1. 선행 테이블에서 주어진 조건을 만족하는 행을 찾음
![](https://velog.velcdn.com/images/cnj9912/post/3af1de7e-8fc0-4174-97c8-fca3d473aab9/image.png)
2. 테이블의 조인 키 값을 가지고 후행 테이블에서 조인 수행
3. 선행 테이블의 조건을 만족하는 모든 행에 대해 1번 작업 반복 수행


==== HashJoin ====
MongoDB는 JSON을 통해 데이터에 접근할 수 있고, Binary JSON 형태(BSON)로 데이터가 저장되며 와이어드타이거 엔진이 기본 스토리지 엔진으로 장착된 키-값 데이터 모델에서 확장된 도큐먼트 기반의 데이터베이스다. 확장성이 뛰어나며 빅데이터를 저장할 때 성능이 좋고 고가용성과 샤딩, 레플리카셋을 지원한다. 또한, 스키마를 정해 놓지 않고 데이터를 삽입할 수 있기 때문에 다양한 도메인의 데이터베이스를 기반으로 분석하거나 로깅 등을 구현할 때 강점을 봉니다.


Hash Join은 해슁 기법을 이용하여 조인을 수행한다. 조인을 수행할 테이블의 조인 칼럼을 기준으로 해쉬 함수를 수행하여 서로 동일한 해쉬 값을 갖는 것들 사이에서 실제 값이 같은지를 비교하면서 조인을 수행한다. Hash Join은 NL Join의
또한, MongoDB는 도큐먼트가 생성할 때마다 다른 컬렉션에서 중복된 값을 지니기 힘든 유니크한 값인 ObjectID가 생성된다.
랜덤 액세스 문제점과 Sort Merge Join의 문제점인 정렬 작업의 부담을 해결 위한 대안으로 등장하였다.
 
![](https://velog.velcdn.com/images/cnj9912/post/e4b0d64d-e2da-48a3-ae26-9d1b1a74063c/image.png)
 
 
==== redis ====
redis는 인메모리 데이터베이스이자 키-값 데이터 모델 기반의 데이터베이스이다.
 
![](https://velog.velcdn.com/images/cnj9912/post/041eee68-7fa8-42d7-b69f-cbb9e29780ec/image.png)
 
기본적인 데이터 타입은 문자열(string)이며 최대 512MB까지 저장할 수 있다. 이외에도 셋(set), 해시(hash) 등을 지원한다.
 
pub/sub 기능을 통해 채팅 시스템, 다른 데이터베이스 앞단에 두어 사용하는 캐싱 계층, 단순한 키-값이 필요한 세션 정보 관리, 정렬된 셋(sorted set) 자료 구조를 이용한 실시간 순위표 서비스에 사용한다.

2025년 4월 17일 (목) 14:23 기준 최신판

데이터베이스(DB, DataBase)란?

> 일정한 규칙, 혹은 규약을 통해 구조화되어 저장되는 데이터의 모음

해당 데이터베이스를 제어, 관리하는 통합 시스템을 DBMS(DataBase Management System)라고 하며, 데이터베이스 안에 있는 데이터들은 특정 DBMS마다 정의된 쿼리 언어(query language)를 통해 삽입, 삭제, 수정, 조회 등을 수행할 수 있다.

엔티티(entity)란?

>사람, 장소, 물건, 사건, 개념 등 여러 개의 속성을 지닌 명사

약한 엔티티와 강한 엔티티 예를 들어 A가 혼자서는 존재하지 못하고 B의 존재 여부에 따라 종속적이라면 A는 약한 엔티티이고 B는 강한 엔티티가 된다.

릴레이션(relation)란?

>데이터베이스에서 정보를 구분하여 저장하는 기본 단위

엔티티에 관한 데이터를 데이터베이스는 릴레이션 하나에 담아서 관리한다.

릴레이션은 관계형 데이터베이스에서는 '테이블'이라고 하며, NoSQL 데이터베이스에서는 '컬렉션'이라고 한다.

테이블과 컬렉션 데이터 베이스의 종류는 크게 관계형 데이터베이스와 NoSQL 데이터베이스로 나눌 수 있다. 이 중 대표적인 관계형 데이터베이스인 MySQL과 대표적인 NoSQL 데이터베이스인 MongoDB를 예로 들면, MySQL의 구조는 레코드-테이블-데이터베이스로 이루어져 있고 MongoDB 데이터베이스의 구조는 도큐먼트-컬렉션-데이터베이스로 이루어져 있다.

속성(attribute)이란?

>릴레이션에서 관리하는 구체적이며 고유한 이름을 갖는 정보

에를 들어 '차'라는 엔티티의 속성을 뽑아보면, 차 넘버, 바퀴 수, 차 색깔, 차종 등이 있다. 이 중에서 서비스의 요구 사항을 기반으로 관리해야 할 필요가 있는 속성들만 엔티티의 속성이 된다.

도메인(domain)이란?

>릴레이션에 포함된 각각의 속성들이 가질 수 있는 값의 집합

예를 들어 성별이라는 속성이 있다면 이 속성이 가질 수 있는 값은 {남, 여}라는 집합이 된다.

필드와 레코드

앞에서 설명한 것들을 바탕으로 데이터베이스에서 필드와 레코드로 구성된 테이블을 만들 수 있다. ![](https://velog.velcdn.com/images/cnj9912/post/c16b36f4-fe86-4a9c-905a-326b1fdf9bc4/image.png)

고객이란 엔티티는 고객코드, 이름, 전화번호 등의 필드를 가진다. 그리고 이 테이블에 쌓이는 행(row) 단위의 데이터를 레코드라고 한다. 또한 레코드를 튜플이라고도 한다.

관계

데이터베이스에 테이블은 하나만 있는 것이 아니다. 여러 개의 테이블이 있고 이러한 테이블은 서로의 관계가 정의되어 있다. ![](https://velog.velcdn.com/images/cnj9912/post/3edc6d9e-66cf-4ce2-9ece-ae2a48fb24f8/image.png)

1:1 관계 1:1 관계는 테이블을 두 개의 테이블로 나눠 테이블의 구조를 더 이해하기 쉽게 만들어 준다.

예를 들어, 일반적으로 컴퓨터 1대에 1개의 마우스가 있으므로 1:1 관계라고 할 수 있다.

1:N 관계 두 개의 서로 다른 타입의 두 개체들 A와 B가 있을 때, A 개체가 B 개체 여러 개와 연결될 수 있지만 B 개체는 1개의 A 개체만 연결될 수 있는 관계이다.

예를 들어, 컴퓨터는 1개 이상의 USB 드라이브를 인식할 수 있지만 USB 드라이브는 1대의 컴퓨터랑만 연결할 수 있으므로 컴퓨터와 USB 드라이브는 1:N 관계라 할 수 있다.

N:M 관계 학생과 강의의 관계를 정의하면, 학생도 강의를 많이 들을 수 있고 강의도 여러 명의 학생을 포함할 수 있기 때문에 N:M 관계가 된다.

테이블 간의 관계를 조금 더 명확하게 하고 테이블 자체의 인덱스를 위해 설정된 장치로 기본키, 외래키, 후보키, 슈퍼키, 대체키가 있다. ![](https://velog.velcdn.com/images/cnj9912/post/e081c051-4589-465b-9573-70f3e73c7ac9/image.png)

슈퍼키는 유일성이 있고 그 안에 포함된 후보키는 최소성까지 갖춘 키이다. 후보키 중에서 기본키로 선택되지 못한 키는 대체키가 된다. 유일성은 중복되는 값은 없으며, 최소성은 필드를 조합하지 않고 최소 필드만 써서 키를 형성할 수 있는 것을 말한다.

기본키 기본키(Primary Key)는 줄여서 PK 또는 프라이머리키라고 많이 부르며, 유일성과 최소성을 만족하는 키이다.

이는 테이블의 데이터 중 고유하게 존재하는 속성이며 기본키에 해당하는 데이터는 중복되어서는 안된다.

외래키 외래키(Foreign Key)는 FK라고도 하며, 다른 테이블의 기본키를 그대로 참조하는 값으로 개체와의 관계를 식별하는 데 사용한다.

외래키는 중복되어도 상관없다.

후보키 후보키(candidate key)는 기본키가 될 수 있는 후보들이며 유일성과 최소성을 동시에 만족하는 키이다.

대체키 대체키(alternate key)는 후보키가 두 개 이상일 경우 어느 하나를 기본키로 지정하고 남은 후보키들을 말한다.

슈퍼키 슈퍼키(super key)는 각 레코드를 유일하게 식별할 수 있는 유일성을 갖춘 키이다.

ERD(Entity Relationship Diagram)란?

>데이터베이스를 구축할 때 가장 기초적인 뼈대 역할을 하며, 릴레이션 간의 관계들을 정의한 것

만약 서비스를 구축한다면 가장 먼저 신경 써야 할 부분이며 이 부분을 신경 쓰지 않고 서비스를 구축한다면 단단하지 않은 골조로 건물을 짓는 것이나 다름없다.

ERD의 중요성

ERD는 시스템의 요구 사항을 기반으로 작성되며 이 ERD를 기반으로 데이터베이스를 구축한다. 데이터 베이스를 구축한 이후에도 디버깅 또는 비즈니스 프로세스 재설계가 필요한 경우에 설계도 역할을 담당하기도 한다.

하지만 ERD는 관계형 구조로 표혈할 수 있는 데이터를 구성하는 데 유용할 수 있지만 비정형 데이터를 충분히 표현할 수 없다는 단점이 있다. >비정형 데이터 비구조화 데이터를 말하며, 미리 정의된 데이터 모델이 없거나 미리 정의된 방식으로 정리되지 않은 정보를 말한다.

정규화 과정

정규화 과정은 릴레이션 간의 잘못된 종속 관계로 인해 데이터베이스 이상 현상이 일어나서 이를 해결하거나, 저장 공간을 효율적으로 사용하기 위해 릴레이션을 여러 개로 분리하는 과정이다.

데이터베이스 이상 현상이란 회원이 한 개의 등급을 가져야 하는데 세 개의 등급을 갖거나 삭제할 때 필요한 데이터가 같이 삭제되고, 데이터를 삽입해야 하는데 하나의 필드 값이 NULL이 되면 안되어서 삽입하기 어려운 현상을 말한다.

정규화 과정은 정규형 원칙을 기반으로 정규형을 만들어가는 과정이며, 정규화된 정도는 정규형(NF, Normal Form)으로 표현한다. 기본 정규형인 제1정규형, 제2정규형, 제3정규형, 보이스/코드 정규형이 있고 고급 정규형인 제4정규형, 제5정규형이 있다. 이 중 기본 정규형인 제1정규형, 제2정규형, 제3정규형, 보이스/코드 정규형을 알아보겠다.

정규형 원칙 정규형의 원칙이란 같은 의미를 표현하는 릴레이션이지만 좀 더 좋은 구조로 만들어야 하고, 자료의 중복성은 감소해야 하고, 독립적인 관계는 별개의 릴레이션으로 표현해야 하며, 각각의 릴레이션은 독립적인 표현이 가능해야 하는 것을 말한다.

제1정규형 릴레이션의 모든 도메인이 더 이상 분해될 수 없는 원자 값(atomic value)만으로 구성되어야 한다. 릴레이션의 속성 값 중에서 한 개의 기본키에 두해 두 개 이상의 값을 가지는 반복 집합이 있어서는 안 된다. 만약에 반복 집합이 있다면 제거해야 한다. ![](https://velog.velcdn.com/images/cnj9912/post/aed0cfdc-eccb-4e24-bbe1-f2be459785c9/image.png)

예를 들어 위처럼 릴레이션이 이루어져 있다면, 제1 정규형을 만족하지 못한다. 학번이 100인 학생의 과목 번호와 성적이 2개로 이루어져 있기 때문이다. 따라서 제1 정규형이 되려면 다음과 같이 속성 값을 분리해주어야 한다. ![](https://velog.velcdn.com/images/cnj9912/post/75a16d5b-ead9-40b7-84c3-0698233c3844/image.png)

제2정규형 릴레이션이 제1정규형이며 부분 함수의 종속성을 제거한 형태를 말한다.

부분 함수의 종속성 제거란 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속적인 것을 말한다. ![](https://velog.velcdn.com/images/cnj9912/post/632bd8c5-5bbe-4250-8d60-660d70e7ab2a/image.png)

위 그림처럼 각 속성들이 모두 완전 함수 종속이 되도록 릴레이션을 분리시켜준다. 따라서 아래와 같이 릴레이션이 형성된다.

![](https://velog.velcdn.com/images/cnj9912/post/9006b4f1-ede4-4096-9e3d-18cf03b729b6/image.png)

이 때 주의할 점은 릴레이션을 분해할 때 동등한 릴레이션을 분해해야 하고, 정보 손실이 발생하지 않는 무손실 분해로 분해되어야 한다는 것이다.

제3정규형 제2정규형이고 기본키가 아닌 모든 속성이 이행적 함수 종속(transitive FD)을 만족하지 않는 상태를 말한다.

>이행적 함수 종속 A -> B와 B -> C가 존재하면 논리적으로 A -> C가 성립하는데, 이때 집합 C가 집합 A에 이행적으로 함수 종속이 되었다고 한다.

![](https://velog.velcdn.com/images/cnj9912/post/6c2c94d6-e340-4299-ad9f-0be41a0ca2ea/image.png)

이렇게 이행적 함수 종속 관계에 있는 속성을 분리한다. 테이블로 나타내면 아래와 같다.

![](https://velog.velcdn.com/images/cnj9912/post/608eee97-9762-4f49-ac1b-78c579df0fc1/image.png)

보이스/코드 정규형 보이스/코드 정규형(BCNF)은 제3정규형이고, 결정자가 후보키가 아닌 함수 종속 관계를 제거하여 릴레이션의 함수 종속 관계에서 모든 결정자가 후보키인 상태를 말한다. >결정자 함수 종속 관계에서 특정 종속자(dependent)를 결정짓는 요소, 'X -> Y'일 때 X는 결정자, Y는 종속자이다.

아래와 같은 제3 정규형을 만족하는 릴레이션이 있다고 가정하자. 한 교수당 하나의 수업만 맡는다고 가정한다.

![](https://velog.velcdn.com/images/cnj9912/post/499ecc11-9c94-48fc-92b4-9bb2b268d4d2/image.png)

모든 결정자는 항상 후보키가 되도록 릴레이션을 분해해주면 강한 제3 정규형, 즉 BCNF를 만족하게 된다. ![](https://velog.velcdn.com/images/cnj9912/post/0d251558-4cb8-4e12-992b-d6b1c0a65e58/image.png)

트랜잭션이란?

> 데이터베이스에서 하나의 논리적 기능을 수행하기 위한 작업의 단위

데이터베이스에 접근하는 방법은 쿼리이므로, 즉 여러 개의 쿼리들을 하나로 묶는 단위를 말한다. 이에 대한 특징은 원자성, 일관성, 독립성, 지속성이 있으며 이를 한꺼번에 ACID 특징이라고 한다.

원자성

"all or nothing"

원자성(atomicity)은 트랜잭션과 관련된 일이 모두 수행되었거나 되지 않았거나를 보장하는 특징이다. 예를 들어 트랜잭션을 커밋했는데, 문제가 발생하여 롤백하는 경우 그 이후에 모두 수행되지 않음을 보장하는 것을 말한다.

또한, 트랜잭션 단위로 여러 로직들을 묶을 때 외부 API를 호출하는 것이 있으면 안 된다. 만약 있다면 롤백이 일어났을 때 어떻게 해야 할 것인지에 대한 해결 방법이 있어야 하고 트랜잭션 전파를 신경 써서 관리해야 한다.

커밋과 롤백 커밋(commit)은 여러 쿼리가 성공적으로 처리되었다고 확정하는 명령어이다. 트랜잭션 단위로 수행되며 변경된 내용이 모두 영구적으로 저장되는 것을 말한다. "커밋이 수행되었다."를 "하나의 트랜잭션이 성공적으로 수행되었다."라고도 말한다.

update, insert, delete의 쿼리가 하나의 트랜잭션 단위로 수행되고 이후에 데이터베이스에 영구 저장된다.

하지만 에러나 여러 이슈 때문에 트랜잭션 전으로 돌려야 한다면 어떻게 해야 할까?

이때 사용하는 것이 롤백이다. 롤백이란 트랜잭션으로 처리한 하나의 묶음 과정을 일어나기 전으로 돌리는 일(취소)을 말한다.

이러한 커밋과 롤백 덕에 데이터의 무결성이 보장된다. 또한, 데이터 변경 전에 변경 사항을 쉽게 확인할 수 있고 해당 작업을 그룹화할 수 있다.

트랜잭션 전파 트랜잭션을 수행할 때 커넥션 단위로 수행하기 때문에 커넥션 객체를 넘겨서 수행해야 한다. 하지만 이를 매번 넘겨주기가 어렵기도 하고 귀찮다. 이를 넘겨서 수행하지 않고 여러 트랜잭션 관련 메서드의 호출을 하나의 트랜잭션에 묶이도록 하는 것을 트랙잭션 전파라고 한다.

java
@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)은 트랜잭션 수행 시 서로 끼어들지 못하는 것을 말한다. 복수의 병렬 트랜잭션은 서로 격리되어 마치 순차적으로 실행되는 것처럼 작동되어야 하고, 데이터베이스는 여러 사용자가 같은 데이터에 접근할 수 있어야 한다.

격리성은 여러 개의 격리 수준으로 나뉘어 격리성을 보장한다. ![](https://velog.velcdn.com/images/cnj9912/post/b3629745-2f4d-4475-8d04-2d774c7d4e51/image.png)

격리 수준은 SERIALIZABLE, REPEATABLE_READ, READ_COMMITTED, READ_UNCOMMITTED가 있으며 위로 갈수록 동시성이 강해지지만 격리성은 약해지고, 아래로 갈수록 동시성은 약해지고 격리서은 강해진다.

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로 나오는 경우를 말한다.

격리 수준

  • SERIALIZABLE
 SERIALIZABLE은 말 그대로 트랜잭션을 순차적으로 진행시키는 것을 말한다. 여러 트랜잭션이 동시에 같은 행에 접근할 수 없다. 이 수준은 매우 엄격한 수준으로 해당 행에 대해 격리시키고, 이후 트랜잭션이 이 행에 대해 일어난다면 기다려야 한다. 그렇기 때문에 교착 상태가 일어날 확률도 많고 가장 성능이 떨어지는 격리 수준이다.
  • REPEATABLE_READ
 REPEATABLE_READ는 하나의 트랜잭션이 수정한 행을 다른 트랜잭션이 수정할 수 없도록 막아주지만 새로운 행을 ㅜㅊ가하는 것은 막지 않는다. 따라서 이후에 추가된 행이 발견될 수도 있다.
  • READ_COMMITTED
 READ_COMMITTED는 가장 많이 사용되는 격리 수준이며 MySQL8.0, PostgreSQL, SQL Server, 오라클에서 기본값으로 설정되어 있다. READ_UNCOMMITTED와는 달리 다른 트랜잭션이 커밋하지 않은 정보는 읽을 수 없다. 즉, 커밋 완료된 데이터에 대해서만 조회를 허용한다.
 하지만 어떤 트랜잭션이 접근한 행을 다른 트랜잭션이 수정할 수 있다. 예를 들어 트랜잭션 A가 수정한 행을 트랜잭션 B가 수정할 수도 있다. 이 때문에 트랜잭션 A가 같은 행을 다시 읽을 때 다른 내용이 발견될 수도 있다.
  • READ_UNCOMMITTED
 READ_UNCOMMITTED는 가장 낮은 격리 수준으로, 하나의 트랜잭션이 커밋되기 이전에 다른 트랜잭션에 노출되는 문제가 있지만 가장 빠르다. 이는 데이터 무결서을 위해 되도록이면 사용하지 않는 것이 이상적이나, 몇몇 행이 제대로 조회되지 않더라도 괜찮은 거대한 양의 데이터를 '어림잡아' 집계하는 데는 사용하면 좋다.

지속성

지속성(durability)은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 하는 것을 의미한다. 이는 데이터베이스에 시스템 장애가 발생해도 원래 상태로 복구하는 회복 기능이 있어야 함을 뜻하며, 데이터 베이스는 이를 위해 체크섬, 저널링, 롤백 등의 기능을 제공한다.

> - 체크섬

   중복 검사의 한 형태로, 오류 정정을 통해 송신된 자료의 무결성을 보호하는 단순한 방법
  • 저널링
 파일 시스템 또는 시스템에 변경 사항을 반영(commit)하기 전에 로깅하는 것, 트랜잭션 등 변경 사항에 대한 로그를 남기는 것

무결성이란?

무결성이란 데이터의 정확성, 일관성, 유효성을 유지하는 것을 말하며, 무결성이 유지되어야 데이터베이스에 저장된 데이터 값과 그 값에 해당하는 현실 세계의 실제 값이 일치하는지에 대한 신뢰가 생긴다. 무결성의 종류는 다음과 같다.

|이름|설명| |:|:| |개체 무결성|기본키로 선택된 필드는 빈 값을 허용하지 않는다.| |참조 무결성|서로 참조 관계에 있는 두 테이블의 데이터는 항상 일관된 값을 유지해야 한다.| |고유 무결성|특정 속성에 대해 고유한 값을 가지도록 조건이 주어진 경우 그 속성 값은 모두 고유한 값을 가진다.| |NULL 무결성|특정 속성 값에 NULL이 올 수 없다는 조건이 주어진 경우 그 속성 값은 NULL이 될 수 없다는 제약 조건이다.|

관계형 데이터베이스

관계형 데이터베이스(RDBMS)는 행과 열을 가지는 표 형식 데이터를 저장하는 형태의 데이터베이스를 가리키며 SQL이라는 언어를 써서 조작한다. MySQL, PostgreSQL, 오라클, SQL Server, MSSQL 등이 있다. 참고로 관계형 데이터베이스의 경우 표준 SQL은 지키기는 하지만, 각각의 제품에 특화시킨 SQL을 사용한다. 예를 들어 오라클의 경우 PL/SQL이라고 하며 SQL Server에서는 T-SQL, MySQL은 SQL을 쓴다.

MySQL

MySQL은 대부분의 운영체제와 호환되며 현재 가장 많이 사용하는 데이터베이스이다.

C, C++로 만들어졌으며 MyISAM 인덱스 압축 기술, B-트리 기반의 인덱스, 스레드 기반의 메모리 할당 시스템, 매우 빠른 조인, 최대 64개의 인덱스를 제공한다. 대용량 데이터베이스를 위해 설계되어 있고 롤백, 커밋, 이중 암호 지원 보안 등의 기능을 제공하며 많은 서비스에서 사용한다.

MySQL의 스토리지 엔진 아키텍처는 다음과 같다.

![](https://velog.velcdn.com/images/cnj9912/post/36351d98-60bb-4bf7-aaa2-2252c58e348f/image.png)

데이터베이스의 심장과도 같은 역할을 하는 곳이 바로 스토리지 엔진인데, 모듈식 아키텍처로 쉽게 스토리지 엔진을 바꿀 수 있으며 데이터 웨어하우징, 트랜잭션 처리, 고가용성 처리에 강점을 두고 있다. 스토리지 엔진 위에는 커넥터 API 및 서비스 계층을 통해 MySQL 데이터베이스와 쉽게 상호 작용할 수 있다.

또한, MySQL은 쿼리 캐시를 지원해서 입력된 쿼리 문에 대한 전체 결과 집합을 저장하기 때문에 사용자가 작성한 쿼리가 캐시에 있는 쿼리와 동일하면 서버는 단순히 구문 분석, 최적화 및 실행을 건너뛰고 캐시의 출력만 표시한다.

PostgreSQL

PosrgreSQL은 MySQL 다음으로 개발자들이 선호하는 데이터베이스 기술이다 ![](https://velog.velcdn.com/images/cnj9912/post/44faf8a5-c2ab-44f7-b17e-034ce8130fd1/image.png)

디스크 조각이 차지하는 영역을 회수할 수 있는 장치인 VACUUM이 특징이다. 최대 테이블의 크기는 32TB이며 SQL뿐만 아니라 JSON을 이용해서 데이터에 접근할 수 있다. 지정 시간에 복구하는 기능, 로깅, 접근 제어, 중첩된 트랜잭션, 백업 등을 할 수 있다.

NoSQL 데이터베이스

NoSQL(Not only SQL)이라는 슬로건에서 생겨난 데이터베이스이다. SQL을 사용하지 않는 데이터베이스를 말하며, 대표적을 MongoDB와 redis 등이 있다.

MongoDB

![](https://velog.velcdn.com/images/cnj9912/post/3af1de7e-8fc0-4174-97c8-fca3d473aab9/image.png)

MongoDB는 JSON을 통해 데이터에 접근할 수 있고, Binary JSON 형태(BSON)로 데이터가 저장되며 와이어드타이거 엔진이 기본 스토리지 엔진으로 장착된 키-값 데이터 모델에서 확장된 도큐먼트 기반의 데이터베이스다. 확장성이 뛰어나며 빅데이터를 저장할 때 성능이 좋고 고가용성과 샤딩, 레플리카셋을 지원한다. 또한, 스키마를 정해 놓지 않고 데이터를 삽입할 수 있기 때문에 다양한 도메인의 데이터베이스를 기반으로 분석하거나 로깅 등을 구현할 때 강점을 봉니다.

또한, MongoDB는 도큐먼트가 생성할 때마다 다른 컬렉션에서 중복된 값을 지니기 힘든 유니크한 값인 ObjectID가 생성된다.

![](https://velog.velcdn.com/images/cnj9912/post/e4b0d64d-e2da-48a3-ae26-9d1b1a74063c/image.png)


redis

redis는 인메모리 데이터베이스이자 키-값 데이터 모델 기반의 데이터베이스이다.

![](https://velog.velcdn.com/images/cnj9912/post/041eee68-7fa8-42d7-b69f-cbb9e29780ec/image.png)

기본적인 데이터 타입은 문자열(string)이며 최대 512MB까지 저장할 수 있다. 이외에도 셋(set), 해시(hash) 등을 지원한다.

pub/sub 기능을 통해 채팅 시스템, 다른 데이터베이스 앞단에 두어 사용하는 캐싱 계층, 단순한 키-값이 필요한 세션 정보 관리, 정렬된 셋(sorted set) 자료 구조를 이용한 실시간 순위표 서비스에 사용한다.