[Database] RDBMS와 NoSQL의 차이

이 글을 쓰게 된 이유

나는 그동안 NoSQL을 단순히 개념 배우며 살짝 테스트 형식으로 써보기만 했지 실전으로 써본 적은 없다.
다만 RDBMS는 확실하게, 당연하게 사용할 수밖에 없었는데도 불구하고…
최근 면접에서 이 둘의 차이점이나 특징을 얘기 못하고 끝난 적 있었다…ㅠㅠ;
그래서! 이왕 얘기 나온 김에 정리하면서 제대로 파악하고자 한다!

RDBMS?

우선 둘의 차이점을 알기 전에 각각의 특징과 개념은 알아야 하지 않을까?
RDBMS는 DBMS에서 Relational의 약자 R이 붙은 단어이다.

DBMS는?

그렇다면 DBMS는 뭘까?
사실 데이터베이스의 정의부터 파악해야겠지만, 우리는 이 글에서 RDBMS와 NoSQL의 차이점을 알고 싶은 것이니,
기본 개념은 알고 있다는 전제하에 간단히만 다뤄보자.
DBMS는 DataBase Management System의 약자로, 데이터베이스 관리 시스템이다.
다수의 사용자들이 데이터베이스 내의 데이터를 접근할 수 있도록 해주는 소프트웨어 도구의 집합인데, 유형과 종류가 매우 많다.

유형으로는 RDBMS, NoSQL DBMS, IMDBMS, CDBMS가 있고,
종류로는 대표적으로 Oracle, MySQL, MSSQL, MariaDB 등이 있다.

그래서 RDBMS란?

<데이터베이스 스키마 그림>

앞서 말했든 R은 Relational의 약자로, RDBMS는 관계형 데이터 베이스 시스템이라고 할 수 있다.
관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태로 표현하는 데이터베이스를 RDB라고 하며, 그를 다루는 시스템인 것이다.
RDBMS에서의 저장 방식은 SQL에 의해 저장되고 있으며 정해진 스키마에 따라 데이터를 저장하게 된다.

<프로젝트 때 사용했던 스키마>

위 그림과 같이 여러 테이블이 외래키(foreign key)를 이용하여 연결되어 있는 상황을 참고하면 된다.
user 테이블의 id는 고유키이지만 post 테이블의 userId, comment 테이블의 userId가 외래키로 연결되어 있다.

이렇게 테이블간의 관계에서 외래키를 이용한 테이블 사이 Join이 가능하다는 게 RDBMS의 가장 큰 특징이다.

NoSQL?

RDBMS의 한계

RDBMS는 데이터 관리에 가장 널리 사용되는 접근 방식이다. 하지만 이 관계형 모델에는 특정 사용 사례에서 문제가 될 수 있는 몇 가지 제한 사항이 존재한다.
이는 아래에 정리할 ‘RDBMS 단점’과 같다.

• 모든 데이터가 2차원 테이블끼리 연결되어 있다 보니 시스템이 커질 경우 JOIN문이 많은 복잡한 쿼리문을 사용해야 할 수 있다.
• 성능향상을 위해서는 수직적 확장(Scale up)만 지원.
  • 비용이 기하급수적으로 늘 수 있다.
• 스키마로 인해 데이터가 유연하지 않다. 스키마를 변경할 시 그 과정이 번거롭다.
  
  

여기서 말하는 ‘수직적 확장’이란 다음을 참고하면 된다.

• 수평적 확장(Scale out) : 수평적 확장(Horizontal Scalability)은 더 많은 서버를 추가해서 데이터베이스를 전체적으로 분산시키는 것을 의미한다.
  • ex) 하나의 처리 능력을 가진 서버에 동일한 서버 6대를 더 추가하여, 총 7의 처리 능력을 만드는 것.
• 수직적 확장(Scale up) : 수직적 확장(Vertical Scalability)는 CPU나 RAM 같은 부품이나 하드웨어를 추가해주거나 교체를 해 전체적인 성능을 향상시키는 것을 의미한다. 그래서 소프트웨어의 설계나 구조에 변화를 주거나 시간을 따로 쏟을 필요가 없다. 단순하게 데이터베이스 서버의 성능을 향상시킨다.
  
  

