DB의 필요성
데이터를 저장하는 방법으로 메모리에 임시로 저장한다거나, 실제 파일에 데이터를 만들어 보관하는 등의 방법을 사용하면 되는데 왜 DB가 필요한지 먼저 생각해 볼 필요가 있다. 개인 사용자 입장에서는 (사용자마다 다르지만) 굳이 DB를 사용할 필요 없이 기억장치로도 충분히 데이터를 보관할 수 있다.
하지만 다량의 데이터를 다루는 사용자 (기업이나 큰 규모의 프로젝트 관리 등) 입장에서는 아래와 같은 문제점이 발생할 수 있다.
| In-Memory | 휘발성 - 끄면 데이터 증발 중요한 데이터가 있는데 갑자기 꺼진다면? |
| File I/O (파일 입출력) | 원하는 데이터만 가져올 수 없고 항상 모든 데이터를 가져온 다음에 서버에서 필터링을 해야함 파일이 손상되거나, 동시 다발적으로 또 데이터의 크기가 클 경우, 데이터를 불러오는 작업이 힘들어진다. |
데이터베이스 (DB)는 필터링 말고도 파일 입출력으로 구현이 힘든 부분들을 해결하는 기능을 갖고 있는 는 데이터 특화 서버 이기 때문에 이러한 문제점들을 보완하는 동시에, 데이터의 관리 측면에서 더 편리하다.
DB는 Excel이랑 비슷하게 생겼다.
- DB - Table :: Excel - Sheet
- Row(행) - Column(열) 존재
- 필터링 가능
- 인터페이스가 따로 없어서 터미널에 Query문을 적절하게 사용한다 - 쿼리를 날린다
SQL이란?
SQL (Structured Query Language)는 구조화된 Query 언어로써, 주로 관계형 데이터베이스에서 사용한다. 예를 들어 MySQL(돌고래), Oracle, SQLite, PostgreSQL 등 다양한 DB에서 SQL 구문을 사용할 수 있다.
'Structured'라는 단어에서 유추할 수 있듯이,
SQL은 데이터가 구조화된 테이블 (구조가 고정된 테이블)을 사용하는 DB에서 사용 가능하다. 여기서 테이블을 Relation 이라고도 부른다.
여기에서 Query (쿼리)는 질의문이라는 뜻을 가지고 있는데, 예를 들면 구글링 할 때 입력하는 검색어가 일종의 쿼리라고 볼 수 있다. 검색어를 통해 저장되어있는 데이터를 해당 검색어로 필터링한다.
즉, Query는 DB에 저장되어 있는 데이터를 필터링하기 위한 검색어이다. SQL을 통해 DB로 쿼리를 보내 원하는 데이터를 받아오거나, 추가하는 등의 동작을 수행할 수 있다.
SQL의 반대로, 데이터의 구조가 고정되어 있지 않는 형태의 DB를 NoSQL이라고 한다. 관계형 데이터베이스와는 다르게 테이블을 사용하지 않으며 데이터를 다른 형식으로 저장해 놓는다. 대표적인 예로 문서 지향 DB인 MongoDB가 있다.
SQL vs NoSQL 목차에 더 자세한 내용이 있다.
DB Transaction
Transaction 은 DB의 상태를 변환시키는 논리적 기능을 실행하기 위해 행해지는 하나 이상의 쿼리를 모아놓은
하나의 작업 단위이다. 즉, 여러 개의 작업을 하나로 묶어놓은 실행 유닛이다.
각 트랜잭션은 하나의 특성 작업으로 시작하여 하나로 묶여있는 모든 작업을 완료해야 정상적으로 종료된다. 트랜잭션 중 하나의 작업이라도 실패하면 해당 트랜잭션의 모든 작업은 실패 처리가 된다. 이때, 해당 트랜잭션 중 성공한 작업도 취소가 되는데 이를 'Rollback - 롤백'이라고 한다.
데이터베이스 트랜젝션은 ACID라는 특성을 갖고 있다.
ACID
" ACID는 DB안에서 일어나는 하나의 transaction의 안정성을 보장하기 위해 필요한 속성이다 "
Atomicity (원자성)
하나의 transaction에 속한 모든 작업이 전부 성공하거나, 전부 실패해서 결과를 예측할 수 있어야 한다.
은행 계좌이체를 생각하면 쉬운데, A 계좌에서 B계좌로 송금을 했다고 보자. A 계좌에서는 출금 기록이 남아있는데 B계좌에는 입금 기록이 없다면 해당 돈은 공기가 된 것이나 마찬가지다.
이런 상황을 방지하기 위해 위와 같이 입금에 실패하는 경우, A 계좌에서 출금하는 작업을 실패 처리시켜야 하는데 이것이 Atomicity의 요지이다.
마찬가지로 SQL에서도 특정 Query를 날렸는데 부분적으로 실패하는 부분이 있다면 해당 쿼리는 전부 실패가 되도록 구현한다.
Consistency (일관성)
하나의 transaction 이전과 이후, DB의 상태는 이전과 동일해야 한다.
트랜잭션이 동시에 실행될 경우(병렬-Concurrent)와 연속으로 실행될 경우(직렬-Serial)의 DB 상태는 동일해야 한다.
Isolation (고립성)
모든 transaction은 다른 transaction으로부터 독립되어야 한다.
예를 들어 내가 A 계좌와 B계좌로 각각 5000원씩 보낸다고 가정했을 때, A 계좌로 송금한 트랜잭션과 B계좌로 송금한 트랜잭션은 서로 독립되어 있다. 그리고 각각의 트랜잭션은 서로 다른 트랜잭션의 작업 내용을 알 수 없다.
Durability (지속성)
Transaction이 성공적으로 수행되었다면 해당 기록은 영구적, 그리고 안정적으로 남아있어야 한다.
예를 들어, 계좌이체를 성공적으로 하였지만, 후에 은행 DB에 오류가 나서 종료가 되더라도, 성공한 계좌이체 내역은 기록으로 남아 있어야 한다.
Atomicity에 근거해서, 완벽하게 실행된 트랜잭션은 그 결과를 비 휘발성 저장장치에 저장하는 형태로 보존해야 하고, 트랜잭션을 처리하는 프로그램은 이를 보장해야 한다.
SQL vs NoSQL
데이터는 크게 SQL 같은 관계형 데이터베이스와 NoSQL 같은 비관계성 데이터베이스로 구분할 수 있다. SQL과 NoSQL은 만들어진 방식, 저장하는 정보의 종류, 그리고 저장 방식 등에서 차이가 있다.
SQL
관계형 DB는 MS Excel을 생각하면 편한데 테이블을 생성하여 그 구조와 데이터 타입 등을 미리 설정하고, 테이블에 정의된 내용에 적합한 형태의 데이터를 추가한다.
Excel과 마찬가지로 Row(행)과 Column(열)로 구성된 테이블에 데이터를 저장한다.
| row | 하나의 속성에 대한 정보를 저장 |
| column | 각 row의 데이터 형식에 맞는 데이터를 저장 |
이렇게 특정한 형식을 지니고 있어서 정확하게만 데이터를 입력했다면 데이터를 사용할 때는 많이 수월하다. 관계형 DB에서는 SQL을 이용해 원하는 정보를 Query 할 수 있기 때문에 DB의 Schema를 뚜렷하게 확인할 수 있다.
즉 관계형 DB는 테이블들 간의 관계를 직관적으로 파악 가능하다.
대표적 관계형 DB: [ MySQL, Oracle, SQLite, PostgressSQL, MariaDB 등 ]
NoSQL
NoSQL은 단어 그 자체로도 유추 가능한 것처럼, 데이터가 고정되어 있지 않은 DB를 말한다. No가 붙었다고 해서 위에서 설명한 "SQL은 DB의 Schema(스키마)를 뚜렷하게 확인 가능하다"의 반대의 미인 NoSQL에는 Schema가 없다 는 아니다.
Schema: 어떤 구조로 데이터에 저장하는지 나타내는 DB 데이터 구조라고 생각하자
객체의 특성을 나타내는 속성(Attribute)
+
속성(Attribute)의 집합으로 이루어진 개체(Entity)
+
개체(Entity) 사이에 존재하는 관계(Relation)에 대한 정의
+
유지해야 하는 제약 조건들
관계형 DB는 데이터를 입력 시 schema에 맞게 '입력'해야 하는 것이고
NoSQL은 schema에 따라 데이터를 '읽어'온다. (schema on read).
읽어올 때 데이터 스키마가 사용되는 것은, 데이터를 입력하는 방식에 따라 읽어올 때 영향을 미친다는 것을 의미한다.
대표적 NoSQL: [ MongoDB, Casandra 등 ]
NoSQL 기반 DB의 구성
- Key - Value 타입 (Redis, Dynamo DB 등)
- 속성을 Key-Value의 쌍으로 나타내는 데이터를 '배열'의 형태로 저장한다.
Key - 속성 이름
Value - 속성인 Key에 연결된 데이터 값
- 속성을 Key-Value의 쌍으로 나타내는 데이터를 '배열'의 형태로 저장한다.
- 문서형(Document) DB (Mongo DB)
- 데이터를 관계형 DB의 테이블처럼 이 아닌, 문서처럼 저장한다.
- 많은 문서형 DB는 JSON과 비슷한 형식의 데이터를 문서화해서 저장한다.
- 각각의 문서는 하나의 속성에 대한 데이터를 갖고 있고, 컬렉션이라고 하는 그룹으로 묶어 관리한다.
- Wide-Column DB (Cassandra, HBase 등)
- DB의 column에 대한 데이터를 집중적으로 관리하는 DB이다.
- 각각의 column에 Key-Value 형식으로 데이터가 저장되고, Column Families라는 column의 묶음 단위로 데이터를 처리한다.
- 하나의 row에 많은 column을 포함하기 때문에 높은 유연성을 가지고 있다. 따라서 규모가 큰 데이터 분석에 주로 많이 사용된다.
- Graph DB (Neo4J, InfiniteGraph 등)
- 자료구조의 graph와 비슷한 형식으로 데이터 간의 관계를 구성하는 DB
- 각 노드(nodes)에 속성별(entities)로 데이터를 저장한다.
- 각 노드 간의 관계는 간선(edge)으로 표현한다.
SQL / NoSQL 차이점
- 데이터 저장 방식
- SQL 기반
-- SQL을 이용하여 데이터를 테이블에 저장.
-- 미리 작성된 schema를 기반으로 정해진 형식에 맞게 데이터를 저장해야 한다.| - NoSQL 기반
-- Key-Value / Document / Wide-Column / Graph 등의 방식으로 데이터를 저장한다.
- SQL 기반
- Schema
- SQL 기반
-- 고정된 형식의 schema가 필요하다. 즉, 처리하려는 데이터의 속성별로 column에 대한 정보를
미리 정해두어야 한다.
-- schema는 변경 가능 하지만, DB 전체를 수정하거나 오프라인(down-time)으로 전환할 필요가 있다. - NoSQL 기반
-- 동적으로 schema의 형태를 관리할 수 있다.
-- row를 추가할 때 즉시 새로운 column을 추가할 수 있고, 개별 속성에 대해 모든 column에 대한 데이터를
반드시 입력할 필요가 없다.
- SQL 기반
- Query
- SQL 기반
-- Table의 형식과 table 간의 관계에 맞춰 데이터를 요청해야 한다.
-- 따라서 SQL처럼 구조화된 쿼리 언어를 사용한다. - NoSQL 기반
-- NoSQL 기반에서 쿼리는 데이터 그룹 자체를 조회하는 것에 포인트를 둔다.
-- 따라서 구조화되지 않은 쿼리 언어로도 데이터 요청이 가능하다.
(UnQL - UnStructured Query Language)
- SQL 기반
- Scalability(확장성)
- SQL 기반
-- 일반적으로 수직적으로 확장한다. (높은 메모리와 CPU 자원을 사용하는 확장)
-- DB가 구축된 Hardware의 성능을 많이 사용하기 때문에 비용이 높다.
-- 여러 서버에 걸쳐 DB 간의 관계를 정의 가능하지만, 엄청 복잡하고 시간도 많이 소모된다. - NoSQL 기반
-- 수평적으로 확장한다. (값싼 서버 증설 비용, 클라우드 서비스를 이용한 확장)
-- NoSQL DB를 위한 서버를 추가적으로 구축하면, 많은 트래픽을 보다 편리하게 처리할 수 있다
-- 저렴한 범용 Hardware나 클라우드 기반의 인스턴스에 DB를 호스팅 할 수 있어, SQL 기반 DB의 수직적
확장보다 가격적인 측면에서 많이 저렴하기 때문에 유리하다.
- SQL 기반
SQL기반 사용 케이스
1. DB의 ACID 성질을 따라야 하는 경우
SQL을 사용하면 DB와 상호작용 하는 방식을 명확하게 규정 가능하기 때문에, DB에서 데이터를 처리할 때 발생할 수 있는 예외적인 상황을 최소화하고 DB의 무결성을 보호할 수 있다. 즉, transaction 과정에서의 DB의 안정성을 보장해야 할 때 SQL을 사용한다.
특히 은행이나 금융 서비스를 다루는 소프트웨어에서는 반드시 데이터베이스의 ACID성질을 반드시 준수해야 하기 때문에 이런 케이스는 일반적으로 SQL 기반의 DB를 사용한다.
2. 사용되는 데이터가 구조적이고 일관적인 경우
프로젝트의 규모가 대규모 서버를 필요로 하지 않고 일관된 데이터를 사용하는 경우에 SQL 기반 데이터베이스를 사용한다. NoSQL은 상대적으로 다양한 데이터 종류와 높은 트래픽을 지원하도록 설계되어 있기 때문에, NoSQL을 사용할 이유가 없다.
NoSQL 기반 사용 케이스
1. 데이터의 구조가 거의 없거나 전혀 없는 대용량의 데이터를 저장하는 경우
대부분의 NoSQL 기반의 DB는 저장이 가능한 데이터 유형에 제한이 없다. 경우에 따라 새로운 데이터의 유형을 추가할 수 있다. 따라서, 일관적이지 않거나 정형화되지 않은 대규모의 데이터가 필요한 경우 NoSQL 기반의 DB를 사용하는 것이 효율적일 것이다.
2. Cloud 컴퓨팅 / 저장공간을 최대한 활용하는 경우
클라우드 기반으로 DB 저장소를 구축하면 저렴한 비용으로 솔루션을 제공받을 수 있다. DB의 확장성을 중점으로 둬야 한다면, 번거로움 없이 확장이 가능한 NoSQL 기반 DB를 사용하는 게 좋다.
3. 빠른 서비스 구축 과정에서, 데이터 구조가 자주 변경되는 경우
NoSQL 기반 DB는 schema를 미리 준비할 필요가 없어서 빠르게 프로토타입이나 데모 버전을 내야 할 때와 같이 빠른 개발을 진행해야 하는 경우에 아주 유리하다.
또한 소프트웨어 버전별로 잦은 down-time 없이 데이터 구조를 업데이트해야 하는 경우, NoSQL 기반 DB가 더 적합하다. SQL 기반의 DB는 구조를 변경할 때마다 매번 스키마도 수정해야 하기 때문이다.
*down-time
- DB 서버를 Offline으로 내린 뒤 데이터 처리를 진행하는 작업 시간
SQL 문법 종류
언어에서 주어나 동사 그리고 형용사를 문법적으로 구분하는 것처럼, SQL에서도 역할에 따른 다양한 문법이 존재한다.
일반적으로 다음의 5가지로 분류한다.
Data Definition Language (DDL)
DDL은 데이터를 정의할 때 사용하는 언어이다.
CREATE나 DROP처럼 테이블을 만들거나 제거할 때 쓰이는 것들이 해당함. DB의 테이블과 같은 오브젝트를 정의할 때 사용한다.
Data Manipulation Language (DML)
DML은 DB에 데이터를 저장할 때 사용하는 언어이다.
새로운 레코드를 추가할 때 사용하는 INSERT를 포함해서, 데이터 삭제의 DELETE, 변경하는 UPDATE가 DML에 속한다.
Data Control Language (DCL)
DCL은 DB에 대한 접근 권한과 관련된 문법이다.
유저의 접속 권한을 설정한다. 권한을 부여하는 GRANT나, 권한을 회수하는 REVOKE 등이 있다.
Data Query Language (DQL)
DQL은 정해진 스키마 내에서 쿼리 할 수 있는 언어이다.
SELECT 가 DQL에 해당한다. DQL을 DML의 일부분으로 취급하는 경우도 있다.
Transaction Control Language (TCL)
TCL은 DML을 거친 데이터의 변경사항을 수정할 수 있다.
COMMIT 같은 DML이 작업한 내용을 DB에 커밋하거나, ROLLBACK처럼 커밋한 내용을 다시 롤백하는 문법이 있다.
'web > DB' 카테고리의 다른 글
| DB 설계 (0) | 2022.06.13 |
|---|---|
| MySQL 접속 에러 ERROR 2003 (HY000) (0) | 2022.06.10 |
| DB/SQL 관련 명령어 (0) | 2022.06.09 |