1. 스키마리스라는 특징 때문에 무결성이 부족함

   -> 잘못된 타입이나 누락된 필드가 저장되더라도 DB 차원에서 막지 못함

   -> 그래서 결국 애플리케이션 rdbms처럼 타입 설정하고 무결성 방어 로직을 추가해야함

   -> 그렇게 할 바에 rdbms를 쓰는게 맞음

   
   

2. 몽고디비에서 트랜잭션 구현

   -> 몽고디비에서 트랜잭션을 구현하려면 최소 2개 (보통 3개)의 레플리카셋을 만들어야함

   -> 왜 보통 3개냐면 (프라이머리, 세컨더리, 아비터) 이런 구조로 구현하게됨.

   -> 만약 프라이머리 노드에서 문제가 생기면 투표를 통해 과반수를 얻은 새로운 프라이머리 노드를 선출함

   -> 이렇게 트랜잭션을 구현할 바에 단일 노드로도 트랜잭션이 지원되고 훨신 더 빠른 rdbms를 사용하는게 맞음

   -> 그럼에도 불구하고 몽고디비를 택했다면, 몽고디비 클라우드를 사용하는게 정신건강과 비용 측면에서 더 좋음

   
   

3. 복잡한 join ($lookup)

   -> nosql은 기본적으로 $lookup이 필요없게끔 설계해야함.

   -> 그런데 만약 lookup이 필요한 상황이 온다면 지옥이 시작됨.

   
   

4. 허위 마케팅

   -> 몽고디비는 빠르지 않음.

   -> 장점이라는 json은 postgres에서도 jsonb로 지원해주는데 이 부분에서 마저 몽고디비보다 포스트그리가 더 빠름

   
   

5. WiredTiger의 치명적인 문제점

   -> 데이터를 삭제해도 OS 디스크 공간으로 바로 반환되지 않고, WiredTiger 내부의 free list에만 남음

   -> 예를 들어 데이터를 hard delete로 계속 삭제한다면 디스크가 계속 커져서 나중에 디비가 터짐

   -> 그래서 compact라는 명령어를 써야하는데 수동으로 해야함.

   
   

이러한 문제점들을 극복하기 위해서 여러 기법들이 존재하지만, 먹기 힘든 음식을 어떻게든 맛있게 조리하는 방법을 배우는 거랑 다를게 없다.

친몽고 개발자는 쉽게 반몽고가 되지 않지만, 한 번 반몽고가 된 개발자는 다시 친몽고가 될 수 없다.

도구마다 그 쓰임새가 있지만, 몽고디비는 그 쓰임새에 비해 너무 과하게 사용됨.

하지만 쓰임새가 있다하더라고 몽고디비는 postgres같은 rdbms에 완벽하게 대체된다는 것.