NoSQL에 설명하기 앞서, RDB에 대해 간단히 생각해보자.
RDB의 특징
- 유연한 확장성 부족
특정 table이 존재하고, 그 table에 존재하는 데이터들에 새로운 요소를 추가해야된다고 가정해보자. 그러면 우리는 새로운 column을 추가해야되고, 결국 schema를 변경해야되는 상황이 돤다.
만약 table에 데이터의 양이 많고, 이러한 과정이 계속해서 일어난다고 생각해보자. 이렇게 되면 우리는 데이터를 write하는 데 많은 resource를 소모하게 된다. 결국 db 서버에는 부하가 걸릴 것이고, 이는 곧 서비스의 장애로 이어질 수도 있다.
이를 바탕으로 생각해 볼 수 있는 건, 결국 RDB는 데이터를 저장할 때 schema를 구성하여 저장을 하기 때문에 정의한 데이터의 형식에 변화가 생기게 되면 유연한 확장성이 떨어진다는 것이다.
- Join으로 인한 부하
RDB에서는 데이터의 중복을 방지하기 위해 정규화를 진행한다. 이로 인해 데이터의 정보를 전체적으로 보기 위해서는 Join이 필요하다.
결국, 정규화로 인한 중복은 제거가 됐지만, 전체적인 데이터를 불러오기 위해 필요한 Join 작업이 많아질수록 resource를 많이 필요로 하게 되기 때문에 이 또한 db 서버의 부하로 이어진다.
- scale out의 어려움
RDB는 1대의 서버 컴퓨터에 저장된다고 생각해보자.
서비스가 지속적으로 운영되고, db 서버가 처리해야 되는 정보량이 증가하면 부하를 감당하기 위해 서버를 확장해야 될 필요가 생긴다.
이 때 RDB 서버는 scale up 전략을 선택할 수 있다. scale up이란, db 서버의 하드웨어적 성능을 업그레이드하는 전략이다.
또, replication을 선택할 수도 있다. replication은 똑같은 정보를 가진 서버를 복사하고, 그렇게 복사한 서버는 read only로 하여, 일반적으로 가장 많이 처리하게 되는 read를 전용으로 처리하게 하는 전략이다. 하지만 이 전략은 write의 처리량을 근본적으로 해결하지 못하는 문제가 있다.
증가하는 write 처리량을 해결하기 위해 sharding, multi-master 전략이 존재하지만 기본적으로 RDB는 scale out에 적합한 db가 아니다. 여기서 scale out은 db 서버를 추가하는 방식으로 확장하는 전략이다.
replication은 scale out에 해당하지만, db 서버를 통째로 복사를 해줘야 한다는 문제가 있다. write 트래픽을 감당하기 위해 선택하는 sharding 전략 또한, 기존에 데이터가 존재한다면 데이터를 전부 옮겨야 하는 문제가 존재한다.
이처럼, RDB는 서버를 확장할 때 scale out 전략을 선택하기에는 좋지 않은 db이다.
- transaction ACID의 보장이 성능에 미치는 영향
transcation ACID의 보장은 RDB가 데이터를 안전하게 다루는 데 결정적인 역할을 한다. 하지만, 언제나 반대급부가 존재하듯, 어쩔 수 없이 성능 면에서의 하락은 피할 수 없다.
NoSQL의 필요성
각종 서비스의 사용자들이 늘고, 그 범위가 전 세계에 걸치기 시작하면서 방대한 양의 데이터를 빠르게 처리할 필요성이 증가했다. 또한, 다양한 사용자가 다양한 데이터를 생산해냈기 때문에 비정형 데이터도 증가했다. RDB에서처럼 데이터를 저장하기 전에 db에 schema를 만들고 그 형식에 맞게 데이터를 저장하는 것이 아닌, 정해진 형식이 없는 데이터를 저장할 필요가 생겼다. 이러한 이유로 NoSQL에 대한 관심이 증가했다.
NoSQL이란, Not Only SQL의 약자로, SQL이 미처 커버하지 못하는 부분까지 커버하겠다는 컨셉이다. NoSQL db는 다양한 종류가 존재하고, RDB에 비해 일관성이 떨어지기 때문에 db마다 차이가 존재한다. 때문에 일반적인 특성에 대해 먼저 알아보자.
NoSQL이란?
- flexible schema
Mongo DB를 예로 들어보자. RDB에서 다루는 schema를 Mongo DB에서는 collection이라 한다.
일반적으로 schema를 처음 구성할 때, schema의 요소들을 정의해줘야한다. 하지만 collection의 경우, collection의 명칭만 정의할 뿐, collection 안에 들어갈 data의 형태를 정의하지는 않는다.
따라서 해당 collection에 데이터를 집어넣고 싶을 때는 데이터의 형식을 자유롭게 정의할 수 있다.
또한 RDB와 마찬가지로 특정 조건을 만족하는 데이터를 조회할 수 있고, 여기서 RDB의 row, tuple에 해당하는 값을 document라고 칭한다.
schema가 flexible하기 때문에, schema의 data 형태 관리는 dbms가 아니라 application 레벨에서 개발자가 직접 해줘야 한다는 단점이 존재한다.
- 중복 허용
NoSQL에서는 정규화를 하지 않기 때문에 데이터의 중복을 허용한다. 때문에 데이터를 조회할 때 join을 할 필요가 없다.
물론 중복된 데이터들이 존재하기 때문에, 만약 데이터가 변경이 된다면 application 레벨에서 직접 수정을 해줄 필요가 있다.
- scale out 최적화
NoSQL은 RDB에 비해서 scale out을 쉽게 할 수 있다. 때문에 일반적으로 여러 개의 db 서버를 하나의 클러스터로 구성해서 사용하는 경우가 많다.
여러 서버에 데이터를 나눠서 저장을 해도, join이 발생하지 않기 때문에 다른 서버의 collection에 접근하지 않고 데이터를 처리할 수 있다. 같은 상황에서 SQL이라면 join이 필요할 때 다른 db 서버의 table에 접근해야되는 overhead가 발생할 확률이 높기 때문에 성능이 잘 나오지 않을 것이다.
- 높은 데이터 처리 성능
RDB와 달리 transaction을 통한 ACID를 보장하지 않기 때문에, 보다 높은 처리 성능을 보여준다.
하지만, 금융 시스템처럼 consistency가 중요한 작업을 할 때에는 당연히 적합하지 않다.
물론, NoSQL은 어떤 db인지에 따라 차이가 크기 때문에 세부적인 기능은 해당 db를 직접 확인해 봐야 한다.
