RDB vs NoSQL

Lukaid·2024년 1월 15일

회고

목록 보기

2/3

해당 포스팅은 청첩장 프로젝트를 하며 느낀 firebase 경험 회고에 포함되는 글입니다.

RDB vs NoSQL

전 직장에서 일할 때, firestore를 비롯해서 mongoDB, Redis등의 NoSQL을 사용하면서 RDB와의 차이점을 느꼈다. 그때 느낀 가장 큰 차이점은 별도의 테이블과 스키마를 만들지 않아도 되는게 편하다..? 정도였던 것 같다. 추가적으로 이렇게 해도 되나...? 싶은 왜인지 모를 불안함 정도?

이번 기회에 두 방식의 차이점을 정리해보고자 한다.

RDB의 단점

DB의 근본, Relational Database는 업계의 표준으로 사용되고 있는 만큼 아주 많은 장점들이 있다. 예를들면, ACID(Atomicity, Consistency, Isolation, Durability)를 지원하며, 안전한 테이블을 가지고 있고, 데이터의 중복을 최소화하며, 데이터의 일관성을 유지할 수 있다. 하지만, 오늘은 RDB의 장점이 아닌 단점을 조명해보고 NoSql로 넘어가는 빌드업을 해보자.

RDB의 단점1 : 경직된 스키마

RDB는 정확한 스키마를 사전에 정의해야한다. 이를 통해, 데이터의 일관성을 보장하고, 쿼리를 최적화 할 수 있고, 개발 및 유지보수가 편해지고, 데이터의 무결성을 보장할 수 있다. 하지만, 이는 데이터 구조가 변경될 때 유연성을 제한하고, 새로운 데이터 형식이나 요구사항에 대한 대응이 어려울 수 있다.

새로운 데이터를 추가하기 위해서는 스키마를 변경해야하고, 이미 해당 테이블에 많은 데이터가 있다면 새로운 컬럼을 추가하는 것은 부담이 될 수 있다.

RDB의 단점2 : 과도한 조인과 성능 하락

RDB는 데이터 중복제거를 위해 정규화를 진행합니다. 이를 통해, 중복을 최소화하여 일관성을 향상시키고, 검색 및 조회 성능을 향상시키며, 저장 공간을 절약할 수 있습니다. 하지만, 데이터를 가져오기 위해서는 여러 테이블 간에 JOIN을 수행하는 것이 필요하다. 복잡한 쿼리나 대량의 데이터에서 조인을 수행하면 성능 저하가 발생할 수 있다. (복잡한 JOIN은 read/write 성능에 영향을 미침)

RDB의 단점3 : scale-out 편하지 않음

트래픽이 많아 질수록 scale-out이 필연적인데, multi-master나 sharding등의 방법이 있긴하지만 rdb는 이에 유연하지 않다. scale-out을 위해 샤딩을 진행하면, 데이터가 분산되어 있기 때문에 JOIN이 불가능해지고, multi-master를 진행하면, 데이터의 일관성을 위해 복잡한 로직이 필요하다고 한다. (직접 해본적은 없어서 잘 모르겠다.)

RDB의 단점4 : ACID가 성능에 영향

RDB는 ACID(Atomicity, Consistency, Isolation, Durability) 특성을 보장하기 위해 트랜잭션을 사용한다. 이로 인해 데이터 일관성과 안전성은 확보되지만, 트랜잭션 처리로 인한 오버헤드가 발생하여 성능에 영향을 줄 수 있다.

