🤔 프로젝트를 진행하기에 앞서서 어떤 DB를 사용해야 하는지 정해야 하는 경우가 있다. 각 DB는 어떤 특징을 가지게 되며 어떤 특징이 있는지 알아보자.
1 . 관계형 데이터베이스 (Relational Database)
관계형 데이터 베이스는 보통 데이터 베이스를 떠올리게 되면 가장 먼저 떠올릴 만큼 많이 사용되며,관계형 데이터 베이스의 종류도 정말 다양하게 많이 존재한다.
관계형 DB는 다음과 같은 테이블의 형태로 데이터 베이스를 저장한다. 각 테이블의 행과 행이 연결되는 관계를 맺고, 테이블 간의 관계는 일 대 일(1:1), 일 대 다(1:N), 다 대 다(N:N) 의 관계가 있다.
📌 관계형 DB의 특징
1. SQL 이라는 쿼리 언어를 사용한다.
2. 정규화
정규화는 사진과 같이 중복이 되는 것들을 다른 테이블로 빼서 중복을 제거를 하는 것이다. 이것을 반대로 하게 되면 '역정규화'라고 부르게 된다. 정규화를 하게 되면 중복이 제거되는 대신, 읽기와 쓰기에 좀 더 복잡한 query를 사용해야 하며 Join의 비용이 올라가게 된다.
3. ACID Transaction
| Atomicity | 트랜잭션이 "모두 성공하거나 모두 실패해야 한다"는 원자성을 보장. 실패 시 모든 작업이 롤백됩니다. |
| Consistency | 트랜잭션 전후로 데이터가 항상 일관된 상태를 유지해야 함. 데이터 무결성을 보장. |
| Isolation | 여러 트랜잭션이 동시에 실행될 때, 각각이 독립적으로 처리되어야 함. 다른 트랜잭션의 영향을 받지 않음 |
| Durability | 트랜잭션 완료 후에는 시스템 오류가 발생해도 데이터가 영구적으로 저장됨. |
ACID의 원칙을 따르기 때문에 데이터의 신뢰성 보장, 동시성 문제의 해결, 그리고 데이터의 무결성이 유지되기 때문에 데이터의 일관성이 높아진다. 따라서, 은행의 계좌 이체등 속도보다는 데이터의 정확도가 중요한 곳에 많이 쓰인다.
4. Schema
데이터베이스 스키마란 특정 데이터베이스의 구조 또는 구성에 대한 형식적인 설명, 청사진이라고 할 수 있다.
✅ 데이터베이스 스키마는 두가지의 기본 구성 요소가 존재한다.
물리적 데이터베이스 스키마 : 데이터가 스토리지 시스템에 물리적으로 저장되는 방식과 스토리지 형태(파일, Key-Value, 인덱스 등)를 말한다.
논리적 데이터베이스 스키마 : 데이터에 적용되는 논리적 제약 조건을 설명하고 필드, 테이블, 관계, 보기, 무결성 제약 조건등을 정의한다.
다음과 같은 스키마를 정해두고 엄격하게 따르게 한다.
5. 수직적 확장성
관계형 데이터 베이스는 기본적으로 단일 서버를 기준으로 하기 때문에 수직적 확장성에 열려있다. 수직적 확장성은 시스템 성능을 향상시키기 위해 기존의 단일 서버(또는 데이터베이스)에 더 많은 자원을 추가하는 방식으로 CPU, RAM, 디스크 용량 등의 하드웨어 스펙을 업그레이드하여 처리 능력을 높이는 방식으로 이루어진다
단점
- 초기 비용이 낮지만, 하드웨어의 물리적 한계에 도달하면 더 이상 확장 불가능.
- 고성능 서버는 비용이 기하급수적으로 증가하는 경향.
장점
- 하나의 데이터베이스 인스턴스에서 동작하므로 관리 복잡성이 낮음.
- 샤딩이나 데이터 복제와 같은 분산 시스템 설계가 필요하지 않음
2. 키-값(Key-Value) 데이터 베이스
다음과 같이 단순히 키와 값의 형태로 저장되는 DB이다(대표적으로 Redis가 존재한다). 매우 매우 단순하기 때문에 서브 DB로 대부분 사용이 된다. 하드 디스크가 아닌 RAM에 데이터를 저장하기 때문에 속도가 매우 빠르며 자주 쓰는 데이터를 캐시 해두고 사용하거나, 채팅 pub/sub 등의 용도로 쓰인다.
📌 키-값 DB의 특징
1. 단순한 구조
키(key)와 값(value) 쌍으로 데이터가 저장되며, 데이터 모델이 매우 간단하다.
ex) {"username": "joohyejeong", "email": "joohyejeong@example.com"}
2. 빠른 속도
3. Schema-less
스키마가 존재하지 않는다.
4. 비구조적 데이터
값은 일반 텍스트, JSON 객체, 바이너리 데이터 등 다양한 형태일 수 있으며, 데이터 형식이 매우 유연하다.
3. Document 데이터 베이스
도큐먼트 데이터베이스는 RDBMS에서 사용하는 Table, Row, Columns 대신 Collections, Document, 그리고 Field라는 이름을 사용한다. Document는 Json 형태로 저장되며 Schema를 엄격하게 관리하지 않아 관계형 데이터 베이스보다 높은 자유도를 가지고 있는 유연한 데이터 베이스이다.
📌 Document 데이터 베이스 특징
1. SQL이 아닌 DB마다의 쿼리 언어가 있다
ex) MongoDB : MQL(Mongo DB Query Language) , CouchBase: N1QL
2. 정규화를 하지 않으며 Schema를 엄격하게 관리하지 않는다.
Collection이 RDBMS의 테이블에 매칭되지만 정확하게 똑같은 것은 아니다. 예를 들어, 이력서를 다룰 때를 생각해 보면, 이력서는 스펙에 따른 여러 섹션과 인적 사항을 포함할 수 있다. 관계형 데이터베이스(RDB)를 사용할 경우, 각 섹션에 대해 정규화를 적용하여 별도의 테이블로 관리하게 된다. 그러나 하나의 이력서를 열람할 때마다 섹션 정보를 조인해야 하므로 복잡성이 증가하게 된다.
이와 달리, Document 데이터베이스는 정규화를 하지 않고 하나의 이력서에 모든 섹션 정보를 담아 설계할 수 있다. 이렇게 하면 각 섹션의 정보를 한 번에 불러올 수 있어 조인 작업이 필요하지 않다.
또한, Document 데이터베이스는 스키마 관리를 엄격하게 하지 않기 때문에, 이력서의 폼이 변경되더라도 새로운 섹션이 추가되더라도 쉽게 새로운 필드를 추가할 수 있다. 이는 매우 유연한 데이터 모델링을 가능하게 하며, 개발과 유지보수가 보다 수월해지는 효과가 있다.
3. 분산 처리의 유용성
분산 처리가 유용한 것은 noSQL의 특징이기도 하지만 그것을 가장 잘 나타내는 예시가 Document DB라고 할 수 있다. DB를 유연하게 분산할 수 있지만, 분산된 DB 간의 일관성이 떨어질 수 있다. 정확성보다는 속도가 중요한 SNS, 실시간 게시판, 그리고 실시간 채팅등에 주로 쓰인다.
4. 수평적 확장성
수평적 확장은 시스템을 여러 서버, 노드, 또는 데이터베이스 인스턴스 간에 나누어 데이터를 분산하는 방식이다. 기존 노드(서버)에 부담을 주지 않고 새로운 노드를 추가함으로써 성능을 증가시킬 수 있다.
장점
- 트래픽이 증가해도 추가 노드를 통해 시스템이 지속적으로 확장될 수 있다.
- 수많은 요청이 여러 노드로 나누어지기 때문에 부하가 균등하게 분산되며, 시스템의 가용성을 유지할 수 있다.
- 하나의 노드가 장애를 겪더라도 다른 노드가 데이터 처리를 이어가기 때문에 높은 가용성을 제공한다.
단점
- 데이터 동기화, 병렬 처리 등의 복잡한 관리가 필요하다
- 분산된 데이터가 서로 통신해야 하므로 네트워크 지연(Latency)이 발생할 수 있다.
- 시스템이 여러 노드로 나누어지기 때문에 데이터 일관성(Consistency) 관리가 어려워질 수 있다.
4. 칼럼 패밀리(Column-Family) 데이터베이스
✅ 칼럼 패밀리에 저장되는 데이터의 예시
Row(UserID=1, PurchaseDate='2024-12-31', ItemName='T-shirt', Price=20)
Row(UserID=1, PurchaseDate='2024-12-30', ItemName='Jeans', Price=40)
Row(UserID=2, PurchaseDate='2024-12-31', ItemName='Hat', Price=15)
Row(UserID=2, PurchaseDate='2024-12-30', ItemName='Socks', Price=5)
Column Family Database는 Cassandra와 같이 데이터를 Row와 Column으로 관리하는 NoSQL 데이터베이스의 유형이다. 행(Row)과 열(Column)을 기반으로 데이터를 저장하고 관리한다. RDB처럼 표 느낌으로 쓰고 싶은데 조금 유연하게 사용하고 싶을 경우 사용할 수 있는 데이터 베이스가 칼럼 패밀리 DB이다. 카산드라의 같은 경우에는 Row들마다 Partition Key를 설정하여 파티션 키를 바탕으로 예를 들어 회원들과 관련된 Row들을 조회할 수 있다( RDB의 테이블과 같은 맥락).
📌 Column-Family 데이터베이스 특징
1. SQL이 아닌 DB마다의 쿼리 언어 사용
ex) 카산드라 CQL(Cassandra Query Language)
2. 정규화를 하지 않으며 Schema를 엄격하게 관리하지 않는다
3. 복제와 분산 처리의 유용성
4. 수평적 확장성
5. 시간 데이터 기록 기능
일부 칼럼 패밀리 DB는 시간 기록을 관리할 수 있는 유연성을 제공한다. Cassandra를 포함한 일부 칼럼 패밀리 데이터베이스는 시간 기반의 데이터를 효율적으로 관리하며, Clustering Key 등을 사용해 시간 순서로 데이터를 정렬하고 처리할 수 있다(시계열 데이터를 다루기에 유용하다).
5. 그래프(Graph) 데이터베이스
그래프 데이터베이스(Graph Database)는 노드(Node), 엣지(Edge), 그리고 속성(Property)을 사용하여 데이터를 저장하고 처리하는 데이터베이스이다. 그래프 데이터베이스는 특히 복잡한 관계(연결성)를 처리하는 데 강점을 가지며, 비즈니스 데이터를 분석하거나 네트워크, 소셜 네트워크, 지식 그래프, 추천 시스템 등에서 사용된다. 정말 단순하게 말하면 그래프 구조를 데이터베이스에 응용하여 사용한다고 생각하면 된다. 비행기 노선, SNS 친구 관계, 추천 서비스 등 관계가 중요한 경우에 사용할 수 있다.
📌Comment:
꼭 하나의 어플리케이션에서 한 가지의 DB를 사용할 필요는 없다. 예를 MySQL을 메인으로 활용하더라도 캐싱 기능이 필요하게 되면 Redis를 사용하게 될 것이다. 같은 맥락으로 Join연산을 많이 하지 않게 되고 데이터의 일관성이 필요한 부분은 SQL 데이터베이스로 구현을 하고 반대로 데이터의 정규화가 비효율적인 부분은 noSQL 데이터 베이스를 함께 사용할 수 있을 것이다.
처음부터 데이터 베이스 분산과 수평적 확장을 고려한 상태로 MongoDB로 프로젝트를 시작할 수도 있다. 하지만, 만약 MySQL로 프로젝트를 시작하게 되었는데 단일 데이터 베이스가 너무 무거워져서 읽기/쓰기 기능들이 너무 오래 걸리게 된다면 샤딩을 통해서 이를 해결할 수도 있을 수 있다.
이처럼 다양하게 DB를 조합하고 상황마다 다르게 사용될 수 있을 수 있고 직접 프로젝트를 수행해보면서 경험을 쌓아가야겠다.
참고:
유튜브: '코딩 애플' - 개발시 데이터베이스 선택 가이드 (총정리) 🔗
블로그: Toss33 - 스키마 🔗
블로그: smf2545.log - 그래프 데이터 다뤄보기 🔗