[면접을 위한 CS 전공 지식 노트] 4주차 - 4장 데이터베이스

4.1 DB의 기본

데이터베이스 ⇒ 일정한 규칙/규약을 통해 구조화되어 저장되는 데이터의 모음

DBMS database mangement system ⇒ 이러한 DB를 제어 & 관리하는 통합 시스템

ex) DBMS ⇒ MySQL, 응용 프로그램 ⇒ Node.js

엔터티 entity

⇒ 여러 개의 속성을 지닌 명사

ex) 회원이라는 엔터티 있으면 이름, 아이디, 주소, 전화번호의 속성을 가짐

약한 엔터티 & 강한 엔터티

⇒ A가 혼자서 존재하지 못함. B의 존재 여부에 따라 종속적

• 약한 엔터티 ⇒ A
• 강한 엔터티 ⇒ B

ex) 방은 건물 안에만 존재함. 즉, 방은 약한 엔터티, 건물은 강한 엔터티

릴레이션 relation

⇒ DB에서 정보를 구분하여 저장하는 기본 단위

• 관계형 DB에서는 ‘테이블’ table
• NoSQL DB에서는 ‘컬렉션 collection

테이블 & 컬렉션

• 관계형 DB - MySQL
  • 레코드-테이블-DB
• NoSQL - MongoDB
  • 도큐먼트-컬렉션-DB

속성 attribute

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

도메인 domain

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

필드 field & 레코드 record

• DB에서 필드와 레코드로 구성된 테이블 만들 수 있음
• 레코드 == 튜플

  

필드 타입

1. 숫자타입 : TINYINT SMALLINT MEDIUMINT INT BIGINT

   

   2. 날짜타입 : DATE DATETIME TIMESTAMP
   • DATE → 날짜만 있음, 시간 X, 3 바이트, 1000-01-01 ~ 9999-12-31
   • DATETIME → 날짜+시간, 8 바이트, 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59
   • TIMESTAMP → 날짜+시간, 4 바이트, 1970-01-01 00:00:01 ~ 2038-01-19 03:14:07

DATETIME & TIMESTAMP의 차이점

• TIMESTAMP는 사용자의 별도 입력이 없으면 데이터가 마지막으로 입력되거나 변경된 시간이 저장되며 기본적으로 NOT NULL이다. DATETIME은 데이터 값을 입력해주어야만 날짜가 입력이 된다. (default 값을 설정해준 경우 제외)
• DATETIME은 시스템의 TIME_ZONE이 변경되어도 값이 변하지 않지만, TIMESTAMP는 시스템의 TIME_ZONE에 의존한다.
• DATETIME은 문자형으로 저장되고, TIMESTAMP는 숫자형으로 저장된다.(1970년 1월 1일 자정을 기준으로 몇 초가 지났는지를 저장)
• Timestamp 타입을 갖는 쿼리는 캐시로 저장되나 Datetime 타입을 갖는 쿼리는 캐시로 저장되지 않는다.

3.문자 타입 : CHAR VARCHAR TEXT BLOB ENUM SET

• CHAR → 고정 길이 문자열, 0~255
• ex) CHAR(100)으로 선언해서 5글자만 저장해도 100바이트로 저장함
• VARCHAR → 가변 길이 문자열, 0~65,535
• TEXT → 큰 문자열 저장
• ex) 게시판의 본문 텍스트 저장할때
• BLOB → 이미지, 동영상, 하지만 보통 AWS S3와 같은 서버 이용하여 파일을 올리고 파일에 관한 경로를 VARCHAR로 저장함
• ENUM & SET → 문자열 열거

관계

⇒ 여러 개의 테이블이 있고 이러한 테이블은 서로의 관계가 정의되어 있음

1:1 관계

⇒ 테이블을 두 개의 테이블로 나눠 구조를 더 이해하기 쉽게 만들어줌

ex) 유저당 유저 이메일은 한 개씩

1:N 관계

⇒ 한 개체가 다른 많은 개체를 포함하는 관계

ex) 쇼핑몰에서 한 유저 당 여러 개의 상품을 장바구니애 넣을때

N:M 관계

⇒ 테이블 2개를 직접적으로 연결해서 구축 X, 1:N과 1:M이라는 관계를 갖는 테이블 2개로 나눠서 설정

ex) 학생과 강의의 관계 (둘다 서로 여러개 포함할 수 있음)

키 key

⇒ 테이블 간의 관계를 더 명확하게 하고 테이블 자체의 인덱스를 위해 설정된 장치

