데이터베이스란 데이터 저장소로, DBMS를 이용하여 DB에 접근하고 SQL or NoSQL 언어로 데이터를 CRUD합니다. 엣지 케이스가 발생하든 트래픽이 많든 안전하고 빠르게 데이터를 CRUD 하는것이 목표입니다. CRUD란 데이터 생성, 읽기, 업데이트, 삭제를 의미합니다.
1. SQL이란
DB와 대화하기 위해 특별히 디자인된 언어로 테이블 기반으로 동작합니다.이들은 크게 엄격한 스키마 구조와 관계의 특징을 보유합니다.
[1] 엄격한 스키마 구조
- 데이터는 테이블 레코드로 저장되며, 스키마를 준수하지 않은 레코드는 추가할 수 없습니다.
- 아래 테이블에서 '유툥기한'이라는 필드를 넣고 싶다면 스키마를 뜯어 고치지 않는 한 레코드를 추가할 수 없습니다.
※ 스키마란 DB의 전체구조(메타데이터)와 제약 조건 명세를 말합니다.
[2] 관계
- 데이터들을 여러개의 테이블에 나누어 저장합니다. 어떤 결과를 도출하기 위해 테이블들을 조합(Join)합니다.
- 만약 사용자가 구입한 상품을 나타내기 위해서는 Users, Products, Orders 테이블을 만들어야 하는데 각각의 테이블들은 다른 테이블에 핵심 데이터를 저장하지 않습니다. 즉 중복된 데이터가 없습니다. 따라서 다른 테이블에서 부정확한 데이터를 다룰 위험이 사라집니다.
SQL은 데이터를 엄격히 다뤄 부정확한 데이터를 다룰 위험을 줄입니다. 하지만 이 과정에서 Join의 비용이 높아져 속도가 비효율적일 수 있습니다.
[3] SQL의 분류
DDL [Data Definition Language]
DB의 스키마 구조를 조작합니다. DB 객체는 테이블, 뷰, 인덱스, 파티션 테이블 등을 포함합니다.
CREATE / DROP / ALTER
DML [Data Manipulation Language]
데이터베이스 내의 데이터를 조작합니다.
SELECT / INSERT / UPDATE / DELETE
DCL [Data Control Language]
사용자에게 권한을 주거나 회수합니다.
GRANT / REVOKE / COMMIT / ROLLBACK
2. Data Integrity
일관성있는 데이터를 제공하기 위해 아래의 방법을 제공합니다.
| 제목 | 내용 |
|---|---|
| Integrity Constraint | 컬럼에 Referentional Integrity, Domain Integrity, Not NULL 등의 제약 조건을 명시합니다. |
| 중복 컬럼 | 특정 테이블이 가진 컬럼을 다른 테이블에서도 제공하는 중복 컬럼을 지양합니다. 만약 중복 컬럼의 어떤 데이터를 업데이트할 때 하나의 테이블만 업데이트한다면 데이터의 일관성이 깨질 수 있습니다. |
| Isolation Level | 여러 트랜잭션이 공유 데이터에 동시 접근하여 발생하는 이상 현상들을 방지합니다. 어떤 트랜잭션이 공유 데이터를 변경하던 도중 다른 트랜잭션이 접근하여 이상 데이터를 읽을 수도 있어 Isolation Level을 설정합니다. |
| Transaction | DB에서 논리적 작업 단위로 쿼리의 집합을 의미합니다. 트랜잭션으로 묶인 쿼리들을 모두 수행하거나 모두 수행하지 않는 atomic한 쿼리 집합을 지원합니다. |
| Nomalization | 테이블을 잘못 설계하면 하나의 테이블에서 이상현상이 발생합니다. 메모리 낭비 및 업데이트 문제가 발생합니다. 이러한 문제를 해결하기 위해 테이블을 분해하여 저장합니다. |
Index
SQL 기반의 DBMS는 테이블을 조합하여 쿼리를 수행합니다. 이때, join 연산은 굉장히 비용이 큰 동시에 RDB에서 필수적으로 수행하는 기능입니다. 따라서 연산의 비용을 줄이고자 Join에 자주 걸리는 컬럼에 Index를 설정하여 보다 빠르게 Join 연산을 수행합니다.
3. Integrity Constraint (무결성 제약조건)
무결성이란 DB에 저장된 값과 현실의 값이 일치하는 정확성을 말합니다. 무결성을 위해 아래의 기능을 제공합니다.
- Entity Integrity (개체 무결성) : 모든 테이블은 기본 키를 가져야합니다. 기본 키로 설정된 컬럼은 Unique, Not Null의 특징을 보유합니다.
- Referentional Integrity (참조 무결성) : 참조 되는 값이 항상 일관된 값을 갖도록 유지하는 것을 말합니다. 예를 들어 유저의 실수로 관련 데이터가 삭제되거나 수정하는 일을 막습니다. 이때 참조 컬럼은 unique 키 값, 데이터 형식이 같아야합니다.
- Domain Integrity (도메인 무결성) : 테이블에 올바른 데이터가 입력 됬는지 체크하는 제약조건입니다. Null 값 비허용, unique 값만 허용, 특정 값들만 허용 등이 존재합니다. 만약 계절이라는 컬럼에 '봄', '여름', '가을', '겨울' 이외에 값을 비허용 할 수도 있습니다.
4. Key
※ 예를 들어, '학번', '과목', '교수', '나이'의 컬럼을 보유하고, '과목'과, '교수'가 1대1 대응인 테이블이 있다고 가정해봅니다.
[1] Super Key
테이블에 존재하는 필드들의 부분집합으로서 유일성을 만족합니다. 즉 레코드를 유일하게 구별할 수 있는 식별자를 말합니다.
Ex) {학번, 과목, 교수, 나이}, {학번, 과목}, {학번, 교수}, {학번, 과목, 나이}
[2] Candidate Key
기본키가 될 수 있는 후보를 말합니다. 테이블에 존재하는 필드들의 부분집합으로써, 유일성과, 최소성을 만족합니다. 유일성은 레코드들을 구별할 수 있음을 나타내고, 최소성은 이러한 필드들의 갯수가 최소임을 말합니다.
Ex) {학번, 교수}, {학번, 과목}
[3] Primary Key
- Candidate Key 중에서 PK의 특성에 맞는 키 값을 선정합니다. 기본키는 유일성, 최소성의 성질을 가짐과 동시에 NULL 값을 가질 수 없습니다.
- PK는 기본적으로 Clustered Index로, Update 연산이 자주 일어날 경우 물리적 데이터가 밀리고 땡기는 Overhead가 자주 발생하여 업데이트가 적은 컬럼으로 선정해야합니다.
- Join시 비교연산이 자주 일어나, 많은 자릿수를 가진 정수나, 많은 문자를 포함한 문자열을 지양해야합니다. 즉, 짧고 단순한 형식의 필드를 선정해야합니다.
[4] Foreign Key
다른 테이블의 PK를 참조하는 컬럼을 보통 외래키라고 합니다. 이때 참조하는 키와 동일한 데이터 타입, Unique한 키를 참조하는 제약조건이 필요합니다.
필요에 따른 설정 값
- RESTRICTED : 레코드를 변경, 삭제 할 때 해당 레코드를 참조하는 개체가 있다면 연산 취소합니다.
- CASCADE : 레코드를 변경, 삭제 할 때 해당 레코드를 참조하는 개체도 변경, 삭제합니다.
- SET NULL : 레코드를 변경, 삭제 할 때 해당 레코드를 참조하는 개체를 NULL로 변경합니다.
5. DML 처리 과정
[1] SELECT
- Parse
서버 프로세스는 해당 쿼리가 이전에 실행된적이 있는지 캐시에서 찾습니다. 이전에 실행된적이 있다면 바로 Execution 과정을 진행합니다. 만약 처음 실행된 것이면 서버는 Parsing 과정을 시작합니다. 문법, 권한, 테이블이 존재한지 등을 확인하고 해당 데이터로 가는 최적의 방법 QEP를 만듭니다. 이후 다음을 대비하여 QEP를 라이브러리 캐시에 저장합니다.
- Execution
디스크에서 데이터가 들어이쓴 블록을 찾아 메모리(DB Buffer Cache)로 복사합니다. 만약 메모리에 해당 데이터가 있으면 Fetch를 진행하고 없으면 계속해서 디스크에서 블록을 찾아옵니다.
디스크에서 메모리로 복사하는 과정(I/O)은 굉장히 오래 걸려 인덱스를 생성하는 등 성능을 높이기도 합니다.
- Fetch
최종적으로 메모리에 복사한 블록 중에서 사용자가 요청한 데이터를 실행합니다.
[2] INSERT, UPDATE, DELETE
SELECT문과 같이 PARSE 과정까지는 동일합니다. 이후 원하는 데이터가 들어있는 블록을 메모리로 가져 온 후 트랜잭션을 위해 변경 전 데이터를 Undo Log에, 변경되는 데이터를 Redo Log에 기록합니다. 이후 변경 데이터를 디스크에 반영합니다.
6. NoSQL
테이블에 레코드를 삽입하는 방식이 아니라 거대한 Map의 Key & Value 형태로 데이터를 저장합니다. 이때 Value는 domuent, json 등 다양한 값이 들어갑니다.
- 스키마 없이 사용하거나 느슨한 스키마를 제공해 설계가 간단하고 확장에 용이합니다.
- SQL은 정해진 스키마를 따르지 않다면 데이터를 추가할 수 없지만 NoSQL은 다른 구조의 데이터를 같은 컬렉션에 추가 할 수 있습니다.
- SQL은 다른 테이블에서 사용하는 컬럼을 중복 제공을 지양하는 반면 NoSQL은 관련 데이터를 동일한 컬렉션에 넣습니다.
- Join 비용이 줄어들어 빅데이터 같이 대규모 탐색시 효율적이지만 일관성이 깨진 데이터를 CRUD할 단점이 존재합니다.
아래 사진을 보면 Order 컬렉션은 관련 정보를 모두 포함합니다. 따라서 다른 컬렉션과 Join할 필요가 없습니다. 당연히 Join의 비용이 없어 빠르게 데이터 탐색할 수 있습니다.
하지만 컬렉션에 데이터가 중복되기 때문에 불안정합니다. 예를 들어 A, B 컬렉션이 공유 컬럼을 갖고 있을 때 실수로 A 컬렉션만 수정하고 B 컬렉션을 수정하지 않았다면 문제가 생깁니다.
7. SQL vs NoSQL
SQL을 사용하면 좋은 경우
- 관계를 맺고 있는 데이터가 자주 변경 될 경우에 유용합니다. NoSQL에서는 여러 컬렉션을 모두 수정해야합니다.
- 명확한 스키마를 보장할 경우에 유용합니다. 일관성 있는 데이터를 제공합니다.
NoSQL을 사용하면 좋은 경우
- 정확한 데이터 구조를 알 수 없거나 변경 및 확장 될 경우 유용합니다. SQL 에서는 스키마 구조가 다른 레코드는 삽입할 수 없습니다.
- 읽기 연산을 자주 하지만, 데이터가 자주 변경 되지 않은 경우에 유용합니다. SQL은 Join 연산으로 데이터를 읽어 속도가 느려질 수 있습니다. 하지만 데이터가 자주 바뀔 경우 NoSQL에서는 한 번의 변경이 수십 갯의 문서를 업데이트 할 수도 있어 업데이트가 적어야합니다.
SQL vs NoSQL
| SQL | NoSQL | |
|---|---|---|
| 장점 | 스키마가 명확하고 중복 데이터를 지양하여 데이터 무결성을 보장합니다. | 스키마 변경이 용이해 뛰어난 확장성을 보유합니다. 데이터를 빠르게 읽을 수 있어 빅데이터에서 자주 사용합니다. |
| 단점 | 기존 스키마를 수정하기 어렵습니다. Join을 필연적으로 하여 속도가 느려집니다. 하지만 제약 조건을 두어 Join을 빠르게 합니다. | 중복된 데이터를 가질 확률이 높아 업데이트 성능이 떨어집니다. 업데이트가 잘 안될 경우 데이터의 일관성을 보장 못합니다. |
