[DB] RDB vs NoSQL 📌

 

Database

• 일반적으로 컴퓨터 시스템에 전자 방식
• 저장된 구조화된 정보 도는 데이터의 체계적인 집합을 의미한다

 

 

 

DBMS

• Database Management System
• 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고 데이터베이스를 관리해주는 소프트웨어이다

 

 

SQL

• Structured Query Language
• 관계형 데이터베이스 관리 시스템의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어이다
• 관계형 데이터베이스 관리 시스템에서 자료의 검색과 관리, 데이터베이스 스키마 생성과 수정, 데이터베이스 객체 접근 조정 관리를 위해 고안되었다

 

 

 

 

RDBMS

• R은 Relationl의 약자로, RDBMS는 관계형 데이터베이스 관리 시스템을 의미한다
• 즉, RDB(Relational Database)를 관리하는 시스템이며 RDB는 관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태로 표현하는 데이터베이스이다
• RDBMS는 구성된 테이블이 다른 테이블들과 관계를 맺고 모여있는 집합체로 이해할 수 있다
• RDBMS에서는 테이블 간 관계를 나타내기 위해 외래 키(foreign key)를 사용한다
• 또한 테이블 간의 관계에서 외래 키를 이용한 테이블 간 Join이 가능하다
• 데이터의 중복이 허용되지 않기 때문에 Object 안에 Object를 넣을 수 없어 2개의 테이블의 데이터를 조인해서 사용한다

 

RDB의 특징

• SQL 쿼리 언어를 사용한다
• 테이블마다 스키마(Schema)를 정의해야 한다
• 데이터 타입과 제약으로 데이터의 정확성이 보장된다
• 속도보다 트랜잭션 시의 ACID가 중요하다
• 수직적 확장(Scale-Up)에 적합하다
• 데이터 중복이 없어 쓰기 속도가 빠르다
• 비용이 많이 들어 확장성이 좋지 않다
• Undo와 Redo를 제공한다
• MariaDB, MySQL, Oracle 등이 있다

 

💡 ACID
▷ Atomicity (원자성) : 트랜잭션이 중간에 중단되지 않고 처음부터 끝까지 수행하는 것
▷ Coinsistency (일관성) : 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태를 유지하는 것
▷ Isolation (격리성) : 트랜잭션 처리 중에 간섭하지 못하도록 하는 것
▷ Duraility (지속성) : 하나의 트랜잭션이 발생하면 하드디스크에 영구히 저장되는 것

- 스키마 : 데이터베이스에서 자료의 구조, 자료의 표현 방법, 자료 간의 관계를 형식 언어로 정의한 구조
- 트랜잭션 : 일을 처리하는 가장 작은 단위

 

 

RDBMS의 장점

• RDBMS는 정해진 스키마에 따라 데이터를 저장하여야 하므로 명확한 데이터 구조를 보장한다
• 관계는 각 데이터를 중복 없이 한 번만 저장할 수 있다

 

RDBMS의 단점

• 테이블 간 관계를 맺고 있어 시스템이 커질 경우 JOIN 문이 많은 복잡한 쿼리가 만들어질 수 있다
• 성능 향상을 위해서는 서버의 성능을 향상시켜야 하는 Scale-Up(수직적 확장)만 지원하기 때문에 비용 부담이 크다
  • 사실 Scale-Out(수평적 확장)이 가능은 하나, 테이블 간 의존 관계로 인해 다소 어려운 것이다
  • 따라서 분산된 데이터를 용이하게 관리하기 위해 대부분 Scale-Up을 지원하는 것이라고 생각하면 쉽다
• 스키마로 인해 데이터가 유연하지 못하다. 만약 스키마가 변경될 경우 번거롭고 관리가 어렵다

 

 

 

NoSQL

• Not Only SQL의 약자
• RDB 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 의미한다
• 또한 NoSQL에서는 RDBMS와는 달리 테이블 간의 관계를 정의하지 않는다
• 데이터 테이블은 그냥 하나의 테이블이며, 테이블 간의 관계를 정의하지 않아 일반적으로 테이블 간 Join도 불가능하다
• 데이터 중복이 가능하여 Object안에 Object를 넣을 수 있기 때문에 컬렉션과 컬렉션 간에 관계가 존재하지 않는다
• 하지만 데이터의 중복으로 인해 각각의 컬렉션의 데이터를 동기화하는데 시간이 걸리게 되는데, 이를 극복하기 위해 샤딩으로 MongoDB에서 이 기술을 제공하고 있다
• NoSQL은 점점 빅데이터의 등장으로 인해 데이터와 트래픽이 기하급수적으로 증가함에 따라 RDBMS에 단점인 성능을 향상시키기 위해서는 장비가 좋아야하는 Scale-Up의 특징이 비용을 기하급수적으로 증가시키기 때문에 데이터 일관성은 포기하되 비용을 고려하며 여러 대의 데이터에 분산하여 저장하는 Scale-Out을 목표로 등장했다
• NoSQL은 다양한 형태의 저장 기술을 지원하는데, 이를 통해 RDBMS 스키마에 맞춰 데이터를 관리해야 하는 한계를 극복하고 수평적 확장성(Scale-Out)을 쉽게 할 수 있다는 장점을 갖는다

 