기본키 primary key

• PK
• 유일성 & 최소성
• 테이블의 데이터 중 고유하게 존재하는 속성
• 자연키 & 인조키 중에 골라서 설정 ⇒ 보통 기본키는 인조키로 설정함
• 자연키
  • 중복된 값들을 제외하며 중복되지 않는 것을 자연스레 뽑다가 나오는 키
  • 언제나 변하는 속성을 가짐
• 인조키
  • 인위적으로 고유 식별자를 만드는것
  • 변하지 않음

외래키 foreign key

• FK
• 다른 테이블의 기본키를 그대로 참조하는 값으로 개체와의 관계를 식별하는데 사용함
• 중복되어도 괜찮음

후보키 candidate key

• 기본키가 될 수 있는 후보들
• 유일성 & 최소성

대체키 alternate key

• 후보키가 2개 이상이면 어느 하나를 기본키로 저장하고 남은 후보키들을 가리킴

슈퍼키 super key

• 각 레코드를 유일하게 식별할 수 있는 유일성을 갖춘 키

4.2 ERD와 정규화 normalization 과정

• ERD entity relationship diagram ⇒ 릴레이션 간의 관계를 정의

ERD의 중요성

• 시스템의 요구사항을 기반으로 작성 → 따라서 이 ERD 기반으로 DB 구축
• 단점: 비정형(비구조화) 데이터 표현하기가 어려움

예시 - 승원 영업부서의 ERD

요구 사항

• 영업사원은 0~n명의 고객을 관리한다
• 고객은 0~n개의 주문을 넣을 수 있다
• 주문에는 1~n개의 상품이 들어간

  

예시 - 무무오브레전드의 ERD

요구 사항

• 선수들은 1명의 챔피언을 고를 수 있다
• 챔피언은 한 개 이상의 스킬을 갖는다
• 스킬은 한 개 이상의 특성을 갖는다

  

정규화 과정

⇒ 릴레이션 간의 잘못된 종속 관계로 인해 DB 이상 현상이 일어나서 이를 해결하기 위해, 저장 공간을 효율적으로 사용하기 위해 릴레이션을 여러 개로 분리하는 과정

이상 현상

• 삽입 이상
• 삭제 이상
• 갱신 이상

정규형 원칙

• 같은 의미하는 릴레이션을 좀 더 좋은 구조
• 자료의 중복성은 감소
• 독립적인 관계는 별개의 릴레이션으로 표현
• 각각의 릴레이션은 독립적인 표현이 가능해야 함

제1정규형

⇒ 릴레이션의 모든 도메인 더 이상 분해될 수 없는 원자 값만으로 구성되어야 함

제2정규형

⇒ 1NF + 부분 함수의 종속성을 제거한 형태(=기본키가 아닌 모든 속성이 기본키에 완전 함수 종속)

제3정규형

⇒ 2NF + 기본키가 아닌 모든 속성이 이행적 함수 종속을 만족하지 않은 상태

이행적 함수 종속: A→B와 B→C가 존재하면 논리적으로 A→C 성립

보이스/코드 정규형 BCNF

⇒ 3NF + 결정자가 후보키가 아닌 함수 종속 관계를 제거하여 릴레이션의 함수 종속 관계에서 모든 결정자가 후보키인 상태

4.3 트랜잭션 transaction & 무결성 integrity

트랜잭션 transaction

⇒ DB에서 하나의 논리적 기능을 수행하기 위한 작업의 단위를 말함

원자성 atomicity

⇒ 트랜잭션과 관련된 일이 모두 수행되었거나 되지 않았거나를 보장하는 특징

• all or nothing
• ex) 커밋과 롤백 수행하는 것
• 트랜잭션 단위로 여러 로직들을 묶을 때 외부 API를 호출하는 것이 있으면 안됨
• COMMIT
  • 여러 쿼리가 성공적으로 처리되었다고 확정하는 명령어
  • 트랜잭션 단위로 수행되며 변경된 내용이 모두 영국적으로 저장된다는 것을 말함
  • 커밋이 수행됨 === 하나의 트랜잭션이 성공적으로 수행됨

    

• ROLLBACK
  • 트랜잭션으로 처리한 하나의 묶음 과정을 일어나기 전으로 돌리는 일 ⇒ 취소
  • 커밋과 롤백 덕에 데이터의 무결성이 보장됨

    

트랜잭션 전파

• 트랜잭션 수행할 때 커넥션 단위로 수행하기 때문에 커넥션 객체를 넘겨서 수행해야 함.

