NoSQL

Contents

1. RDBMS

2. NoSQL

3. RDBMS와 NoSQL 차이

---

1. RDBMS

RDBMS는 데이터를 테이블 형태로 저장하고, 테이블 간의 관계를 기반으로 데이터를 관리하는 데이터베이스입니다. 대표적으로 MySQL, PostgreSQL, Oracle 등이 있습니다.

1.1 특징

1.1.1 정해진 스키마를 기반으로 데이터를 관리한다

RDBMS는 테이블 구조, 컬럼 타입, 제약 조건 등을 미리 정의합니다. 그래서 데이터 구조가 명확하고, 잘못된 형식의 데이터가 들어오는 것을 어느 정도 막을 수 있습니다.

다만 새로운 컬럼을 추가하거나 구조를 크게 바꿔야 할 때는 상대적으로 유연성이 떨어질 수 있습니다.

1.1.2 데이터 정합성을 지키는 데 강하다

RDBMS는 기본키, 외래키, UNIQUE, NOT NULL 같은 제약 조건을 통해 데이터의 일관성을 관리합니다.

예를 들어 주문 데이터가 있는데, 존재하지 않는 사용자 ID로 주문이 생성되면 안 됩니다.

users.id = orders.user_id

이런 관계를 DB 차원에서 관리할 수 있습니다.

1.1.3 트랜잭션과 ACID를 보장한다

RDBMS는 트랜잭션을 통해 여러 작업을 하나의 작업 단위로 묶을 수 있습니다.

예를 들어 결제 과정에서는 다음 작업들이 함께 일어나야 합니다.

1. 주문 생성
2. 결제 정보 저장
3. 재고 차감
4. 포인트 사용

중간에 하나라도 실패하면 전체를 롤백해야 합니다.

RDBMS는 이런 상황에서 ACID를 보장하기 때문에, 데이터가 어긋나는 문제를 줄일 수 있습니다.

1.1.4 JOIN을 통해 관계 데이터를 조회할 수 있다

RDBMS는 정규화를 통해 중복을 줄이고, 필요한 데이터를 JOIN으로 가져옵니다.

예를 들어 사용자 정보와 주문 정보를 따로 저장하고, 조회할 때 연결할 수 있습니다.

SELECT *
FROM users u
JOIN orders o ON u.id = o.user_id;

다만 JOIN이 많아질수록 쿼리가 복잡해지고, 성능 부담이 커질 수 있습니다.

1.1.5 Scale-out 적용 시 관계형 모델의 복잡도가 커진다

RDBMS도 Sharding, Multi-master 등을 통해 write 부하를 분산할 수 있다.
다만 NoSQL보다 도입이 까다롭다고 말하는 이유는, RDBMS가 테이블 간 관계, JOIN, 외래키, 트랜잭션, 강한 정합성을 전제로 하기 때문이다.

데이터를 여러 샤드로 나누면 기존에 한 DB 안에서 처리되던 JOIN이 분산 JOIN이 될 수 있고, 여러 테이블을 함께 수정하는 로직은 분산 트랜잭션 문제가 될 수 있다.
또한 Multi-master 구조에서는 여러 노드에서 동시에 write가 발생하므로 충돌 감지, 충돌 해결, 복제 지연, 일관성 보장 문제가 생긴다.

NoSQL도 샤딩과 복제 구조가 쉬운 것은 아니다. 다만 많은 NoSQL은 처음부터 분산 저장을 고려해 설계되었고, JOIN을 줄이거나 중복 저장을 허용하는 방식으로 데이터 모델을 구성한다.
그래서 관계형 모델과 강한 정합성을 유지해야 하는 RDBMS보다 수평 확장 설계의 부담이 상대적으로 작다.

---

2. NoSQL 특징 정리

NoSQL은 관계형 모델만을 사용하지 않는 데이터베이스입니다. 문서형, Key-Value, Column-family, Graph DB 등 다양한 형태가 있습니다. 대표적으로 MongoDB, Redis, Cassandra, DynamoDB 등이 있습니다.

2.1 특징

2.1.1 유연한 스키마를 가진다

NoSQL은 RDBMS처럼 정해진 테이블 구조를 강하게 요구하지 않는 경우가 많습니다.

예를 들어 MongoDB는 JSON과 유사한 문서 형태로 데이터를 저장합니다.

{
  "id": 1,
  "name": "Kim",
  "interests": ["travel", "food"]
}

다른 데이터는 이런 형태일 수도 있습니다.

{
  "id": 2,
  "name": "Lee",
  "age": 25,
  "address": {
    "city": "Seoul"
  }
}

즉, 데이터 구조가 자주 바뀌거나 비정형 데이터가 많을 때 유리합니다.

다만 스키마를 DB가 강하게 관리하지 않기 때문에, 애플리케이션 레벨에서 데이터 구조를 잘 관리해야 합니다.

2.1.2 JOIN을 줄이기 위해 중복을 허용한다

NoSQL은 조회 성능을 높이기 위해 데이터를 한 문서에 함께 저장하거나, 중복 저장하는 경우가 많습니다.

예를 들어 게시글과 작성자 정보를 함께 저장할 수 있습니다.

{
  "postId": 1,
  "title": "게시글 제목",
  "writer": {
    "id": 10,
    "name": "Kim"
  }
}

이렇게 하면 JOIN 없이 빠르게 읽을 수 있습니다. 하지만 작성자 이름이 바뀌면, 여러 문서에 중복 저장된 작성자 정보를 함께 수정해야 할 수 있습니다.

즉, 읽기 성능은 좋아질 수 있지만 데이터 정합성 관리는 애플리케이션 책임이 커집니다.

2.1.3 Scale-out에 유리하다

NoSQL은 많은 경우 분산 저장과 수평 확장을 전제로 설계되었다.

특정 key나 shard key를 기준으로 데이터를 여러 노드에 나누어 저장할 수 있고, 서버를 추가해 저장 공간과 처리량을 늘리기 쉽다. 또한 조회 단위에 맞춰 데이터를 문서나 key 중심으로 묶어 저장하는 경우가 많아, 요청을 특정 노드에서 처리하기 좋다.

2.1.4 일부 정합성을 완화하고 성능과 확장성을 얻는다

NoSQL은 모든 상황에서 강한 ACID를 보장하기보다, 성능과 확장성을 위해 일부 정합성을 완화하는 경우가 많습니다.

그래서 금융 거래, 결제, 재고 차감처럼 데이터 정합성이 중요한 도메인에서는 신중하게 사용해야 합니다.

물론 요즘 NoSQL도 트랜잭션 기능을 제공하는 경우가 있지만, 기본적인 설계 철학은 RDBMS와 다릅니다.

---

3. RDBMS와 NoSQL 차이

구분	RDBMS	NoSQL
데이터 구조	테이블 기반	문서, Key-Value, 그래프 등 다양
스키마	고정 스키마	유연한 스키마
관계 표현	JOIN 사용	중복 저장 또는 내장 문서
정합성	강한 정합성, ACID 중심	성능과 확장성을 위해 일부 완화 가능
확장 방식	Scale-up 중심, 일부 scale-out 가능	Scale-out에 유리
적합한 상황	결제, 주문, 회원, 재고 등 정합성이 중요한 데이터	로그, 피드, 캐시, 이벤트, 비정형 데이터
단점	구조 변경이 상대적으로 불편하고 JOIN 비용 발생	중복 데이터 관리와 정합성 관리 부담