선발대 녹화 강의 수강
데이터베이스를 사용하는 이유
sql 이라는 질의어를 통해 효과적으로 데이터 인출 가능
백업과 복구에 용이 (특히 aws rds는 pit(point-in-time)를 지원)
acid 특성
데이터관리의 중앙화
파편화되어 관리될때 단점:
관리자 입장에서는 데이터 채널이 여러개가 될 수 있어서 번거롭고 불편함
데이터가 중복되어 저장될 가능성이 있음
민감한 데이터 보안
데이터베이스는 접근 권한을 명시할 수 있어 민감한 데이터 열람의 위협으로부터 보호할 수 있음
고가용성
대규모 웹 서비스를 운영함에 있어 안정성이 가장 중요한 사항 중 하나임
안정성
: 동시에 다수의 트래픽이 몰려도 웹 서비스 성능에 지장이 있어선 안됨
웹 서비스의 백엔드를 이루는 구성요소중 일부분에 장애가 발생해도 웹 서비스는 중지되지 않고 계속 제공되어야 함
(ex: 네이버 지식인이 다운되도 다른 네이버 서비스는 제공됨)
= 고가용성 (High Availability)
가용성: 서버, 네트워크, 프로그램 등의 정보 시스템이 정상적으로 사용 가능한 정도.
정상사용시간 / 전체사용시간
위 수식의 값이 1로 수렴할수록(다운타임이 거의0에 수렴할수록), 고가용성을 확보했다는 뜻
백엔드 프로그래머는 이런 서비스 다운타임 최소화가 핵심
데이터베이스 고가용성
이중화
: 마스터 인스턴스가 죽은 경우 스탠바이 인스턴스가 곧바로 마스터 인스턴스로 교체되어 다운타임을 최소화 하는 메커니즘
db 자체에서 지원하는 개념은 x, aws rds와 같은 클라우드 서비스는 안정성 확보를 위해 이중화라는 솔루션을 자체적으로 제공하여 고민거리를 덜어줌
기본적으로 aws rds는 보통 여러개의 인스턴스가 있으며 1개의 마스터 인스턴스와 n개의 스탠바이 인스턴스로 구성됨
Read Only :
master(primary)의 분신. 읽기 전용.
select쿼리 원툴. 모든 서비스에서 select쿼리 빈도가 압도적으로 많기 때문.
primary(master):
read/write 인데 보통 write
쓰기,읽기,수정
stanby:
master대신 심어놓고, master가 없어지면 master가 될 수 있는 애. 분신이랑 다름.
승격이 되면 얘의 standby가 생김.
replication(복제)가 일어나고 있음
쿼리의 5종류
DDL (Data Definition Language)
: 관계형 데이터베이스의 구조를 정의하는데 사용
CREATE, ALTER
DQL (Data Query Language)
: 반드시 알아야 하는 쿼리1
SELECT
DML (Data Manipulation Language)
: 반드시 알아야 하는 쿼리2
테이블이 정의되면 데이터를 삽입/수정/삭제하는 쿼리
INSERT,UPDATE,DELETE
DCL (Data Control Language)
: 데이터에 엑세스하는 정책들을 컨트롤하기 위해 사용
GRANT, REVOKE
TCL (Transaction Control Language)
: 트랜잭션 별로 데이터를 커밋하거나 롤백하기 위해 사용
트랜잭션
트랜잭션 성질 === ACID
트랜잭션 정의
: 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위, 도는 한꺼번에 모두 수행되어야 할 일련의 연산들
예시: 계좌이체
반드시 각각의 단계가 하나의 단계인것처럼 움직여야 함.
커밋: 모두 성공적으로 완료되어 반영되는 것
롤백: 문제가 하나라도 발생해 원래 상태(실행 전)로 돌아가는 것
데이터의 정확성을 보장하고 데이터베이스의 상태를 일관성있게 유지하는데 필수적
Stored Procedure(저장 함수) / CALL
ACID 특성
A (Atomicity) 원자성
: 데이터베이스의 모든 트랜잭션은 원자성을 보장함. 수행이 되던지/ 안되던지 둘 중 하나,
애매한 상태는 존재x
C (Consistency) 일관성
: 데이터베이스에서는 트랜잭션이 완료되면 데이터의 일관성이 보장됨
무결성 제약을 깨뜨리는 트랜잭션은 실행되지 x
I (Isolation)
: 트랜잭션이 일단 수행되면 다른 트랜잭션으로부터 영향받지 않고 수행될 수 있음
D (Durability)
: 트랜잭션이 성공적으로 수행되면 이 결과는 영원히 데이터베이스에 반영됨
데이터베이스의 보안 - 접근 제어
데이터베이스는 서비스의 심장
내부 사용자들이 데이터를 부적절하게 변경하거나 삭제하는것을 방지해야함.
인증(Authentication)
CREATE USER 'messi'@'localhost' IDENTIFIED BY 'goat';localhost에서 접근할수있는 messi라는 이름의 새로운 사용자를 등록하고 'goat'라는 비밀번호로 이 사용자를 인증하겠다.
인가(Authorization)
GRANT SELECT, INSERT, DELETE ON soccer.* TO 'messi'@'localhost';messi라는 유저에게 soccer라는 데이터베이스에서는 어떤 테이블이건 SELECT, INSERT, DELETE 할 권한을 허락함
UPDATE는 불가. soccer를 제외한 다른 데이터베이스에서는 아무런 권한x
사용자마다 항상 최소 권한의 법칙 적용.
해당 사용자가 컨트롤할 수 있는 영역에서만 명확하게 권한을 주자는 것.
데이터 암호화
암호화
: 원래의 평문(plain text)을 암호문(인간의 눈으로 해독이 불가능한 텍스트)으로 변환하는 과정. 특정한 암호화 키를 사용해 수행됨
복호화
: 위의 암호화 과정에서 사용한 키 혹은 새로운 키를 사용해서 암호문을 다시 원래의 평문으로 복원하는 것
- 대칭키 암호화
: 복호화 과정에서 암호화 과정에서 사용한 키를 사용함
하나의 마스터키가 암/복호화를 할 수 있음
간편하지만 무서운 메커니즘 - 비대칭키 암호화
: 복호화 과정에서 새로운 키 사용
암호화 하는 열쇠, 복호화 하는 열쇠 따로
대칭키 암호화에 비해 조금 더 안전
비밀번호의 경우 복호화하지 않고, 암호화된 값 자체를 비교하여 인증을 수행
암호화 키가 노출되더라도 복호화가 불가능한 구조로 설계되어있기 때문. ( 단방향 암호화 )
원본 데이터 자체는 항상 보호받을 수 있음
SQL Injection
"SELECT * FROM Users WHERE Username='admin'; --' AND Password='...';"
-- 가 sql주석이라 AND password= 부분은 실행되지 않게함prepared statement
const sql = "SELECT * FROM Users WHERE Username = ? AND Password = ?";escape처리
모델링
클라이언트 요구사항 분석
: 클라이언트가 절대 원하는것을 100%로 빠짐없이 말할 수 있는 사람들이 아니라고 생각하고 적극적으로 요구사항을 수집한 뒤 분석해야 함
데이터베이스 모델링
: 타겟 유저 및 추상화 수준에 따라 여러종류의 스키마 정의
-
내부단계
: 데이터베이스의 물리적인 저장 구조를 기술하고 물리적 모델 사용
물리적 데이터 모델에는 { 테이블, 테이블간 관계 정의, 컬럼, 인덱스, 제약조건 설정 } 이 포함되어야 함 -
개념단계
: 보다 더 개념적으로 설계/ 조금 더 추상적 단계
세부사항 생략, 클라이언트 요구사항 구현하기 위해 필요한 정보 및 속성 기술하는 단계
{ e.g. 게시판 테이블 ( 작성인, 작성일, 조회수, 제목, 내용, 첨부파일) } -
외부단계
: 데이터베이스를 사용하는 고객이 보는 관점에서 스키마를 설계하는 단계
각각의 사용자는 저마다의 뷰를 가짐
ERD 용어 정의
-
엔티티
: 개념적으로 혹은 실제로 존재하는 개체/ 고유해야 함
e.g.
분야별 { 연구원, 생산직, 판매직, ... }
개념별 { 프로젝트, 스토리, 태스크, ... } -
애트리뷰트
: 엔티티의 구성요소
e.g. 프로젝트를 구성하는 요소
{ 프로젝트번호, 프로젝트이름, 프로젝트시작일, 프로젝트종료일, 프로젝트_목표, 최종책임자 } -
릴레이션
: 엔티티와 엔티티의 관계를 나타내는 것
보통 카디널리티 비율( 1:1, 1:N, M:N )로 표기
데이터베이스 모델링 시 기본 원칙
- 업무에서 필요로하는 모든 데이터가 모델이 정의되어 있어야 함
- 두 개의 엔티티가 비슷한 애트리뷰트로 구성되어 있으면 하나의 엔티티로 통합
- 애트리뷰트는 누구라도 알 수 있게 작성되어야 함
- 애트리뷰트의 이름은 너무 길게 작성하지 말 것
- 애트리뷰트가 여러개의 값을 가지면 엔트리로 바꾸는 것이 나을수 있음
- 엔티티, 애트리뷰트는 명사/ 관계는 동사
- Data Redundancy 이슈가 발생하지 않아야 함
: 데이터 중복
저장공간이 낭비, 일관성유지위해 유지보수 작업 낭비
데이터 타입
-
논리타입
: BOOLEAN / 참,거짓을 저장할 때 사용 -
정수타입
: TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 등
정수를 저장해야 할 때 사용
저장 범위
TINYINT(1바이트): 0~2^8-1 (부호 없는 기준)
SMALLINT(2바이트): 0~2^16-1 (부호 없는 기준)
MEDIUMINT(3바이트): 0~2^24-1 (부호 없는 기준)
INT(4바이트): 0~2^32-1 (부호 없는 기준)
BIGINT(8바이트): 0~2^64-1 (부호 없는 기준) -
부동소수점 타입
: FLOAT, DOUBLE
소수점을 포함하는 숫자를 저장해야할 때 사용
부동: 움직일 수 있다
EX) 123.45 → 1.2345 x 10^2
장점: 소수점 아래에 많은 자릿수를 가지거나 매우 크거나 작은 수를 표현하는 데 유리
넓은 범위의 수를 표현. 많은 양의 데이터 처리
한계: 근사값을 표현하므로 계산의 정확성이 떨어짐 -
고정소수점 타입
: DECIMAL
정밀한 계산이 필요할 때 사용
다만 FLOAT, DOUBLE에 비해 범위가 넓지 않음
소수점 아래에 특정 개수의 자리를 가진 수를 표현
소수점 위치가 고정되어있어 표현 범위 제한
소수점 이하의 정밀도 보장X
계산이 빠르고 정확
-
문자열 타입
CHAR, VARCHAR, TEXT 등/ 텍스트를 저장
CHAR: 고정길이 저장
VARCHAR: 가변길이 저장
TEXT: 매우 큰 텍스트 데이터 저장 -
날짜/시간 타입
: DATE, TIME, DATETIME, TIMESTAMP
인덱스
: 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조
인덱스를 저장하기 위한 추가 공간 필요
풀스캔( 테이블의 모든 데이터를 검색 ) 하면 시간이 오래걸리므로 데이터+데이터위치 를 포함한 자료구조를 생성하여 빠르게 조회
보통 B+ 트리를 많이 이용
인덱스의 종류
-
클러스터형 인덱스
: 정렬된 데이터 row들을 탐색 키 값으로 가짐
테이블 당 클러스터형 인덱스를 하나만 가짐 (보통 primary key)
인덱스의 포인터는 row가 저장된 데이터 블록을 가리킴
정렬이 되어있다는 전제조건 -> 검색시 성능 매우 빠름
전제조건을 지키기위해 삽입,수정,삭제시 성능 아쉬움
기존에 레코드가 많이 보유된 테이블에 클러스터형 인덱스를 새로 생성하면 데이터페이지를 전부 다시 정렬해야되어 부하가 매우 커질수 있음 -
비클러스터형 인덱스
: 정렬되지 않은 데이터 row들을 탐색 키 값으로 가짐
비클러스터형 인덱스 키 값. 각 키 값 항목에는 해당 키 값 포함된 데이터 row에 대한 포인터.
별도의 페이지에서 인덱스를 구성하므로 추가적인 용량 필요
클러스터형에 비해 느린 검색, 빠른 삽입/수정/삭제
남발할 경우 저장공간이 순식간에 마름 -> 실제로 수행할 쿼리나 연산 기준으로 무조건 필요한 컬럼에만 지정할 것
selectivity(분포도)
검색했을 때 해당건수가 적을 수록 좋음
인덱스 사용 시 주의사항
- 검색결과가 전체 데이터에서 20%를 넘는다면 사용x
(풀스캔 가까움) - 사용하지 않는 인덱스는 제거
- INSERT만 자주 하는 테이블이면 인덱스 필요X
SELECT 문의 빈도가 INSERT, UPDATE, DELETE에 비해서 많은지 정확하게 예상할 것 - WHERE 절에 사용되는 컬럼은 인덱스 유력 후보
데이터베이스 정규화 1NF, 2NF, 3NF 알아보기
제2정규화: partial dependency를 가지는 column을 분리 ( 한 테이블: 제2정규형을 만족하는 테이블 / 각각)
partial dependency: 하나의 composite primary key에 종속됨
제3정규화: 일반컬럼(primary key에 종속되어있지 않은 column) 분리
장점: 데이터가 많을 때 수정이 편함
단점: 정보를 한 테이블에서 볼 수 없고 join하거나 다른 테이블을 참조해야 알 수 있음