⇒ 넘겨서 수행하지 않고 여러 트랜잭션 관련 메서드 호출을 하나의 트랜잭션에 묶이도록 하는 것을 트랜잭션 전파

일관성 consistency

⇒ 허용된 방식으로만 데이터 변경해야 하는 것

• ex) 통장에 0원이 있는데 500만원 이체하는건 불가

격리성 isolation

⇒ 트랜잭션 수행 시 서로 끼어들지 못하는 것

• 복수의 병렬 트랜잭션 → 서로 격리되어 순차적으로 실행되는 것처럼 작동해야 함
• 여러 사용자가 데이터베이스에 접근 시 같은 데이터에 접근해야 함 → 여러개의 격리 수준으로 나누어 격리성 보장

  

격리 수준에 따라 발생하는 현상

• 팬텀 리드 phantom read
  • 한 트랜잭션 내에서 동일한 쿼리를 보냈을 때 해당 조회 결과가 다른 경우
• 반복 가능하지 않은 조회 non-repeatable read
  • 한 트랜잭션 내의 같은 행에 2번 이상 조회 발생했으나, 그 값이 다른 경우
  • 팬텀 리드는 다른 행이 선택될 수도 있는 것 의미, 반복 가능하지 않은 조회는 행 값이 달라질 수도 있다는 것 의미
• 더티 리드 dirty read
  • 한 트랜잭션이 실행 중일 때 다른 트랜잭션에 의해 수정되었으나, 아직 커밋되지 않은 행의 데이터 읽을 수 있는 경우

격리 수준

SERIALIZABLE REPEATABLE_READ READ_COMMITTED READ_UNCOMMITTED

- 순차적으로 트랜잭션 진행	- 하나의 트랜잭션이 수정한 행을 다른 트랜잭션이 수정할 수 없도록 막아주나, 새로운 행을 추가하는 것은 막아주지 X	- 가장 많이 사용되는 격리 수준	- 가장 낮은 격리 수준
- 여러 트랜잭션이 동시에 같은 행에 접근 불가	- MySQL8.0의 innoDB 기본값	- PostgreSQL, SQL Server, 오라클에서 기본값으로 설정	- 하나의 트랜잭션이 커밋되기 전에 다른 트랜잭션에 노출될 수 있으나 가장 빠름
- 매우 엄격한 수준		- 다른 트랜잭션이 커밋하지 않은 정보 읽을 수 X (커밋 완료된 데이터만 조회 허용)	- 데이터 무결성을 위해 되도록 사용하지 않는 것이 좋으나, 거대한 양의 데이터를 어림잡아 집계 시 사용하면 좋음
- 해당 행에 대해 격리, 이후 이 행에 대해 트랜잭션 발생 시 기다려야 함		- but 어떤 트랜잭션이 접근한 행을 다른 트랜잭션이 수정 가능
- 교착상태 발생 확률 ⬆️, 가장 성능 ⬇️

지속성 durability

⇒ 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함

• 데이터베이스에 시스템 장애가 발생해도 원래 상태로 복구될 수 있어야 함
• 이를 위해 체크섬, 저널링, 롤백 등의 기능 제공

체크섬

• 중복 검사의 한 형태
• 오류 정정을 통해 송신된 자료의 무결성 보호하는 방법

저널링

• 파일 시스템 또는 데이터베이스 시스템에 변경 사항을 반영(commit)하기 전에 로깅하는 것
• 트랜잭션 등 변경 사항에 대한 로그 남기는 것

무결성

⇒ 데이터의 정확성, 일관성, 유효성 유지하는 것

이름 설명

개체 무결성	기본키로 선택된 필드에 빈 값이 들어가면 안됨
참조 무결성	서로 참조 관계에 있는 두 테이블의 데이터는 항상 일관되어야 함
고유 무결성	특정 속성에 대해 고유한 값을 가지도록 설정된 경우, 해당 속성값은 모두 고유한 값 가짐
NULL 무결성	특정 속성 값에 NOT NULL 조건이 주어진 경우, 해당 속성값은 NULL이 될 수 없음

4.4 데이터베이스의 종류

관계형 데이터베이스 RDBMS

⇒ 행과 열을 가지는 표 형식 데이터를 저장하는 형태의 데이터베이스

• SQL 사용해서 조작
• 표준 SQL 지키지만 각각의 제품에 특화된 SQL 사용
• 종류: MySQL, PostgreSQL, 오라클, SQL Server, MSSQL 등

MySQL

