본문 바로가기

CS 과목(CS科目)/데이터 베이스(データベース)

28. NoSQL( MongoDB, Redis, etc )

RDBMS의 단점

1. Column을 추가할 때마다, 스키마를 변경해야 한다( 경직된 스키마 )

2.  너무 많은 JOIN 연산을 하게 된다.( DB 서버의 CPU,메모리 과부하 )

데이터가 중복으로 저장되는 것을 막기 위하여 3NF, BCNF를 통해 아래와 같이 원본 테이블을 분할을 하였다.

그런데 만약 원본 테이블의 tuple을 조회하고 싶을 때, 위 4개의 table들에 대해 JOIN 연산을 해야 한다. 

이렇게 되면, DB 서버는 JOIN 연산을 실행하기 위하여, CPU와 메모리를 상당 부분 사용하게 될 것이다. 

3번째 단점을 살펴보기에 앞서 , scale - up과 scale out에 대한 알고 가자.

scale - up : 컴퓨터의 cpu, 메모리 등을 더 좋은 성능의 것으로 바꾸어서 퍼포먼스를 향상시키는 방법

scale - out : 똑같은 컴퓨터, 예를 들어 똑같은 DB 서버를 여러 대로 증설하여서 퍼포먼스를 향상시키는 방법

 

3. RDBMS의 세계관에서는, scale out하는 것이 그렇게 유연하지가 않다.

scale up

 

scale out

트래픽이 많이 몰려 1개의 DB 서버로 감당이 되지 않을 때, Scale up 혹은 Scale out의 방식으로 해결이 가능하다.

그러나 이 scale out 방식에도 문제가 생길 수도 있다.

예를 들어, 대부분의 트래픽이 read 작업인 경우에는 트래픽을 분산을 시켜서 Primary DB Server에 드는 부하를 굉장히 

줄일 수가 있다. ( Primary DB Server는 보통 read/write 작업을 2개 다 함 )

그러나 만약 대부분의 트래픽이 Write 작업인 경우에는 Primary DB Server로 트래픽이 다 몰리기에 cpu, 메모리에 굉장한

부하가 걸린다. 

또한 DB 서버를 증설하면서 DB Table들을 그대로 복사해줘야 하는 비용도 발생을 한다. 

 

4. ACID(대체적으로 Isolation이)가 성능에 영향을 준다.

 

위에서 언급한 RDBMS의 1~4 단점들에 의해, 2000년대 초,중반에 NoSQL이 폭발적으로 사용되기 시작하였다. 

-> 2000년대 초, 중반부터 우리나라를 비롯하여 전세계적으로 인터넷 보급이 폭발적으로 늘었다. 

그에 따라 SNS 등의 어플리케이션들이 전 지구적으로 서비스가 되기 시작하며 아래의 2가지 요구사항이 발생했다.

1. HIGH - ThroughPut ( 높은 처리량 )

2. low - latency ( 빠른 응답 )

위 1~2를 만족시키기에 RDBMS만으로는 한계가 왔다.

3. 비정형 데이터의 폭발적인 증가

-> RDBMS는 정해진 스키마에 맞춰진 정형적 데이터만을 처리할 수가 있는데, 비정형 데이터가 폭발적으로 증가를 하면

서 경직된 스키마 구조를 가지고 RDBMS로는 한계에 부딪히게 되었다. 

그래서 나온 것이 NoSQL( Not Only SQL의 약자  ) 이다.

NoSQL 종류는 매우 다양하고, 각 DBMS마다 특색이 있어서 표준화가 잘 되어 있지 않다. 

고로, 일반론으로서의 NoSQL을 설명을 하겠다. 

NoSQL의 특징

1. 유연한 스키마(Flexible schema)

기존의 경직된 스키마

 

NoSQL식의 스키마 선언!

(참고로, MongoDB 세계관에서는 DB Table을 Collection이라고 부른다)

데이터 삽입

 

데이터 삽입

 

데이터 조회

 

데이터 조회

RDBMS에서는 이러한 결과물을 ROW or TUPLE이라고 불렀는데, NoSQL 세계관에서는 Document라고 부른다.

 

2. RDBMS와 달리 중복 데이터를 허용( JOIN 연산을 하지 않아도 된다 )

중복되는 데이터를 허용

RDBMS는 데이터의 중복을 피하기 위하여 정규화를 통해 테이블을 분할하였지만, NoSQL에서는

분할하지 않음으로써 조회 시, JOIN 연산을 하지 않아도 된다. 

 

3. Scale - out에  최적화돼 있다.

 

각각의 서버에 데이터들을 일반적으로 나누어서 저장을 한다. 

그렇게 해서 쿼리 문을 실행을 할 때에, 각 서버로부터 필요한 데이터를 가져와서 응답을 해준다.

그러나, NoSQL은 중복된 데이터를 허용하므로, 똑같은 데이터

(솔직히 이 부분 잘 몰겠네 ㅠㅠㅜ)

 

4. ACID의 일부를 포기하여, high throuhgput와 low lateny 실현

-.> 금융 시스템처럼 consistency가 중요한 환경에서는 사용하기가 매우 조심

( 실제로, 금융권에서는 NoSQL을 잘 사용하지 않음 )

 

Redis

메모리 DB이자 캐쉬로도 사용이 된다.