MongoDB 개요

이 페이지에서는 NoSQL 의 대표 엔진중 하나인 MongoDB 의 등장배경, 특징등에 대하여 다룬다

이 페이지는 Perplexity Pro 의 검색 내용에 근거하여 작성하며 이에 따른 Perplexity 의 출처 링크도 같이 작성하며 공유한다.

 

 

MongoDB 의 등장배경

 

MongoDB 는 2007년 뉴욕의 신생 기업 10gen(현재 MongoDB Inc.)에서 웹 애플리케이션을 위한 PaaS(Platform as a Service) 제품의 핵심 데이터베이스로 개발되기 시작되었다. 이 때, 사용되는 DB 의 형태들은 RDBMS 였으나 RDBMS 는 Scale-Out, 정형 데이터 형태로 인하여 유연하지 않은 데이터구조등의 한계가 있었고, 이 때  MongoDB Inc. 는 이를 극복하기 위하여 MongoDB 를 개발했다. 이후 MongoDB Inc. 는 2009 년에 MongoDB 를 오픈소스로 대중에 공개하며 시장에 진출했다.

MongoDB라는 이름은 “huMONGOus(거대한)”에서 따온 것으로, 대규모 워크로드와 확장성을 염두에 두고 설계된 데이터베이스다.

 

출처

 

[1] https://ko.wikipedia.org/wiki/%EB%AA%BD%EA%B3%A0DB

 

[2] https://inblog.ai/jasonlee/7-mongodb-deep-dive-%EB%AA%BD%EA%B3%A0db-%EB%B6%84%EC%84%9D-4196

 

 

MongoDB 의 특징

 

위의 글에서 기재 한 데로, MongoDB 는 RDBMS 가 가지는 불리한점을 극복하기 위하여 개발된 DB 다

기본적으로 RDBMS 가 가지는 불리한점은 아래와 같다.

 

- 확장성의 한계(Scale-Out의 어려움)

 

RDBMS 는 Scale-up 등으로 단일 서버에 리소스를 더 크게 점유하여 작업을 처리하는데 유리하나 수평으로 서버 개수를 늘려서 작업을 처리하는데는 불리한 점이 있다. 클라우드 환경에서 이는 어느정도 보완이 되었지만 완전히 극복이 된 건 아니다.

 

- 스키마, 테이블 유연성 부족

 

RDBMS는 엄격하게 정의된 스키마 및 테이블 구조를 기반으로 데이터를 저장하는데 데이터, 스키마 구조가 변경될 경우 이를 변경해야 하는데, 이는 대규모 시스템에서는 시간이 오래 걸리고 서비스 중단 등 운영상 부담이 크다. 그래서 동적으로 데이터 구조가 자주 바뀌는 환경에 적합하지 않다.

 

- JOIN 등으로 데이터 조회가 관계가 복잡해 지면 필연적으로 느려지는 성능

 

위의 언급된 여러개의 테이블들의 데이터를 종합하여 조회하려면 JOIN 이 수행 되어야 하는데 데이터가 커질수록 JOIN 연산의 성능이 급격히 저하될 수 있다. 이는 데이터 이외에 종합할 테이블 개수도 성능저하에 영향을 준다.

 

- 비정형 데이터 처리의 어려움  

 

RDBMS 는 정형데이터기반이므로 이미지, 로그, 센서등의 비정형 데이터 관리에는 적합하지 않다.

 

- 비용 및 리소스 관리

 

RDBMS 는 규모가 커질수록 서버 리소스, 라이선스 관리 비용또한 급격하게 증가 할 수 있다.

 

- 운영상의 복잡성

 

RDBMS 는 부하 분석, 설계, 스키마 변경, 샤딩 등 운영 및 관리가 복잡하고, 실시간으로 반영되어야 할 서비스 요구사항에 대응하기 어렵다.

 

MongoDB 는 이와 같은 RDBMS 의 한계점을 극복하기 위해 만들어졌으며 이에 따라 아래의 특징이 있다.

 

- 스키마리스(Schema-less) 구조와 유연성

 

MongoDB는 스키마를 사전에 엄격하게 정의하지 않아도 되므로, 다양한 형태의 데이터를 자유롭게 저장할 수 있다. 이에 따라 데이터 모델의 변경이나 필드 확장이 매우 용이하며, 서비스 요구사항 변화에 빠르게 대응할 수 있습니다.

 

- 뛰어난 확장성(Scale-Out)

 

MongoDB는 샤딩(Sharding) 기능을 통해 데이터를 여러 서버에 자동 분산 저장하여 수평적 확장이 쉽다. 서버를 추가하는 것만으로 대용량 데이터와 트래픽 증가에 유연하게 대응할 수 있다. 또한 이러한 확장성은 서비스 중단 없이 온라인으로도 가능하다.

 

- 다양한 인덱스와 빠른 쿼리 성능

 

다양한 형태의 인덱스(복합, 해시, TTL, 공간, 부분 인덱스 등)를 제공하여 대용량 데이터에서도 원하는 조건으로 빠르게 데이터를 조회할 수 있다. 이는 실시간 검색, 위치 기반 서비스 등 다양한 요구에 적합하다.

 

- 개발 편의성과 직관성

 

JSON(BSON) 기반의 문서 모델은 개발자에게 익숙하고, 객체와 1:1 매핑이 가능해 개발 효율성이 높다. 쿼리 언어도 SQL과 유사해 접근성이 좋고, 데이터 관리가 직관적이다.

 

- 대용량 데이터 처리와 분산 집계

 

메모리 맵 방식과 분산 집계 파이프라인을 지원해 방대한 데이터를 빠르게 처리하고, 여러 서버에 걸쳐 집계 연산을 분산 실행할 수 있다. 데이터가 급증해도 성능 저하 없이 관리할 수 있다.

 

- 서비스 중단 없는 운영 및 관리

 

샤드의 확장·축소, 데이터 밸런싱, 스키마 변경 등 대부분의 작업을 온라인으로 처리할 수 있어, 운영 중에도 서비스 중단 없이 시스템을 관리할 수 있다.

 

출처

 

[1] https://velog.io/@krbibi/RDBMS-%EB%8B%A8%EC%A0%90

[2] https://aws.amazon.com/ko/compare/the-difference-between-relational-and-non-relational-databases/

[3] https://velog.io/@songyuheon/CS-Study-NoSQL%EA%B3%BC-RDBMS%EC%9D%98-%ED%8A%B9%EC%A7%95%EA%B3%BC-%EC%B0%A8%EC%9D%B4%EC%A0%90%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-%EC%9E%A5-%EB%8B%A8%EC%A0%90%EC%9D%84-%EB%93%A4%EC%96%B4-%EC%84%A4%EB%AA%85%ED%95%B4%EC%A3%BC%EC%84%B8%EC%9A%94

[4] https://velog.io/@wndbsgkr/MongoDB%EB%A7%8C%EC%9D%98-%ED%8A%B9%EC%A7%95%EC%9D%80-%EB%AD%98%EA%B9%8C