NoSQL의 특징

• SQL 쿼리 언어를 사용하지 않는다
• 스키마를 반드시 정의하지 않아도 된다 (Schema-less)
• 사용 목적에 따라 ACID가 중요하지 않을 수 있다
• RDB의 확장성 이슈를 해결하기 위해 나온 데이터베이스 모델이다
• Key-Value 방식으로 데이터를 관리한다
• Scale-Out (수평적 확장)에 적합하다
• 데이터 중복이 가능해 읽기 속도가 빠르다
• Undo와 Redo를 제공하지 않는다
• 트랜잭션 관리가 안된다
• MongoDb, Redis 등이 있다

 

NoSQL의 저장 기술

1) Key-Value Database

• Key-Value Database는 데이터가 Key와 Value의 쌍으로 저장된다
• Key는 Value에 접근하기 위한 용도로 사용되며, 값은 이미지나 비디오 등 어떠한 형태의 데이터도 담을 수 있다
• 간단한 API를 제공하는만큼 질의의 속도가 굉장히 빠른 편이다
• 대표적인 NoSQL Key-Value Model로는 Redis, Riak, Amazon Dynamo DB 등이 있다

 

2) Document Database

• Document Database 데이터는 Key-Valule 형태로 저장된다
• Key-Value 모델과 다른 점이라면 Value가 계층적인 형태인 Document로 저장된다는 것이다
• 객체 지향에서의 객체와 유사하며, 이들은 하나의 단위로 취급되어 저장된다
• 즉, 하나의 객체를 여러 개의 테이블에 나눠 저장할 필요가 없어진다는 뜻이다
• Document Database는 객체를 Document의 형태로 바로 저장이 가능하기 때문에 객체-관계 매핑이 필요하지 않다
• 또한 Key-Value 모델과 같이 검색에 최적화되어 있다
• 그러나 사용이 번거롭고 쿼리가 SQL과 다르다는 단점이 있다
• Document 모델에서는 질의의 결과가 JSON이나 xml 형태로 출력되기 때문에 그 사용 방법이 RDBMS에서의 질의 결과를 사용하는 방법과 다르다
• 대표적인 NoSQL Document model로는 ModgoDB, CountDB 등이 있다

 

3) Wide Column Database

• Column-family Model 기반의 Database이며 이전의 모델들이 Key-Value 값을 이용해 필드를 결정했다면, 여기서는 Key를 통해 필드를 결정한다
• Key는 Row(키 값)와 Column-family, Column-name을 갖는다
• 연관된 데이터들은 같은 Column-family 안에 속해 있으며, 각자의 Column-name을 갖는다
• 관계형 모델로 설명하자면 Attribute가 계층적인 구조를 갖고 있는 셈이다
• 이렇게 저장된 데이터는 하나의 커다란 테이블로 표현이 가능하며, 질의는 Row, Column-family, Column-name을 통해 수행된다
• 대표적인 NoSQL Wide Column-family Model로는 HBase, Hypertable 등이 있다

 

4) Graph Database

• Graph Model에서는 데이터를 Node와 Edge, Property와 함께 그래프 구조를 사용하여 데이터를 표현하고 저장한다
• 개체와 관계를 그래프 형태로 표현한 것이므로 관계형 모델이라고 할 수 있다
• 이는 데이터 간의 관계가 탐색의 키일 경우에 적합하다
• 페이스북이나 트위터 같은 소셜 네트워크에서 파도타기(내 친구의 친구 찾기) 같은 기능에 적합하고, 연관된 데이터를 추천해주는 추천 엔진이나 패턴 인식 등의 데이터베이스로도 적합하다
• 대표적인 NoSQL Graph Model로는 Neo4j가 있다

 

NoSQL의 장점

• NoSQL에서는 스키마가 없기 때문에 유연하며 자유로운 데이터 구조를 가질 수 있다
• 또한 언제든지 저장된 데이터를 조정하고 새로운 필드를 추가할 수 있다
• 데이터 분산이 용이하며, 성능 향상을 위한 Scale-Up/Scale-Out 모두 쉽게 가능하다

 

NoSQL의 단점

• 데이터 중복이 발생할 수 있으며, 중복된 데이터가 변경될 경우 데이터 수정을 모든 컬렉션에서 수행해야 하는 번거로움이 존재한다
• 스키마가 존재하지 않기 때문에 명확한 데이터 구조를 보장하지 않으며, 데이터 구조 결정이 어려울 수 있다

 

 

 

데이터 요청 시 문제점

• CPU가 RAM 메모리에 데이터를 요청할 때 RAM에 적재되어 있는 데이터를 가져올 경우 I/O가 발생하지 않지만, 하드디스크에서 데이터를 가져와야 할 경우 I/O가 발생한다
• 이를 페이지 교체가 일어난다고 하는데, 이 때 속도가 현저히 떨어진다

 

