RDB와 NoSQL

RDB의 문제점

스키마

RDB의 단점 중 하나는 새로운 컬럼을 추가하기 위해서는 스키마를 변경해주어야한다는 점이다. 그런데 이미 데이터가 많은 상태라면 스키마를 변경해서 새롭게 컬럼을 추가하는 작업은 DB 서버에 무리가 가고, 결과적으로 전체 서비스에도 안좋은 영향을 준다.

데이터가 많은 테이블에 대해서 스키마를 변경하는 작업은 상당히 부담스러운 작업이다.

확장성

또, RDB는 Schema에 맞춰서 데이터를 저장해야하기 때문에 확장성이 부족하다.

join 연산

마지막으로, RDB는 데이터 중복이 발생하지 않는 방향으로 설계하는 철학을 가지고 있다. 정규화를 하면서 중복된 데이터의 저장은 막을 수 있었지만 전체 데이터를 가져오고자 할 때는 여러 테이블의 join연산을 수행해야 하기 때문에 DB 서버에 무리가 간다.

복잡한 join으로 읽기 성능이 하락된다.

성능

성능 개선의 측면에서도 RDB는 단점을 가지고 있다. DB 서버를 CPU와 보다 나은 메모리로 바꾸는 scale-up을 할수도 있지만 데이터 서버를 추가시키는 scale-out에는 유연하지 않다.

레플리케이션을 한다고 해도 이미 있는 데이터를 카피하는 작업을 해야하고, Sharding을 한다고 하면 데이터를 다른 서버로 옮기는 과정이 필요하기 때문이다.

RDB는 DB를 scale-out하는 것에 유연하지 않다.

Transaction ACID

RDB 가 트랜잭션의 ACID를 보장해준다는 것은 분명한 장점이다. 하지만 RDBMS가 ACID를 보장하기 위해서 DB 서버의 퍼포먼스 중 일부를 소모한다. 그래서 Transaction ACID를 지키기 위해서 전체적인 처리량이 줄어든다.

NoSQL

배경

인터넷이 엄청나게 보급되고, SNS가 인기를 끌면서 높은 처리량과 낮은 응답시간이 요구되었다. 거기다 다양한 사용자들이 다양한 데이터를 발생시키다 보니 비정형 데이터가 증가했다. 결과적으로 Schema라는 틀을 정해놓고 일정한 데이터만 저장하기에는 어려운 상황이 발생하였고, 이러한 상황에서 등장한 것이 NoSQL 이다. Not Only SQL이라고 읽고, RDB가 커버하지 못하는 부분을 다룬다.

일반적인 특징

NoSQL에는 MongoDB, Redis, DynamoDB, neo4j, …등등 많은 종류가 있다. 모든 것을 살펴볼 수 없기 때문에 일반적인 특징에 대해서 알아보자.

Flexible Schema

RDB에서는 테이블을 만들 때 컬럼을 미리 정해주어야했다. 하지만 NoSQL에서는 스키마를 정해두지 않고 데이터를 넣고싶은 형태로 넣어줄 수 있다. 하지만 RDB 에서는 스키마의 관리를 RDBMS가 해주었지만 NoSQL은 애플리케이션 레벨에서 관리해주어야 한다. 개발자들이 컬렉션에 어떤 데이터가 들어가는지 관리하기 때문에 개발자의 부담이 늘어난다.

중복 허용 (join 회피)

RDB 에서는 중복된 데이터를 허용하지 않는 것이 철학이였기 때문에 정규화를 통해서 테이블을 쪼개 데이터 중복이 발생하지 않도록 했다. 그래서 전체 데이터를 얻고자 할 때는 join연산이 수행되었다.

NoSQL에서는 중복된 데이터를 허용해서 join이 발생하지 않도록 한다. 하지만 중복을 허용하는 만큼 애플리케이션 레벨에서 중복된 데이터들이 모두 최신 데이터를 유지할 수 있도록 관리하는 것은 개발자의 몫이다.

Scale-Out

RDB는 scale-out에 최적화 되어있지 않다. NoSQL은 계속해서 DB 서버를 추가하는 것만으로 scale-out할 수 있는 데이터베이스이다.

중복을 허용하는 것의 연장선 이기도 하다. 보통 서버 여러대로 하나의 클러스터를 구성하여 사용한다. 중복을 허용해서 데이터를 저장하기 때문에 여러 컬렉션을 조회할 필요 없이 한 컬렉션에 가서 데이터를 조회하면 된다.

클러스터가 만약 RDB였다면 각 테이블이 정규화되어 있을 것이고, 각 테이블을 분배해서 저장하게 된다. 여러 테이블이 각 서버에 흩어져 있으므로 조인해서 데이터를 가져오려면 네트워크 트래픽이 발생하는 등 어려운 점이 많아진다.

ACID의 일부를 포기하고 높은 처리량과 낮은 응답시간을 추구하는 것이 NoSQL의 철학이다. 하지만 금융시스템처럼 일관성(Consistency)가 중요한 환경에서는 아직 사용하기 조심스럽다.