⇒ 현재 가장 많이 사용하는 데이터베이스며 대부분의 운영체제와 호환됨

• C, C++로 만들어짐
• MyISAM 인덱스 압축 기술, B-트리 기반의 인덱스, 스레드 기반의 메모리 할당 시스템, 매우 빠른 조인, 최대 64개의 인덱스 제공
• 대용량 데이터베이스를 위해 설계
• 롤백, 커밋, 이중 암호 지원 보안 등의 기능 제공

  

• 모듈식 아키텍처 → 스토리지 엔진 쉽게 교체 가능
• 강점: 데이터 웨어하우징, 트랜잭션 처리, 고가용성 처리
• 스토리지 엔진 위에 커넥터 API 및 서비스 계층 두어 MySQL 데이터베이스와 쉽게 상호작용 가능
• 쿼리 캐시 지원
  • 입력된 쿼리문에 대한 전체 결과 집합 저장
  • 사용자가 작성한 쿼리가 캐시에 있는 쿼리와 동일하면 서버는 구문 분석, 최적화 및 실행 건너뛰고 캐시 출력만 표시함

PostgreSQL

⇒ MySQL 다음으로 개발자들이 선호하는 데이터베이스 기술

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

NoSQL 데이터베이스

• SQL 사용하지 않는 데이터베이스
• Not only SQL이라는 슬로건에서 발생
• 종류: MongoDB, redis

MongoDB

⇒ 와이어드타이거 엔진이 기본 스토리지 엔진으로 장착된 키-값 데이터 모델에서 확장된 도큐먼트 기반의 데이터베이스

• JSON 통해 데이터에 접근 가능
• Binary JSON 형태(BJSON)로 데이터 저장됨
• 확장성 좋음
• 빅데이터 저장 시 성능 좋음
• 고가용성, 샤딩, 레플리카셋 지원
• 스키마 정해놓지 않고 데이터 삽입 => 다양한 도메인의 데이터베이스 기반으로 분석 또는 로깅 등 구현 시 좋음
• 도큐먼트 생성시마다 ObjectID 생성됨

redis

⇒ 인메모리 데이터베이스 & 키-값 데이터 모델 기반의 데이터베이스

• 기본적인 데이터 타입: 문자열 (string)
• 최대 512MB까지 저장 가능
• 셋(set), 해시(hash) 등 지원
• pub/sub 기능을 통해 채팅 시스템, 다른 데이터베이스 앞단에 두고 사용하는 캐싱 계층, 단순한 키-값이 필요한 세션 정보 관리, 정렬된 셋(sorted set) 자료 구조를 이용한 실시간 순위표 서비스에 사용

4.5 인덱스 index

인덱스의 필요성

⇒ 데이터를 빠르게 찾을 수 있는 장치, 따라서 인덱스 설정 시 테이블 안에 내가 찾고자 하는 데이터를 빠르게 찾을 수 있음

B-트리

• 인스는 보통 B-트리 자료 구조로 구성
• 루트 노드, 리프 노드, 루트 노드와 리프 노드 사이에 있는 브랜치 노드로 구성

  

인덱스가 효율적인 이유 & 대수확장성

⇒ 효율적인 단계를 거쳐 모든 요소에 접근할 수 있는 균형 잡인 트리 구조와 트리 깊이의 대수확장성 때문

• 대수확장성
  • 트리 깊이가 리프 노드 수에 비해 매우 느리게 성장하는 것
  • 기본적으로 인덱스가 한 깊이씩 증가할 때마다 최대 인덱스 항목의 수는 4배씩 증가함

    

인덱스 만드는 방법

MySQL

1. 클러스터형 인덱스
   • 테이블당 하나 설정 가능
   • primary key 옵션으로 생성
   • 기본키로 만들지 않고, unique not null 옵션 사용
2. 세컨더리 인덱스
   • create index... 명령어 기반으로 생성
   • 보조 인덱스
   • 여러 개의 필드 값 기반으로 쿼리 많이 보낼 때 생성

MongoDB

• 도큐먼트 생성시 자동으로 ObjectID 형성, 해당 키가 기본키로 설정됨
• 부가적으로 세컨더리키도 설정해서 기본키와 세컨더리 키를 같이 사용하는 복합 인덱스 설정 가능

인덱스 최적화 기법

1) 인덱스는 비용이다

