SQL vs NoSQL

NoSQL을 공부하면서 정리한 내용을 작성해보았어요.

취준생이기에 틀린 정보도 있지만 도움이 될 거 같아서 올려봅니다.

SQL(RDB)의 단점

NoSQL은 이름부터 알 수 있듯이 SQL이 탄생하고 그 이후에 만들어졌다.

그말은 즉, SQL의 대표 주자인 RDB의 단점들을 보완하기 위해서 탄생하였다는 것이다.

NoSQL이 탄생하게 된 배경을 알아보기 전에, RDB의 단점에 대해서 먼저 알아보자.

단점 1. RDB는 관물대와 같다.

군대를 갔다온 사람들이면 다들 알거다. (아니여도 읽으면 무슨 느낌인지 알거에요 ㅎㅎ)

군대에서는 숨 쉬는 것 빼고는 마음대로 할 수 없다.

관물대 정리에서도 마찬가지다.

내가 원하는 공간에 원하는 물건을 원하는 방향으로 정리하고 싶지만, 불가능하다.

왜냐하면 이마저도 규칙이 있기 때문에 무조건 규칙에 맞게 물건을 정리해야한다.

이는 RDB와 동일하다.

정해진 규칙에 어긋나게 데이터를 적재하면 오류가 발생하기 때문에 상당히 융통성이 없다고 할 수 있다.

단점 2. 스키마 변경이 매우 어렵고 비효율적이다.

쇼핑몰을 운영하는데, 주문 내용을 관리하기 위해서 Order라는 Table을 생성했다고 해보자.

만약, 형식에 맞게 데이터를 정리한다면 큰 문제는 없을 것이다.

하지만, 할인 이벤트와 같은 기간제 행사의 유무를 판단하려면 어떻게 해야할까?

당연한 말이겠지만, Order 테이블에 새로운 Column(is_event)을 추가해야할 것이다.

기존의 Order 테이블의 데이터양이 10개라면 문제가 없을 것이다.

허나, 1억 개의 데이터가 저장되어있다면 어떨까?

스키마를 변경해서 새로운 Column을 추가하는 것 자체가 매우 위험한 행위일 것이다.

왜냐하면, 해당 RDB를 배포하고 있는 서버의 부담도 커지게 될 뿐만 아니라, 전체적인 서비스에 안 좋은 영향이 끼칠 수 있다.

따라서 RDB는 유연한 확장성이 부족하다.

단점 3. 과도한 조인으로 인한 성능 하락

1번 단점에서 RDB는 정해진 규칙이 있다고 했는데, 그 중 하나가 정규화이다.

정규화를 간단하게 설명하자면, 데이터가 중복되면 자원의 낭비도 있을 뿐만 아니라, 비효율적이기 때문에 데이터의 중복을 막기 위해 만든 규칙 중 하나이다.

그래서 하나의 테이블을 여러 개로 나누는 경우가 많다.

그렇다면 이렇게 여러 개로 나뉜 테이블에서 원래의 전체 데이터를 가져오려면 어떻게 해야할까?

이때, join문을 사용하는데, 여러 개의 테이블을 각각 하나씩 비교해서 맞으면 데이터를 가져오는 작업이다.

당연히 테이블의 갯수가 많으면 많아질수록 DB 서버에서 자원 사용량이 증가하고 그에 따라서 응답 시간이 증가한다.

즉, 성능이 떨어지는 것이다.

단점 4. Scale-out이 어렵다.

보통 DB 서버는 하나가 존재한다.

트래픽이 증가한다면, 서버는 오직 하나만 존재하기 때문에 성능이 떨어진다.

이를 예방하기 위해서 사용되는 방법 중 하나가 Scale-out이다.

Scale-out은 서버를 복제하는 것인데, 서버의 정보를 복제하여 여러 개의 서버를 두는 것과 같은 효과가 있다.

하지만 복제품에 불과하기 때문에 read-only로 조회만 가능하다.

이러한 기능을 RDB는 사용하기가 어렵다는 단점이 있다.

단점 5. ACID이 성능에 영향을 끼친다.

1번 단점이 장점이 되는 경우도 있다.

그 중 하나가 ACID이다.

이는 데이터의 원자성이나 지속성, 독립성 등과 같은 보호되어야하는 요소들을 일컫는다.

RDB는 엄격한만큼 ACID를 잘 보호한다는 장점이 있다.

하지만, 무엇이든 Trade-off가 있기 마련이다.

ACID를 너무 보장하려다보니, DB 서버의 performance에 어느 정도 부정적인 영향을 준다.

NoSQL이 탄생하게 된 배경

인터넷 사용자가 기하급수적으로 늘어남에 따라서 위에서 언급한 단점으로 인해 RDB로는 생산성이 만족을 못하게 되는 상황이 발생하였다.

즉, high-throughput이 요구되었다는 것이다.

또한, 사용자들은 빠르게 정보를 얻고 싶어하기에 low-latency도 요구되었다.

뿐만 아니라, 비정형 데이터가 폭발적으로 증가하였는데, 기존의 비정형 데이터는 예상 가능해서 미리 스키마를 만들어놓고 데이터를 저장했지만, 이게 한계에 다다랐다.

RDB만로는 커버가 안되는 상황 !

NoSQL의 특징

따라서 탄생하였다

NoSQL : Not Only SQL(SQL이 하지 못하는 부분도 해준다. SQL이 아니라는 뜻은 아니다.)

NoSQL은 flexible한 스키마를 가지고 있으나, RDB와 다르게, 자동으로 스키마를 관리하는 기능이 없기 때문에 개발자가 관리해줘야한다.

그리고 중복을 허용하기 때문에 join을 딱히 쓸 필요가 없지만, 하지만 중복이 가능하기 때문에 application 레벨에서 중복된 데이터들이 모두 최신 데이터들을 유지할 수 있도록 관리해야한다.

scale-out이 용이하기 때문에 서버 여러 대로 하나의 클러스터로 구성하여 사용할 수 있다는 장점이 있다.

그러나, ACID의 일부를 포기하고 high-throughput, low-latency를 추구하기에 금융 시스템과 같이 consistency가 중요한 환경에서는 사용하기가 조심스럽다는 특징이 있다.

https://justgotothedesk.tistory.com/147