MongoDB
목차
MongoDB란?
MongoDB는 문서 지향(Document-oriented) 데이터베이스로, 데이터를 BSON(Binary JSON) 형식으로 저장합니다. 이는 비정형 데이터를 처리하기에 매우 적합하며, 복잡한 관계형 데이터베이스의 스키마 제약 없이 유연하게 데이터를 관리할 수 있는 NoSQL 데이터베이스입니다.
주요 특징
- 스키마리스(Schema-less): 각 문서는 고유한 필드와 구조를 가질 수 있으며, 사전 정의된 스키마가 필요 없습니다.
- BSON 형식: 데이터를 BSON(이진 JSON) 형식으로 저장하여 더 많은 데이터 타입과 빠른 처리를 지원합니다.
- 수평적 확장(Sharding): MongoDB는 데이터를 여러 서버에 분산 저장하여 대규모 트래픽과 데이터를 처리할 수 있습니다.
- 고가용성: MongoDB는 리플리카셋(Replica Set)을 지원하여 데이터 복제 및 자동 장애 조치(Failover)를 제공합니다.
사용 사례
실시간 웹 애플리케이션, 로그 데이터 저장, 비정형 데이터 처리, 콘텐츠 관리 시스템(CMS) 등.
스키마리스(Schema-less)
MongoDB는 스키마리스(Schema-less) 구조를 갖고 있어, 데이터베이스에 저장되는 각 문서가 서로 다른 필드와 데이터 구조를 가질 수 있습니다. 이는 데이터의 유연성을 극대화하며, 미리 데이터 구조를 정의하지 않아도 데이터를 저장할 수 있다는 장점을 제공합니다.
장점
- 유연한 데이터 모델링: 데이터의 형식이 자주 변경되거나, 비정형 데이터를 저장할 때 매우 유용합니다.
- 빠른 개발 속도: 미리 스키마를 정의할 필요가 없으므로, 개발 초기 단계에서 빠르게 데이터를 저장하고 관리할 수 있습니다.
- 데이터 모델의 진화: 데이터 구조가 발전하거나 확장될 때에도 기존 데이터를 변경할 필요 없이 새 필드를 추가할 수 있습니다.
단점
- 일관성 문제: 스키마가 없으므로 필드와 데이터 구조가 다를 수 있어 일관성을 관리하는 것이 어려울 수 있습니다.
- 모델링 복잡성: 데이터의 일관성을 유지하기 위해 개발자가 수동으로 모델링을 관리해야 할 수 있습니다.
리플리카셋(Replica Set)
MongoDB의 리플리카셋(Replica Set)은 데이터베이스의 고가용성을 보장하기 위한 기능으로, 동일한 데이터를 여러 노드에 복제하여 장애 발생 시 자동으로 복구할 수 있도록 돕습니다.
구성 요소
- Primary 노드: 데이터를 읽고 쓰는 역할을 합니다. 모든 쓰기 작업은 Primary 노드에서 이루어집니다.
- Secondary 노드: Primary 노드의 데이터를 복제하여 백업 노드 역할을 합니다. Primary 노드가 장애를 일으키면, Secondary 노드가 자동으로 Primary 노드로 승격됩니다.
- Arbiter 노드: 투표에만 참여하며 데이터를 저장하지 않습니다. 주로 짝수 개의 노드로 구성된 리플리카셋에서 사용됩니다.
동작 방식
- Primary 노드에서 발생한 모든 쓰기 작업은 Secondary 노드로 복제됩니다.
- Primary 노드에 장애가 발생하면, 나머지 Secondary 노드들이 투표를 통해 새로운 Primary 노드를 선출합니다. 이 과정은 자동으로 이루어지며, 사용자 개입 없이 서비스 가용성을 유지할 수 있습니다.
장점
- 고가용성 보장: Primary 노드 장애 시 자동으로 Secondary 노드가 Primary로 승격되며, 다운타임을 최소화할 수 있습니다.
- 읽기 성능 향상: Secondary 노드에서 읽기 요청을 처리할 수 있어, 읽기 성능을 분산시키고 향상시킬 수 있습니다.
단점
- 데이터 일관성: 기본적으로 MongoDB의 리플리카셋은 최종 일관성(Eventual Consistency)을 따르므로, 모든 노드에 데이터가 즉시 복제되지 않을 수 있습니다.
- 복제 지연: Secondary 노드에 데이터가 복제되는 과정에서 지연이 발생할 수 있습니다.
샤딩(Sharding)
샤딩(Sharding)은 MongoDB에서 수평적 확장을 지원하는 방식으로, 대규모 데이터를 여러 노드에 분산하여 저장하는 기술입니다. 이를 통해 데이터가 특정 서버에 집중되지 않고 분산되어, 성능 및 저장 용량의 한계를 극복할 수 있습니다.
구성 요소
- Shard: 데이터가 저장되는 개별적인 MongoDB 인스턴스입니다. 각 Shard는 전체 데이터의 일부분만을 저장합니다.
- Config 서버: 샤드의 메타데이터를 관리하며, 샤드 간의 데이터 분포를 추적합니다.
- Query Router (Mongos): 클라이언트 요청을 적절한 샤드로 라우팅하는 역할을 하며, 사용자는 샤딩이 적용된 사실을 인식하지 못하고 사용할 수 있습니다.
샤딩의 동작
- 데이터가 샤드 키(Shard Key)를 기준으로 여러 Shard에 분산 저장됩니다.
- 클라이언트가 데이터를 조회하거나 쓰기 작업을 요청하면, Query Router가 적절한 Shard로 요청을 전달하여 작업을 처리합니다.
- 데이터가 분산 저장됨에 따라 대량의 데이터를 처리하거나 높은 트래픽을 처리할 수 있는 확장성을 갖습니다.
장점
- 무한한 확장성: 샤드를 추가하여 서버 용량이나 트래픽 처리 한계를 쉽게 극복할 수 있습니다.
- 부하 분산: 데이터를 여러 샤드에 분산하여 저장하므로 특정 샤드에 부하가 집중되지 않도록 할 수 있습니다.
단점
- 복잡한 관리: 샤딩은 설정과 운영이 복잡하며, 잘못된 샤드 키 선택은 성능 문제를 일으킬 수 있습니다.
- 일관성 관리: 샤드 간 일관성 문제가 발생할 수 있으며, 이를 해결하기 위해 트랜잭션 관리가 어려울 수 있습니다.
MongoDB VS MySQL
데이터 모델링 및 구조
MongoDB
- 문서 지향 데이터베이스로, 데이터를 BSON(Binary JSON) 형식으로 저장합니다.
- 스키마리스(Schema-less) 구조를 제공하여, 각 문서(레코드)가 서로 다른 구조를 가질 수 있습니다. 즉, 필드가 미리 정의되지 않아 유연성이 매우 높습니다.
- 비정형 데이터와 변동성이 큰 데이터를 처리하기에 적합합니다. 새로운 필드를 추가하거나, 데이터를 유연하게 변경해야 하는 경우 효율적입니다.
MySQL
- 관계형 데이터베이스로, 테이블 기반 데이터 모델을 사용합니다. 데이터를 테이블, 행, 열로 정형화된 구조로 저장하며, 각 테이블 간에 관계(Join)를 맺을 수 있습니다.
- 정형 데이터를 처리하는 데 적합하며, 데이터 스키마가 고정되어 있어 구조가 자주 변경되지 않는 경우에 유리합니다.
- 스키마 변경이 필요한 경우 마이그레이션 작업이 필요하며, 이로 인해 시스템에 영향을 줄 수 있습니다.
대규모 트래픽 관점에서
- MongoDB: 데이터 구조가 유연하여 빠르게 변화하는 데이터를 효율적으로 처리할 수 있지만, 일관성을 유지해야 하는 복잡한 관계형 데이터를 다룰 때는 효율이 떨어질 수 있습니다.
- MySQL: 정형 데이터와 복잡한 관계를 관리하는 데 매우 유리하지만, 데이터 구조가 자주 변하거나 비정형 데이터가 많은 환경에서는 유연성이 떨어집니다.
확장성(Scaling)
MongoDB
- 수평적 확장(Horizontal Scaling)이 뛰어나며, 샤딩(Sharding)을 통해 데이터를 여러 서버에 분산 저장할 수 있습니다.
- 클러스터 구성 시 여러 샤드에 데이터를 분배하여 성능과 저장 용량을 쉽게 확장할 수 있습니다.
- 대규모 트래픽 처리에 매우 유리하며, 특히 NoSQL의 특성상 수평적 확장이 기본적으로 고려되어 설계되었습니다.
MySQL
- 주로 수직적 확장(Vertical Scaling)을 사용합니다. 즉, 더 강력한 하드웨어로 서버를 업그레이드하거나 성능을 향상시키는 방식으로 확장합니다.
- 일부 수평적 확장을 지원하지만, 기본적으로 테이블 간 관계를 유지하기 위해 수평 확장이 제한적일 수 있습니다. 데이터베이스를 분할하거나 분산 처리하는 것이 복잡합니다.
- 읽기 성능을 향상시키기 위해 읽기/쓰기 분리(Read/Write Splitting)를 하거나, 리플리케이션을 통해 읽기 부하를 줄일 수는 있지만, 쓰기 작업은 여전히 확장에 한계가 있습니다.
대규모 트래픽 관점에서
- MongoDB: 대량의 트래픽을 수평적으로 분산하여 처리할 수 있어 확장성이 뛰어납니다. 특히, 샤딩을 통해 트래픽이 증가할 때도 시스템 성능을 유지할 수 있습니다.
- MySQL: 수평적 확장이 제한적이므로, 대규모 트래픽이 발생할 경우 성능 저하가 발생할 수 있습니다. 특히 쓰기 작업이 많을 경우 MySQL의 확장성은 MongoDB에 비해 불리합니다.
일관성 vs. 가용성 (CAP 이론)
MongoDB
- 최종적 일관성(Eventual Consistency)을 지원하는 AP 시스템(가용성과 파티션 허용성)입니다. MongoDB는 네트워크 분할이 발생해도 가용성을 유지하며, 데이터는 시간이 지나면서 일관성을 갖게 됩니다.
- 높은 가용성을 우선시하며, 분산 환경에서 데이터가 일시적으로 불일치할 수 있음을 감안한 설계입니다.
- Write Concern 설정을 통해 일관성과 가용성의 균형을 사용자 환경에 맞게 조정할 수 있습니다.
MySQL
- 강한 일관성(Strong Consistency)을 보장하는 CP 시스템(일관성과 파티션 허용성)입니다. 모든 트랜잭션은 즉각적으로 일관성을 보장하며, 네트워크 문제나 서버 장애 발생 시 일관성을 우선시하는 구조입니다.
- 트랜잭션에서 ACID(Atomicity, Consistency, Isolation, Durability) 속성을 완벽히 지원합니다. 특히 일관성이 중요한 시스템에서 MySQL의 ACID 특성은 매우 유리합니다.
대규모 트래픽 관점에서
- MongoDB: 최종 일관성을 제공하므로 일시적으로 데이터가 불일치할 수 있지만, 높은 가용성과 확장성을 제공합니다. 분산 환경에서 데이터를 저장하고 읽기/쓰기 작업을 동시에 처리하는 데 적합합니다.
- MySQL: 강한 일관성을 제공하므로 데이터의 정확성이 매우 중요한 시스템에서 유리하지만, 트래픽이 급증하거나 네트워크 문제가 발생할 경우 성능 저하가 발생할 수 있습니다.
트랜잭션 및 복잡한 쿼리 처리
MongoDB
- MongoDB는 4.0 버전부터 다중 문서 트랜잭션을 지원하며, ACID 트랜잭션을 보장할 수 있습니다. 하지만 트랜잭션 처리 성능이 RDBMS에 비해 떨어질 수 있습니다.
- Join 연산이 없고, 대신 Aggregation Framework를 사용하여 복잡한 데이터 처리를 수행합니다. 관계형 데이터베이스처럼 다중 테이블 간의 조인 작업이 필요한 경우 성능에 영향을 미칠 수 있습니다.
MySQL
- ACID 트랜잭션을 완벽히 지원하며, 복잡한 트랜잭션 관리가 가능합니다. 은행 거래, 주문 처리 시스템 등 정확성이 중요한 시스템에서 매우 유용합니다.
- Join 연산을 통해 여러 테이블 간의 데이터를 쉽게 결합할 수 있어, 복잡한 데이터 관계를 처리하는 데 매우 적합합니다.
대규모 트래픽 관점에서
- MongoDB: 트랜잭션 처리나 복잡한 관계형 쿼리에서 다소 성능이 떨어질 수 있지만, 대규모 트래픽에 맞춰 설계된 수평 확장 기능 덕분에 읽기 및 쓰기 처리가 매우 빠릅니다.
- MySQL: 복잡한 트랜잭션과 Join 연산이 빈번하게 발생하는 환경에서는 성능이 우수하지만, 트래픽이 급증하는 경우 확장이 어려울 수 있습니다.
복제 및 고가용성
MongoDB
- 리플리카셋(Replica Set) 기능을 통해 데이터 복제를 지원하며, 자동으로 장애 복구(Failover)를 처리할 수 있습니다. Primary 노드에 문제가 발생하면 자동으로 Secondary 노드가 Primary로 승격됩니다.
- 고가용성을 보장하며, 리플리카셋을 통해 읽기/쓰기 작업을 분산할 수 있습니다.
MySQL
- MySQL도 복제(Replication)를 통해 읽기 성능을 향상시킬 수 있으며, 마스터-슬레이브 구조에서 읽기/쓰기 분리를 통해 부하를 분산시킬 수 있습니다.
- 하지만 장애 복구(Failover)는 수동으로 처리해야 하거나 외부 도구(예: MHA, Orchestrator)를 사용하여 구성해야 합니다.
대규모 트래픽 관점에서
- MongoDB: 자동 장애 복구 기능을 제공해 고가용성을 유지하면서도, 대규모 트래픽에 대해 빠르게 대응할 수 있습니다.
- MySQL: 복제를 지원하지만, 자동 장애 복구가 기본적으로 지원되지 않으므로, 고가용성 설정이 복잡할 수 있습니다.
결론: 대규모 트래픽에서의 선택
MongoDB
- 대규모 트래픽 처리에 매우 적합하며, 수평 확장을 쉽게 할 수 있고, 고가용성을 기본으로 제공하는 분산 환경에서 매우 유리합니다.
- 비정형 데이터나 데이터 구조가 자주 변경되는 시스템, 빠른 읽기/쓰기가 필요한 환경, 유연한 데이터 모델링이 요구되는 경우에 MongoDB가 더 적합합니다.
- 예: 실시간 로그 수집, 빅데이터 처리, IoT 애플리케이션, 소셜 미디어 플랫폼.
MySQL
- 데이터 일관성이 중요한 시스템에서 적합하며, 복잡한 트랜잭션 관리와 관계형 데이터 모델을 요구하는 환경에서 우수한 성능을 발휘합니다.
- 고성능 트랜잭션 처리와 관계형 데이터가 중요한 시스템, 데이터의 무결성이 필수적인 경우에 MySQL이 더 적합합니다.
- 예: 금융 시스템, 주문 처리 시스템, ERP, CRM 시스템.
MongoDB와 MySQL은 각각의 강점과 약점을 가지고 있으며, 대규모 트래픽이 발생하는 환경에서는 MongoDB가 더 나은 확장성과 유연성을 제공합니다. 하지만, 트랜잭션 무결성이 중요한 환경에서는 여전히 MySQL이 강력한 선택입니다.