특성	장점	단점
Atomicity (원자성)	트랜잭션 롤백 시 일관성 유지 (트랜잭션이 중간에 실패하면 롤백을 통해 트랜잭션 시작 전의 상태로 되돌릴 수 있음)	트랜잭션 완료까지 시간이 오래 걸릴 수 있음 (많은 양의 데이터를 처리하는 트랜잭션의 경우 시간이 오래 걸릴 수 있어 사용자 경험에 영향을 줄 수 있음)
Consistency (일관성)	데이터 일관성 유지 (트랜잭션이 성공적으로 완료된 경우 데이터베이스는 항상 일관된 상태를 유지)	일관성 유지를 위한 추가 비용 발생 (데이터베이스가 일관성을 유지하기 위해 추가적인 검증 및 조정이 필요하므로 처리 비용이 증가할 수 있음)
Isolation (고립성)	동시성 제어를 통한 데이터 무결성 유지 (동시에 여러 트랜잭션이 실행될 때 각 트랜잭션이 다른 트랜잭션에 영향을 미치지 않도록 고립된 환경을 제공)	동시성 제어로 인한 성능 저하 (트랜잭션 간의 충돌을 방지하기 위해 동시성 제어를 사용하면 일부 성능 저하가 발생할 수 있음)
Durability (지속성)	데이터 손실 방지 (트랜잭션이 성공적으로 완료된 경우, 그 결과는 영구적으로 저장되므로 데이터 손실을 방지할 수 있음)	디스크 I/O로 인한 성능 저하 (지속성을 보장하기 위해 디스크에 데이터를 저장하는데, 이로 인해 디스크 I/O에 따른 성능 저하가 발생할 수 있음)

NoSQL의 등장

2000년대 초중반에 폭발적인 인터넷 수요(특히, SNS)로 기존의 RDBMS로는 감당하기 힘든 트래픽이 몰리는 상황이 발생하게 되면서, high-throughput(고처리량), low-latency(낮은 지연 시간), high-availability(높은 가용성), high-scalability(높은 확장성)를 모두 만족하기가 어려워졌다. 또한 서비스의 형태가 다양해지면서, 비정형 데이터가 많아지고 스키마가 고정되어 있는 것에 대한 불편함이 커졌다. 이에 대한 대안으로 NoSQL이 등장하게 되었다.

일반적인 NoSQL의 특징

NoSQL 특징1 : 유연한 스키마 (mongoDB 기준)

일반적으로 NoSQL은 RDB의 Table에 해당하는 Collection을 가지고 있고, RDB의 Row에 해당하는 Document를 가지고 있다. (Column 즉 Field가 아닌 Row! 데이터 하나하나를 말한다!) 이러한 Document는 JSON 형태로 데이터를 저장한다. (심지어 Document안에 새로운 Collection의 삽입도 가능하다.)

이러한 특징으로 인해, NoSQL은 유연한 스키마를 가지고 있다. 즉, 데이터를 저장하기 전에 스키마를 사전에 정의할 필요가 없다. 이는 데이터의 유연성을 높여주고, 새로운 데이터 형식이나 요구사항에 대한 대응이 용이하다.

장점

빠른 개발 속도 : 초기 단계에서 스키마를 명확히 정의하지 않아도 되므로 빠른 프로토타이핑과 개발이 가능해진다.
유연한 데이터 모델: 다양한 데이터 형식을 수용할 수 있어 변화에 대응하기 편하다.

단점

데이터 무결성 위험 : 유연한 스키마로 인해 데이터 무결성이 약화될 수 있다. 적절한 관리 없이 스키마가 자주 변경되면 데이터 일관성이 유지하기 어려워질 수 있다. 따라서 application 레벨에서의 스키마 관리가 필요하며, 개발자들에게 조금 더 부담이 될 수 있다.

NoSQL 특징2 : 중복 허용 (mongoDB 기준)

RDB의 경우 정규화를 통한 최적화에 관심이 많다. 반면에 NoSQL은 중복을 허용하여, 데이터 간의 관계를 강제하지 않으면서, 데이터 읽기 속도를 높이고 쿼리 성능을 향상시키는 데 관심이 많다. 이를 통해 RDB의 정규화 된 테이블 간 JOIN을 피할 수 있다.

장점

높은 조회 성능 : 중복된 데이터를 사용하면 데이터 조회가 빨라지며, 복잡한 조인 작업을 피할 수 있다.
확장성 향상 : 중복을 허용함으로써 데이터베이스가 분산된 환경에서 쉽게 확장될 수 있다.

단점

데이터 일관성 관리 어려움 : 중복된 데이터로 인해 데이터 간의 일관성을 유지하기 어려워진다. 하나의 데이터가 변경될 때 모든 중복된 복사본도 업데이트되어야 한다. 마찬가지로 application 레벨에서의 스키마 관리가 필요하며, 최신 데이터 유지에 조금 더 신경써야 한다.

