RDBMS와 NoSQL의 선택: 어떤 데이터베이스를 사용할까?
프로젝트를 진행할 때 어떤 데이터베이스 사용할지 한 번은 깊게 생각해보게 된다.
특히 RDBMS에 적합한지 NoSQL에 적합한지부터 고려하게 되는 것 같다.
MySQL과 MongoDB를 기준으로 RDBMS과 NoSQL를 비교하여 살펴보면서 어떤 상황에 어떤 DB가 적합한지에 대해서 한 번 살펴보겠다.
RDBMS란?
RDBMS(Relational Database Management System)는 데이터를 테이블 형식으로 관리하는 데이터베이스 시스템이다.
테이블 간의 관계를 키(Key)를 통해 정의하며, SQL(Structured Query Language)을 사용하여 데이터를 조회, 삽입, 수정, 삭제한다.
대표적으로 MySQL, PostgreSQL,Oracle 등이 있다.
특징은 아래와 같다.
- 테이블 기반 구조: 데이터를 행(Row)과 열(Column)로 저장하며, 테이블 간 관계를 정의.
- 정규화: 데이터 중복을 최소화하여 데이터 무결성을 유지.
- 트랜잭션 지원: ACID(Atomicity, Consistency, Isolation, Durability) 속성을 보장.
- SQL 사용: 데이터 정의와 조작에 SQL이라는 표준 언어를 사용.
NoSQL이란?
NoSQL(Not Only SQL)은 정형화된 테이블 대신 유연한 데이터 모델을 사용하는 데이터베이스이다. 스키마가 고정되지 않고, 다양한 데이터 구조(Document, Key-Value, Column-Family, Graph 등)를 지원한다.
대표적으로는, MongoDB, Redis, Cassandra, DynamoDB 가 있다.
- 유연한 스키마:
- 몽고디비에서도 나름대로의 스키마나 규칙을 정의하지만, 추후 데이터에 필드가 추가되었을 때 이미 확실히 정의된 스키마를 바꾸지 않고 데이터에 필드를 추가하여 개발을 진행할 수 있어 스키마를 유연하게 변경 가능.(개발 속도 가속화)
- 여러 스키마를 데이터를 하나의 테이블에 보관함으로써 조회 성능 및 공간 가성비를 높일 수 있다. 온라인 쇼핑몰에서 각 카테고리에 따라 제품의 속성이 달라질 수 있다. 예를 들어, 의류는 사이즈(size)와 색상(color) 속성이 중요하고, 전자 제품은 배터리 수명(battery_life)과 전압(voltage) 속성이 중요하다. MongoDB에서는 이러한 서로 다른 속성을 가진 데이터를 같은 컬렉션에 저장할 수 있다. RDBMS라면 이를 위해 나머지를 null로 채워야 하겠지만 Mongodb는 해당 필드를 없애도 된다.
- 고성능: 대량의 데이터를 빠르게 처리할 수 있는 구조.
- 실시간 로그 데이터를 저장하는 시스템에서는 MongoDB의 높은 쓰기 성능을 활용하여 빠르게 데이터를 기록할 수 있다.
- 다양한 데이터 모델: 문서(Document)-MongoDB, 키-값(Key-Value)-Redis, 열(Column-Family)-Cassandra
- 반정형 및 비정형 데이터 처리: JSON, BSON 같은 형식의 데이터를 저장하고 관리하기에 적합
- IoT 장비에서 수집된 센서 데이터를 저장. 센서마다 다른 구조의 데이터를 전송하더라도 유연하게 처리 가능하다.
- 자동 샤딩(Sharding): 데이터가 자동으로 여러 서버에 분산되어 저장되어 확장성과 성능을 보장.
- 유연한 인덱싱: 복합 인덱스, 텍스트 인덱스, 해시 인덱스 등 다양한 인덱싱 기법을 제공합니다. 이를 통해 복잡한 질의 조건에서도 빠른 성능을 유지할 수 있다.
BASE 개념
NoSQL은 전통적인 ACID 특성을 일부 희생하는 대신, BASE라는 새로운 접근 방식을 채택하였다.
- Basically Available (기본적인 가용성)
- 시스템은 항상 가용성을 유지하며, 일부 데이터가 최신 상태가 아니거나 손실될 수 있어도 서비스는 중단되지 않는다.
- 예: 분산 시스템에서 특정 노드가 오프라인이어도 다른 노드가 요청을 처리.
- Soft State (유연한 상태)
- 데이터 상태는 반드시 일관성을 유지하지 않아도 됩니다. 데이터가 시간이 지나면서 변경되거나 복제본 간 불일치가 있을 수 있다.
- 예: 노드 간 데이터 동기화가 일정 시간 후에 이루어짐.
- Eventual Consistency (최종적 일관성)
- 모든 업데이트가 궁극적으로 모든 노드에 반영되어 일관성을 이룬다. 즉, 즉각적 일관성을 보장하지 않지만 시간이 지나면서 동기화된다.
- 예: SNS에서 사용자가 게시물을 작성하면, 시간이 지나 모든 사용자에게 표시.
BASE vs ACID
특징 | ACID | BASE |
일관성 | 강한 일관성 (Strong Consistency) | 최종적 일관성 (Eventual Consistency) |
가용성 | 데이터 무결성을 위해 일부 가용성을 희생 | 항상 가용성을 유지 |
복잡성 | 트랜잭션 중심, 복잡한 설계 | 단순한 설계, 고성능 |
하지만 MongoDB 4.0부터는 ACID를 지원한다!
4.0 버전부터 멀티 도큐먼트 트랜잭션을 지원하여 ACID(Atomicity, Consistency, Isolation, Durability) 속성을 충족할 수 있게 되었다. 혹시 프로젝트에서 MongoDB를 사용한다면, 이것을 염두하여 개발을 진행해야할 것 같다.
추가적으로 Mongodb의 여러 기능에 대해 알아보겠다.
ObjectId -> 자동으로 생성되는 Primary Key이다.
- Unix timestamp, 초 단위로 측정된 ObjectId 생성을 나타내는 4바이트 타임스탬프
- 프로세스당 한 번 생성되는 5바이트 임의 값. 이 임의 값은 기계와 프로세스에 고유.
- 첫 3 byte는 클라이언트의 머신별로 고유한 키(mac 주소나 ip 주소)를 이용하여 랜덤 값
- 다음 2 byte는 process id를 이용
- 임의의 값으로 초기화되는 3바이트 증분 카운터
이를 통해, 하나의 프로세스가 여러 도큐먼트를 생성할 때 중복될 확률이 매우 적다.
Atlas Cloud (+Search)
- 클러스터 관리/모니터링, 언제든 Replica 추가 혹은 Sharding 전환 가능
- Managed Data Lake/Federation
- Atlas Search(elastic search 처럼 구현 가능)
- 그 외
RDBMS vs NoSQL
특징 | RDBMS (MySQL) | NoSQL (MongoDB) |
데이터 모델 | 테이블 기반 (행과 열) | 문서(Document) 기반 |
스키마 | 고정된 스키마 | 유연한 스키마 |
확장성 | 수직적 확장 (더 큰 서버) | 수평적 확장 (서버 추가) |
쿼리 언어 | SQL | MongoDB Query Language |
트랜잭션 지원 | 강력한 트랜잭션 지원 (ACID 준수) | 제한적 트랜잭션 지원 (MongoDB 4.0부터 ACID 지원 가능) |
속도 | 소규모 데이터에서 안정적 성능 | 대량의 비정형 데이터에서 빠른 성능 |
아래는 aws에서 상황에 따라 어떤 자사 db를 선택하면 좋을지에 대한 가이드를 제시한 것이다. 어떤 프로그램을 개발하기 전에 db를 선택할 때에는 유형별로 내가 처해진 상황에 어떤 것이 적합한지에 대한 고민은 필수적이다.
언제 RDBMS를 선택해야 할까?
- 데이터 구조가 정형적이고 복잡한 관계를 가진 경우:
- ex) 은행 거래 시스템, ERP.
- 강력한 트랜잭션 보장이 필요한 경우:
- ex) 온라인 결제 시스템.
- 데이터 일관성이 중요한 경우:
- ex) 병원 환자 기록.
언제 NoSQL을 선택해야 할까?
- 유연한 데이터 구조가 필요한 경우:
- 예: 소셜 네트워크 데이터, 사용자 생성 콘텐츠.
- 대량의 데이터를 빠르게 처리해야 하는 경우:
- 예: IoT 센서 데이터.
- 수평적 확장이 필요한 경우:
- 예: 글로벌 사용자 기반 애플리케이션.
'Database' 카테고리의 다른 글
클러스터링과 리플리케이션에 대하여 (2) | 2024.12.27 |
---|---|
데이터베이스의 특징에 대해서 알아보자. (2) | 2024.12.24 |
정규화에 대해서 알아보자. (1) | 2024.12.24 |