RDBMS의 또 다른 제한 사항은 관계형 모델이 구조화된 데이터 또는 사전 정의된 데이터 타입과 일치하거나, 최소한 미리 결정된 방식으로 구성되어야 데이터를 쉽게 정렬하고 검색할 수 있도록 설계되었다는 것이다. 하지만 이메일 메시지, 사진, 비디오 등과 같은 비정형 데이터가 보편화되었다는 사실이 이러한 제한이 더욱 크게 부각시켰다.
그래서 개발자들은 기존의 관계형 데이터 모델의 대안을 찾기 시작하였으며 이로 인해 NoSQL 데이터베이스의 인기가 높아졌다.

그래서 NoSQL이란?

딱 보면 ‘SQL이 아니다’ 같은 의미로 보이는데, 위키백과에서 참고된 이 글에 의하면 ‘non-relational’, 혹은 ‘non SQL’이라고 한다. 다만 NoSQL을 다룬 다른 글들을 참고하면 ‘Not Only SQL‘의 약자로 인식되기도 하는 듯하다.
NoSQL 데이터베이스는 전통적인 관계형 데이터베이스(RDBMS)보다 덜 제한적인 일관성 모델을 이용하는 데이터의 저장 및 검색을 위한 매커니즘을 제공한다.

즉 테이블 간의 관계를 정의하지 않는다.
앞서 언급한 이메일 메시지, 사진, 비디오 같은 비정형 데이터 및 빅데이터 등장으로 인해 데이터가 기하급수적으로 증가함에 따라 데이터베이스 성능 향상을 위해 등장했다.
RDBMS는 수평적 확장이 힘들기에 이러한 데이터베이스 형식이 생긴 것이다.
성능의 확장만 생각하고 보면 데이터 일관성 대신 성능 향상의 가성비를 따졌다고 볼 수 있겠다.

NoSQL에도 여러 종류가 있는데, 그중 대표적인 네 가지는 다음과 같다.

1. Key-Value Database
   • Redis, Riak, Amazon Dynamo DB
2. Document Database
   • MongoDB, CouthDB
3. Wide Column Database
   • HBase, Hypertable
4. Graph Database
   • Neo4J

RDBMS / NoSQL 장단점

장점

RDBMS

• 정해진 스키마에 따라 데이터를 저장하기에 명확한 데이터 구조를 보장
  • 구조의 완전성 보장
• 관계를 설정하기에 데이터를 중복없이 하나만 저장

NoSQL

• 스키마가 없기에 유연
• 언제든지 데이터를 조정하고 필드를 추가할 수 있음
• 수직 및 수평 확장 모두 가능하기에 데이터 분산 및 모든 읽기/쓰기 요청을 원활히 처리 가능
  
  

단점

RDBMS

• 테이블간의 스키마 관계에 의해 시스템이 커질 경우 JOIN문이 많은 복잡한 쿼리문을 사용해야 할 수 있음
• 성능향상을 위한 수직적 확장만 지원하며 비용이 크게 들음
• 스키마로 인해 데이터가 유연하지 않음
  • 스키마를 변경할 시 그 과정이 번거로움

NoSQL

• 데이터 중복이 발생할 수 있음
  • 중복된 데이터가 변경될 경우 모든 컬렉션에서 수정 수행 필요
• 스키마가 없기에 명확한 구조를 보장하지 않으며 데이터 구조를 결정하기 어려움
  • 구조 결정을 미루게 됨

RDBMS / NoSQL 선택

그렇다면 어떤 프로젝트에서 어떤 데이터베이스 시스템을 사용해야 좋을까?
위에 정리된 장단점들을 고려하여 선택하면 되지만, 좀 더 풀어서 정리하겠다.

RDBMS는 명확한 스키마가 중요할 경우, 보이는 스키마가 필요할 경우 유용하다. 또한 데이터 변경이 수시로 일어날 것 같다면 RDBMS를 사용하는 게 좋다.

NoSQL은 정확한 데이터 구조를 가늠하기 힘들면서 데이터 구조가 변경 및 확장이 될 가능성이 있을 경우 유용하다. 그러나 앞서 말했듯 데이터 변경이 일어날 경우 Update가 힘들기 때문에 이런 상황이 별로 일어나지 않을 때 사용하기 좋다.
또한 성능 향상을 하기 좋기에 막대한 데이터를 다뤄야 하는 작업에도 적합하다.

카카오페이로 커피사기 ❤️ 토스 계좌로 커피사기 ❤️