NoSQL 특징3 : scale-out 더 편함

NoSQL은 RDB에 비해 수평적 확장을 강조하며, 분산 환경에서 데이터베이스를 쉽게 확장할 수 있도록 설계되었다고 한다. 따라서 여러 서버에 데이터를 분산하여 처리하며, 높은 확장성을 제공한다고 한다.

NoSQL은 초기부터 분산 아키텍처를 가정하고 설계되었다. 이를 통해 여러 노드로 데이터를 분산 저장하고, 이를 하나의 클러스터로 묶어서 사용하는 방법이 가능하다. 이로써 db의 크기가 커져도 각 노드의 걸리는 부하를 줄일 수 있고, 한 노드에 장애가 발생하더라도 다른 노드에서 서비스를 지속할 수 있다. 이는 데이터의 중복 허용하고, 데이터 간의 관계를 강제하지 않기 때문에 테이블 간 JOIN이 필요 없어서 가능한 것이다.

장점

데이터 처리량 향상 : Scale-Out을 통해 시스템의 데이터 처리량을 효과적으로 확장할 수 있다.
비용 효율성 : 더 많은 서버를 추가함으로써 성능을 향상시킬 수 있어, scale-up보다 성능 향상에 대한 비용 효과가 더 높다.

단점

복잡성 증가 : 분산 시스템의 관리와 운영은 일반적으로 복잡해진다. 데이터 일관성, 분산 트랜잭션 등에 대한 처리가 어려울 수 있다.

NoSQL 특징4 : 더 높은 처리량

NoSQL은 초기부터 대량의 데이터와 높은 트래픽을 처리하기 위해 설계되었다. 수평적 확장성, 중복 데이터의 활용, 비정규화 등 다양한 기술적인 특징을 통해 더 높은 처리량을 제공한다. 즉, ACID의 일부를 희생하여, high-throughput(고처리량), low-latency(낮은 지연 시간)을 만족시키는 것이다.

장점

대규모 데이터 처리 : 높은 처리량을 통해 대규모의 데이터를 효과적으로 처리할 수 있다.
응답 시간 최적화 : NoSQL 데이터베이스는 빠른 응답 시간을 제공하며, 대용량 데이터셋에서도 빠른 조회 성능을 보장한다.

단점

복잡한 쿼리 처리 어려움 : 특정 복잡한 쿼리나 트랜잭션 처리에서는 RDBMS에 비해 어려움을 겪을 수 있다. NoSQL은 주로 단순한 쿼리 패턴에 최적화되어 있다.

정리

NoSQL의 특징	RDB의 특징
유연한 스키마	경직된 스키마
중복 허용	중복 제거
scale-out 편함	scale-out 어려움
더 높은 처리량	ACID 보장

지금까지 알아본 바와 같이 NoSQL은 RDB의 완벽한 대체제가 아니다. NoSQL은 RDB의 단점을 보완하고, 더 높은 처리량을 제공하기 위해 설계되었다. 따라서, 서비스의 특징을 잘 파악하고, 필요한 부분에서 적절하게 취사선택하는 것이 중요하다고 생각한다. (사실 주니어 개발자 입장에서, NoSQL을 사용하면서 느낀 가장 큰 장점은 스키마를 사전에 정의하지 않아도 되는 것이 아닐까 싶다. 특히 서버리스 환경에서는 더더욱 그렇다.)

추가적으로 NoSQL중 하나인 firestore를 사용하면서 느낀점을 정리해보고자 한다. 사실 전반적으로 만족도는 상당히 높았다. 프로적트가 db에 그렇게 큰 의존도가 있지는 않았고, 높은 스펙을 필요로 하지도 않았다. 그래서 느낀 가장 큰 단점도 RDB와 NoSQL의 특징에서 기인하는 것이 아닌, firestore는 sql이 아니라 API 형식으로 데이터를 가져오기 때문에, 데이터를 가져오는데 있어서 조금 불편함이 있었다. 이를 제외하고는 firestore를 사용하면서 느낀 단점은 없었다.