관계형 데이터베이스
Relational Database
구조화된 데이터를 표현하기 위해 테이블을 사용하며, 한 테이블을 Relation이라고 한다.
- 사전에 정의된 열의 데이터 타입대로 작성된 데이터가 행으로 축적된다.
- Column(Field): 테이블의 한 열
- Record(Tuple): 테이블의 한 행
- Key: 테이블의 각 레코드를 구분할 수 고유의 값
- 기본키(Primary key): 테이블의 각 행을 고유하게 식별하는 값을 가진 열 또는 열 조합
- 외래키(Foreign key): 두 테이블의 데이터 간 연결을 설정하고 외래 키 테이블에 저장될 수 있는 데이터를 제어하는 데 사용되는 열
- 테이블의 구조와 데이터 타입 등을 사전에 정의
- 테이블 간의 관계를 직관적으로 파악할 수 있다
- SQL을 활용해 원하는 정보를 쿼리할 수 있다 = 스키마가 뚜렷하게 보인다
- MySQL, Oracle, SQLite, PostgresSQL, MariaDB 등
비관계형 데이터베이스
데이터가 고정되어 있지 않다.
관계형 데이터베이스와는 달리, 테이블을 사용하지 않고 데이터를 다른 형태로 저장한다.
분류 타입 | 설명 | 상세 | 종류 |
Key-Value | 데이터를 배열의 형태로 저장 | Key: 속성 이름 Value: 속성에 연결된 데이터 값 |
Redis, Dynamo 등 |
문서형(Document) | 테이블이 아닌 문서처럼 저장 | JSON과 유사한 형식의 데이터를 문서화 각각의 문서는 하나의 속성에 대한 데이터를 가지고 있고, 컬렉션이라고 하는 그룹으로 묶어서 관리한다 |
MongoDB |
Wide - Column | Column에 대한 데이터를 집중 관리 | 각 열에는 key-value 형식으로 데이터가 저장 컬럼 패밀리(column families)라고 하는 열의 집합체 단위로 데이터를 처리할 수 있다 하나의 행에 많은 열을 포함할 수 있어서 유연성이 높다 규모가 큰 데이터 분석에 주로 사용 - 데이터 처리에 필요한 열을 유연하게 선택할 수 있다 |
Cassandra, HBase |
그래프(Graph) | 자료 구조의 그래프와 비슷한 형식으로 데이터 관계를 구성 | 노드에 속성별로 데이터를 저장한다 각 노드 간 관계는 선(edge)으로 표현한다 |
Neo4J, InfiniteGraph |
SQL vs. NoSQL
구조화된 쿼리 언어와 비구조화된 쿼리 언어
만들어진 방식, 저장하는 정보의 종류, 그리고 저장하는 방법 등에 차이가 있다.
🌳 데이터 저장
- 관계형: SQL을 이용해서 데이터를 테이블에 저장
- 미리 작성된 스키마를 기반으로 정해진 형식에 맞게 데이터를 저장해야 한다.
- 비관계형: key-value, document, wide-column, graph 등의 방식으로 데이터를 저장
🌳 스키마
데이터베이스에서 데이터가 구성되는 방식과 서로 다른 엔티티 간의 관계에 대한 설명 (= 데이터베이스의 청사진)
- 관계형: 고정된 형식의 스키마가 필요하다
= 처리하려는 데이터 속성별로 열(column)에 대한 정보를 미리 정해 두어야 한다
나중에 변경 시, 데이터베이스 전체를 수정하거나 오프라인(down-time)으로 전환해야 한다 - 비관계형: 동적으로 스키마의 형태를 관리할 수 있다
행을 추가 시 즉시 열을 추가할 수 있고, 개별 속성에 대해서 모든 열에 대한 데이터를 반드시 입력하지 않아도 된다
🌳 쿼리
- 관계형: 테이블의 형식과 테이블간의 관계에 맞춰 데이터를 요청해야 한다
= 정보를 요청할 때, SQL과 같이 구조화된 쿼리 언어를 사용 - 비관계형: 데이터 그룹 자체를 조회하는 것에 초점을 둔다
= 구조화 되지 않은 쿼리 언어로도 데이터 요청이 가능하다
UnQL(UnStructured Query Language)이라고 말하기도 한다
🌳 확장성
- 관계형: 수직적으로 확장 (= 높은 메모리, CPU를 사용하는 확장)
데이터베이스가 구축된 하드웨어의 성능을 많이 이용하기 때문에 비용이 많이 든다
여러 서버에 걸쳐서 데이터베이스의 관계를 정의할 수 있지만, 매우 복잡하고 시간이 많이 소모된다 - 비관계형: 수평적으로 확장 (= 보다 값싼 서버 증설, 또는 클라우드 서비스 이용하는 확장)
NoSQL 데이터베이스를 위한 서버를 추가적으로 구축하면, 많은 트래픽을 보다 편리하게 처리할 수 있다
저렴한 범용 하드웨어나 클라우드 기반의 인스턴스에 NoSQL 데이터베이스를 호스팅할 수 있어서,
수직적 확장보다 상대적으로 비용이 저렴하다
무엇을 사용해야 할까?
유저의 요구를 충족하기 위해 모두 사용하여 서비스에 맞게 설계한다
NoSQL 기반의 비관계형 데이터베이스가 확장성이나 속도면에서 더 뛰어나지만,
고차원으로 구조화된 SQL 기반의 데이터베이스가 더 좋은 성능을 보여주는 서비스도 있다
💫 관계형 데이터베이스를 사용하는 케이스
1. ACID 특성을 준수해야 하는 경우
<트랜잭션의 ACID 특성>
트랜잭션: 여러 개의 작업을 하나로 묶은 실행 유닛
ACID: 데이터베이스 내에서 일어나는 하나의 트랜잭션(transaction)의 안전성을 보장하기 위해 필요한 성질
원자성(Atomicity): 하나의 트랜잭션에 속해있는 모든 작업이 전부 성공하지 않으면 전부 실패해야 한다
일관성(Consistency): 트랜잭션이 테이블에 변경 사항을 적용할 때 미리 정의된 방식만 취한다
고립성(Isolation): 모든 트랜잭션은 다른 트랜잭션으로부터 독립되어야 한다
동시에 여러 트랜잭션들이 수행될 때, 각 트랜젝션은 격리되어 있어 연속으로 실행된 것과 동일한 결과를 나타낸다
격리성을 지키는 각 트랜젝션은 철저히 독립적이기 때문에, 다른 트랜젝션의 작업 내용을 알 수 없다
트랜잭션이 동시에 실행될 때와 연속으로 실행될 때의 데이터베이스 상태가 동일해야 한다
지속성(Durability): 하나의 트랜잭션이 성공적으로 수행되었다면, 해당 트랜잭션에 대한 로그가 남아야 한다
= 런타임 오류나 시스템 오류가 발생하더라도, 해당 기록은 영구적이어야 한다
- DB와 상호 작용하는 방식을 정확하게 규정할 수 있기 때문에 데이터를 처리 시 발생할 수 있는 예외적인 상황을 줄이고, 무결성을 보호할 수 있다.
- 전자 상거래를 비롯한 모든 금융 서비스를 위한 개발에서는 반드시 데이터베이스의 ACID 성질을 준수해야 한다
2. 소프트웨어에 사용되는 데이터가 구조적이고 일관적인 경우
규모가 큰 서버가 필요하지 않을 때, 다양한 데이터 유형과 높은 트래픽을 지원하도록 설계된 NoSQL 데이터베이스를 사용해야만 하는 이유가 없다
💫 비관계형 데이터베이스를 사용하는 케이스
- 데이터의 구조가 거의 또는 전혀 없는 대용량의 데이터를 저장하는 경우
- 소프트웨어 개발에 정형화 되지 않은 많은 양의 데이터가 필요한 경우
- 저장할 수 있는 데이터의 유형에 제한이 없기 때문에 언제든지 데이터의 새 유형을 추가할 수 있다
- 클라우드 컴퓨팅 및 저장 공간을 최대한 활용하는 경우
- 소프트웨어에 데이터베이스의 확장성이 중요할 때
- 클라우드 기반으로 데이터베이스 저장소를 구축하면, 저렴한 비용의 솔루션을 제공받을 수 있다
- 빠르게 서비스를 구축하는 과정에서 데이터 구조를 자주 업데이트 하는 경우
- 빠르게 개발할 때(시장에 빠르게 프로토타입을 출시해야 하는 경우) - 스키마를 미리 준비할 필요가 없다
- 소프트웨어 버전별로 많은 다운타임(데이터베이스 서버를 오프라인으로 전환하여 데이터 처리를 진행하는 작업 시간) 없이 데이터 구조를 자주 업데이트 해야하는 경우, 스키마를 매번 수정해야 하는 관계형 데이터베이스보다 적합
'Back-End > Database' 카테고리의 다른 글
정규화(Normalization) (0) | 2022.08.08 |
---|---|
SQL (0) | 2022.08.04 |
댓글