💡 Blocking I/O
I/O 작업이 진행되는 동안 유저 프로세스는 자신의 작업을 중단한 채 대기하는 방식이다

 

 

 

문제 해결 방법

위의 문제를 해결하기 위한 방법으로 Scale-Up(수직적 확장)과 Scale-Out(수평적 확장)이 있다

Scale-Up은 컴퓨터의 성능을 업그레이드하는 방법이고, Scale-Out은 컴퓨터를 여러 대 사용하여 분산시키는 방법이다

 

 

Scale-Up (수직적 확장)

• 수직적 확장을 하게 되면 하나의 컴퓨터에서 데이터를 관리하기 때문에 데이터 쓰기(추가, 수정, 삭제)를 할 때 한 번에 할 수 있다
• 컴퓨터가 분산되어 있지 않아 동기화가 필요없어 데이터의 일관성이 유지된다
• 하지만 하나의 컴퓨터에서 데이터를 관리하게 되면 RAM의 공간에 한계가 있으므로 결국에는 하드웨어에서 데이터를 가져오게 되는데, 이 과정에서 I/O가 일어나기 때문에 데이터 읽기에서 성능이 떨어진다
• 이는 데이터 테이블이 서로 연계되어 있어 데이터 쓰기를 할 때 한 번에 할 수 있는 RDB 방식의 데이터 모델이 적합하다
• 주로 데이터 쓰기가 자주 일어나고 데이터의 정확성이 요구되는 정형화된 프로그램에서 도입된다

 

Scale-Out (수평적 확장 = RAID)

• 수평적 확장은 컴퓨터를 분산해서 데이터를 관리하는데, 이 때 '분산'이란 데이터를 나누어 갖는 것이 아닌 같은 데이터를 복제(=replica, 레플리카)하는 것을 의미한다
• 라우터에서는 각각의 레플리카의 가동 상태를 확인하여 최소한의 시간으로 데이터를 요청받을 수 있는 곳으로 보낸다
• 같은 데이터를 공유하고 있는 레플리카에서 데이터 쓰기가 일어날 경우, 레플리카 간의 동기화로 데이터를 업데이트 하는데 이는 동기화하는 과정에서 여러 번 쓰기를 해야하고, 동기화되는 시점에 따라 딜레이가 생겨 일관성을 유지하기 어렵다
• 하지만 동일한 데이터를 각각의 레플리카가 갖고 있기 때문에 읽기 속도는 매우 빨라진다
• 이는 데이터 테이블이 서로 연계되어 있는 RDB에서는 적합하지 않지만, 컬렉션 사이의 관계가 없고 중복된 데이터를 가질 수 있는 NoSQL 방식의 데이터 모델에 적합하다
• 주로 데이터의 정확성보다 읽기 속도가 요구되고, 쓰기보다 읽기가 자주 발생하는 SNS 등에 도입된다

 

💡 샤딩이란?
- NoSQL 데이터 모델의 느린 write(쓰기) 속도를 커버하기 위해서 MongoDB에서는 샤딩이라는 기술을 제공한다
- 샤딩은 같은 데이터를 복제하여 레플리카를 만들어내는 수평적 확장과는 달리, 데이터를 나누어 갖는 방식으로 라우터(mongos)에서는 메타 데이터(데이터의 저장된 위치 (index) : Config-Server) 정보를 갖고 있다
- 이는 수평적 확장의 단점인 쓰기 속도를 빠르게 한다

 

 

 

RDBMS vs NoSQL, 언제 사용해야 할까?

RDBMS

• 데이터 구조가 명확하며 변경될 여지가 없는 경우
• 명확한 스키마가 중요한 경우
• 중복된 데이터가 없어 데이터 무결성이 보장되고, 데이터 구조 변경이 용이

NoSQL

• 정확한 데이터 구조를 알 수 없고 데이터 구조의 변경 및 확장이 될 수 있는 경우
• 데이터 중복이 발생할 수 있으며, 중복된 데이터가 수정되는 경우 모든 컬렉션에서 수정을 해야하기 때문에 Update가 많이 발생하지 않는 시스템에 적합하다
• Scale-Out이 가능하기 때문에 막대한 데이터를 저장해서 Database의 Scale-Out이 발생할 수 있는 시스템에 적합하다

 

 

 

 

 

 

---

참고)

https://ud803.github.io/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4/2021/11/16/RDB-vs.-NoSQL-%EC%96%B8%EC%A0%9C-%EB%88%84%EA%B5%AC%EB%A5%BC-%EC%8D%A8%EC%95%BC%ED%95%A0%EA%B9%8C/

<데이터베이스> 관계형 vs. NoSQL 언제 무엇을 써야할까? · lee. ui dam

https://www.saichoiblog.com/rdb-nosql/

RDB와 NoSQL 비교하기Saichoiblog

https://khj93.tistory.com/entry/Database-RDBMS%EC%99%80-NOSQL-%EC%B0%A8%EC%9D%B4%EC%A0%90

[Database] RDBMS와 NoSQL의 차이점