MongoDB의 장점(Feat. NoSQL...)

RDBMS의 경우

Boar의 각 행이 누구의(어떤 user)의 데이터인지를 알기 위해서는 위와 같이 user 정보를 적어 주는 방법이 있다.

그러나 이 방법은 RDBMS의 [데이터 중복]을 최소화한다는 철학에 반한다.

그래서 FK를 이용하여 테이블들끼리 서로 참조하게 만든다.

RDBMS의 장점

1. 데이터 중복 최소화

2. 데이터 변경 시, 해당 ROW만 변경하면 된다.(변경 용이)

 

MongoDB와 같은 NoSQL은 컬렉션(List, 그중에서도 ArryaList 배열이라고 생각하면 됨)을 사용해서 저장을 한다.

(Table 개념x,여담으로 MongoDB는 JavaScript로 만들어 져 있다.)

(참고로, {id : 1, username : ssar, phone : 010-222}을 하나의 [JSON Object]라고 부른다.)

MongoDB는 RDBMS와 달리, [데이터의 중복]을 허락한다. 

-> Board 컬렉션에 JSON Object를 그대로 삽입한다. ( RDBMS는 FK를 이용한다 )

 

MongoDB의 장점

1. SELECT할 때, JOIN 없이 한 방에 들고 올 수가 있기 때문에, 조회 퍼포먼스가 굉장히 좋음.

(그러나, insert할 때, 데이터의 중복을 한다는 점에서 insert 시에는 퍼포먼스가 안 좋음)

 

MongoDB의 (치명적인) 단점

1. 데이터의 일관성이 깨진다( 변경이 용이하지가 않다 )

-> USER 컬렉션에 "ssar"을 "kim"으로 바꿨다고 하자. 

RDBMS의 경우, 아무런 문제가 생기지 않지만, MongoDB의 경우, Board 컬렉션에 "ssar"이 그대로 남아 있게 된다.

데이터의 일관성(데이터의 불일치) 문제가 생긴다. 

 

Q. 어떨 때에 MongoDB와 같은 NoSQL을 사용하는 게 좋을까??

A. 데이터의 변경 작업이 거의 없고, 조회가 작업이 많고, 압도적인 조회 기능이 필요한 경우!

-> 인스타그램을 예를 들어 보자.

팔로워가 100만인 경우, 그 사람이 글 하나를 올려도 최소 수십만 명의 사람들이 그 글을 읽을 것이다.

즉, 최소 수십 만 번을 조회하여 각 팔로워들에게 보여줘야 한다. 

이 경우에는 조회 기능이 압도적으로 좋은 NoSQL DB를 선택하는 것이 좋다. 

(JOIN 연산이 없으니깐, SELECT 퍼포먼스가 매우 좋다)

 채팅앱의 경우에도, 상대방에게 나의 글을 조회하여 보여주는 것이 주 기능이므로, 

굳이 RDBMS를 선택할 필요는 없다.

(만약 이용자 수가 매우 적은 경우에는 사실 RDBMS를 사용하던, NoSQL을 사용하던 별 성능 차이 없음 ㅋㅋ)