Post

[Database] RDBMS와 NoSQL 개념 비교 및 선택 가이드

[Database] RDBMS와 NoSQL 개념 비교 및 선택 가이드

서론

데이터베이스 종류가 많아질수록 “우리 프로젝트에는 어떤 DB가 맞을까?”라는 고민도 자연스럽게 생긴다. 이 글은 정답을 하나 제시하기보다, RDBMS와 NoSQL의 특징을 비교하면서 선택 기준을 정리해보려는 글이다.

그럼 바로 시작해보자.


DB의 종류

DB는 크게 두 종류로 나눌 수 있다.

  1. RDBMS (Relational Database Management System)
  2. NoSQL

RDBMS

  • RDBMS는 관계형 데이터베이스 관리 시스템을 의미한다. 관계형 데이터 모델을 기반으로 하며, 데이터를 2차원 테이블 형태로 표현한다.
  • 각 테이블은 다른 테이블과 관계를 맺을 수 있고, 이러한 관계를 표현하기 위해 외래 키를 사용한다.
  • 외래 키를 기반으로 테이블 간 JOIN이 가능하다는 점이 RDBMS의 가장 큰 특징이다.

NoSQL

  • NoSQL은 Not Only SQL의 약자로, 테이블 간 관계를 엄격하게 정의하지 않는 방식의 저장 기술을 통칭한다.
  • 일반적으로 하나의 테이블이나 컬렉션에 필요한 데이터를 함께 저장하며, 테이블 간 JOIN을 중심으로 동작하지 않는다.
  • 데이터와 트래픽이 급격히 증가하는 환경에서, 비용 효율적으로 확장하기 위한 Scale-Out 중심의 구조로 발전해왔다.

1. Key-Value DB

  • Key-Value DB는 데이터를 KeyValue의 쌍으로 저장한다.
  • Key는 Value에 접근하기 위한 식별자로 사용되며, Value는 다양한 형태의 데이터를 담을 수 있다.
  • 구조가 단순한 만큼 조회 속도가 빠른 편이다.

ex) Redis, Riak, Amazon DynamoDB 등

2. Document DB

  • Document DB는 Key-Value 구조와 비슷해 보이지만, Value 대신 구조화된 Document 단위로 데이터를 저장한다.
  • 객체와 관계 사이를 복잡하게 매핑하지 않아도 되는 경우가 많다.
  • 유연한 스키마와 문서 단위 조회에 강점이 있다.
  • 대신 쿼리 방식은 SQL과 다르다.

ex) MongoDB, CouchDB 등

3. Wide Column DB

  • Wide Column DB는 행과 열 중심 구조를 가지면서도, 열 집합을 유연하게 확장할 수 있는 형태의 DB다.
  • Key는 Row와 Column-family, Column-name을 식별하는 데 사용된다.
  • 연관된 데이터는 같은 Column-family 안에 저장되며, 각 데이터는 서로 다른 Column-name을 가질 수 있다.
  • 대규모 분산 저장에 유리한 편이다.

ex) HBase, Hypertable 등

4. Graph Database

  • Graph DB는 데이터를 Node, Edge, Property 구조로 저장한다.
  • 객체와 관계 자체를 그래프로 표현하기 때문에, 관계 탐색이 중요한 경우에 특히 적합하다.
  • SNS, 추천 시스템, 경로 탐색 같은 문제에 잘 어울린다.

ex) Neo4j

RDBMS와 NoSQL의 장단점

RDBMS

장점

  • 명확한 데이터 구조
  • 데이터 중복 방지
  • 관계형 데이터 처리에 강함

단점

  • 시스템이 커질수록 복잡한 JOIN 쿼리가 많아질 수 있음
  • 확장 방식이 주로 Scale-Up 중심
  • 스키마가 엄격해 유연성이 떨어질 수 있음

NoSQL

장점

  • 스키마가 유연해 데이터 구조 변경에 대응하기 쉬움
  • 분산 저장과 Scale-Out에 유리함

단점

  • 데이터 중복이 생기기 쉬움
  • 데이터 구조가 명확하지 않으면 관리가 어려워질 수 있음

그래서 무엇을 선택해야 할까?

  • RDBMS는 데이터 구조가 명확하고, 관계가 중요하며, 데이터 변경의 일관성이 중요한 시스템에 적합하다.
  • NoSQL은 데이터 구조가 자주 바뀌거나, 대규모 분산 처리와 유연한 확장이 중요한 시스템에 적합하다.

결국 중요한 건 “어떤 DB가 더 좋으냐”가 아니라 “현재 서비스의 요구사항에 어떤 DB가 더 잘 맞느냐”이다.

This post is licensed under CC BY 4.0 by the author.