• 인덱스 리스트 → 컬렉션 순으로 탐색하므로 인덱스는 2번 탐색하도록 함 → 관련 읽기 비용 듦
• 컬렉션 수정 시 인덱스도 수정되어야 함
• 쿼리에 있는 필드에 인덱스 모두 설정하면 안됨
• 컬렉션에서 가져와야하는 데이터가 많을수록 인덱스 사용하는 것 → 비효율적

2) 항상 테스팅하기

• 서비스 특징에 따라 인덱스 최적화 기법이 달라지므로 항상 테스팅해야 함
• explain() 함수 통해 인덱스 만들고, 쿼리 보낸 이후에 테스팅하며 걸리는 시간 최소화해야 함

3) 복합 인덱스는 같음, 정렬, 다중 값, 카디널리티 순

• 여러 필드 기반으로 조회 시 복합 인덱스 생성 → 이 인덱스 생성 시 같음, 정렬, 다중 값, 카디널리티 순으로 생성해야 함
• 인덱스 생성 순서에 따라 성능 달라짐

==이나 equal이라는 쿼리 있으면 가장 먼저 인덱스로 설정정렬에 쓰는 필드를 그 다음 인덱스로 설정다중 값을 출력해야 하는 필드 (쿼리 자체가 >, < 등 많은 값 출력) 그 다음 인덱스로 설정카디널리티가 높은 순서 기반으로 인덱스 생성(카디널리티: 유니크한 값의 정도)

4.6 조인 join

⇒ 2개 이상의 테이블을 묶어서 하나의 결과물 만드는 것

• MongoDB → 관계형 데이터베이스보다 조인 연산(lookup) 성능이 떨어지므로 조인 작업이 많은 경우 관계형 데이터베이스 사용하는 것이 좋음

내부 조인 inner join

⇒ 두 테이블 간의 교집합

SELECT * FROM TableA A
INNER JOIN TableB B ON
A.key = B.key

왼쪽 조인 left outer join

⇒ 왼쪽 테이블의 모든 행 결과 테이블에 표시

SELECT * FROM TableA A
LEFT JOIN TableB B ON
A.key = B.key

오른쪽 조인 right outer join

⇒ 오른쪽 테이블의 모든 행 결과 테이블에 표시

SELECT * FROM TableA A
RIGHT JOIN TableB B ON
A.key = B.key

합집합 조인 full outer join

⇒ 왼쪽, 오른쪽 테이블의 모든 레코드 집합 생성

SELECT * FROM TableA A
FULL OUTER JOIN TableB B ON
A.key = B.key

4.7 조인의 원리

중첩 루프 조인 NLJ Nested Loop Join

⇒ 조건에 맞는 조인 하는 방법 (중첩 for문과 같은 원리)

• 랜덤 접근에 대한 비용 ⬆️ → 대용량의 테이블에서는 사용 X
• ex) t1, t2 테이블을 조인하는 경우
  • 첫 번째 테이블에서 행을 하나씩 읽고, 그 다음 테이블에서도 행을 하니씩 읽어 조건에 맞는 레코드를 찾아 결괏값 반환

+) 블록 중첩 루프 조인 (BNL, Block Nested Loop)

• 조인할 테이블을 작은 블록으로 나눠서 블록 하나씩 조인하는 방법
• 중첩 루프 조인에서 발전한 방법

정렬 병합 조인

⇒ 각각의 테이블을 조인할 필드 기준으로 정렬하고, 이후에 조인 작업 수행

• 조인할 때 사용할 적절한 인덱스가 없고, 대용량의 테이블 조인 시 사용
• 조인 조건으로 <, > 등 범위 비교 연산자가 있는 경우 사용

해시 조인

⇒ 해시 테이블 기반으로 조인

• 두 개의 테이블 조인 시 하나의 테이블이 메모리에 온전히 들어간다면, 중첩 루프 조인보다 효율적임
• 동등 조인에서만 사용 가능
• 빌드 단계, 프로브 단계로 구성

1) 빌드 단계

• 입력 테이블 중 하나를 기반으로 메모리 내 해시 테이블 빌드하는 단계
• 두 개의 테이블 중 바이트가 더 작은 테이블 기반으로 빌드함
• 해시 테이블의 키로 조인에 사용되는 필드 사용

  

2) 프로브 단계

⇒ 프로브 단계에서 레코드를 읽으며, 각 레코드에서 'persons.country_id'와 일치하는 레코드 찾아서 결과로 반환

• 각 테이블 한 번만 읽기 때문에 중첩 루프 조인보다 성능 좋음
• 시스템 변수 join_buffer_size에 의해 사용 가능한 메모리 양 제어됨, 런타임 시 조정 가능