TIL - MongoDB - RDBMS vs NoSQL

# MongoDB vs RDBMS

• NoSQL이란?

  • MongoDB는 대표적인 NoSQL 데이터베이스다. MongoDB의 특성에 대해 이해하려면 먼저 NoSQL의 기초적인 개념을 짚고 넘어갈 필요가 있다.

    NoSQL이 무엇의 약자인지는 사람에 따라 NoSQL, Not Only SQL, Non-Relational Operational Database SQL로 엇갈리는 의견들이 있습니다만, 현재 Not Only SQL로 풀어 설명하는 것이 다수를 차지하고 있다고 합니다.

  • NoSQL은 RDBMS(관계형 데이터베이스 관리 시스템)의 한계를 극복하기 위해 만들어진 데이터베이스 형태다. RDBMS가 가진 대표적인 문제점은 정규화 사용으로 인해 서비스의 성능이 저하된다는 점이다. 정규화란 데이터의 중복을 제거하고 무결성을 보장하기 위해 테이블을 분리하여 데이터를 저장하는 방식인데, 데이터를 읽는 과정에서 분리된 테이블을 연결하는 JOIN이 과도하게 사용되면서 웹 서비스의 성능을 떨어뜨리게 된다. 이에 반해 NoSQL은 데이터의 중첩이 허용되기 때문에 불필요한 JOIN을 최소화시킬 수 있고, 이는 데이터 쓰기 및 읽기 속도의 향상으로 이어진다. 초당 수십만 개의 데이터를 처리하는 서비스(소셜 네트워크, 온라인 서비스 등)가 많아지면서 NoSQL을 선호하는 이유다.

• MongoDB의 특징

  • MongoDB의 데이터베이스는 Collection의 집합이다. Collection이란 RDBMS의 Table과 유사한 개념이다. 차이점은 Table처럼 데이터의 구조(Schema)가 고정된 형식으로 정의되지 않는다는 점이다. 때문에, 사용자가 원한다면 언제든지 기존에 생성된 데이터의 형태를 바꾸거나 새로운 필드를 추가하는 것이 가능하다. 한마디로 MongoDB는 RDBMS보다 유연하게 데이터를 읽고 쓸 수 있는 장점을 지니고 있다.

  • RDBMS와 MongoDB를 직접 비교한 하단의 표를 참고하면, MongoDB에 대해 조금 더 쉽게 감을 잡을 수 있다.
    

  • MongoDB의 특징은1:N 관계의 데이터를 모델링하는 방법에서 잘 드러난다. 가령, 대표적인 RDBMS인 MySQL에선 1:N 관계의 데이터를 모델링하기 위해 Foreign Key(외래키)를 사용한다. 이는 1:N 관계로 설정하려는 데이터를 두 개의 테이블에 나눠서 저장한 뒤, 부모 테이블과 자식 테이블의 관계로 묶어주는 것을 말한다. 하지만 MongoDB에는 Foreign Key라는 개념이 존재하지 않는다. 대신 Embedded와 Reference라는 데이터 저장 방식을 사용함으로써, 1:N 관계의 데이터를 모델링한다.

• Embedded vs Reference

  • Embedded

    Embedded 저장 방법은 2가지 종류의 Document가 있을 때, 1개의 Document 데이터를 다른 Document key의 value에 저장하는 방법입니다.

    • Embedded의 이해를 돕기 위해 쉽게 설명하자면, 중첩된 형태의(nested structure) 데이터를 떠올리면 된다. RDBMS로 비유하면, 하나의 데이터 row(Documnet)가 필드값으로 또 다른 데이터 row(SubDocumnet)를 품고 있는 것과 같다. 아래의 이미지에서 products 필드가 Embedded 방식으로 데이터를 저장하고 있다.

    • Embedded 방식의 특징: 한 번의 데이터 읽기(Read)로 필요한 모든 데이터를 얻을 수 있기 때문에 읽기 성능이 향상된다.
      

  • Reference

    Reference 저장 방법은 pointer 개념으로 이해하면 쉬울 것 같습니다. Embedded 방식과 달리 Document를 통째로 저장하는 것이 아니라 참조 할 수 있도록 ID를 저장하는 것입니다.

    • Reference 방식은 RDBMS에서 Foreign Key 방식으로 데이터를 참조하는 것과 비슷하다고 생각하면 된다. Django에서 ORM 방식으로 데이터에 대한 정참조가 가능했던 것처럼, Reference를 사용하면 참조 중인 Document(RDBMS의 데이터 row에 해당) 의 데이터에 접근할 수 있다.

    • 참조 중인 데이터에 접근하려면 여러 번의 쿼리문을 실행해야 하기 때문에 읽기 성능 저하된다.

    • 데이터 일관성이 상대적으로 중요할 때 사용된다.
      

  • Embedded와 Reference의 적절한 사용 기준은 무엇일까?

    • Embedded

      • 자식 객체가 단독으로 사용되지 않고 부모 객체 내에서만 사용되는 경우 사용을 권장
      • Document의 용량이 16MB로 제한되므로, 자식 객체의 데이터가 자주 업데이트되어 전체 용량이 커질 우려가 있는 경우엔 사용하지 않는 것이 좋음
      • 데이터 읽기 성능을 향상시킬 필요가 있는 경우 사용

    • Reference

      • 자식 객체가 부모 객체와 별개로 단독으로 사용되는 경우 사용을 권장
      • 용량 제한이 없기 때문에 데이터의 잦은 업데이트로 인해 전체 데이터 용량이 꾸준히 증가할 것으로 예측될 때 사용하기 적합
      • 데이터 일관성이 상대적으로 중요한 경우 사용

# MongoDB는 언제 사용하는 것이 좋을까?

• 지금까지 NoSQL 데이터베이스인 MongoDB의 특징에 대해 알아봤다. 여기서 한 가지 의문점이 생긴다. MongoDB는 언제 사용하는 것이 바람직할까? 결론부터 말하자면, 많은 양의 데이터 읽기(read)가 필요한 경우이다. 이는 위에서 언급했던 Embedded 저장 방식을 선택하는 기준과 비슷하다. 구체적인 내용은 아래와 같다.

  MongoDB(NoSQL)는 언제 사용하는 것이 좋을까요?

  • 정확한 데이터 구조를 알 수 없거나 변경/확장될 수 있는 경우
  • 읽기(read)처리를 자주 하지만, 데이터를 자주 변경(update)하지 않는 경우 (즉, 한 번의 변경으로 수십 개의 문서를 업데이트할 필요가 없는 경우)
  • 데이터베이스를 수평으로 확장해야 하는 경우 ( 즉, 막대한 양의 데이터를 다뤄야 하는 경우)

  RDBMS는 언제 사용하는 것이 좋을까요?

  • 관계를 맺고 있는 데이터가 자주 변경(수정)되는 애플리케이션일 경우 (NoSQL에서라면 여러 컬렉션을 모두 수정해줘야만 합니다)
  • 변경될 여지가 없고, 명확한 스키마가 사용자와 데이터에 중요한 경우

👉 다음 글에선 MongoDB와 Mongoose의 설치 및 실행 방법에 관해 정리하겠습니다.