몽고DB
MongoDB
MongoDB는 NoSQL 데이터베이스로, 데이터를 문서(Document) 형태로 저장하는 비관계형 데이터베이스다. BSON(Binary JSON) 형식으로 데이터를 저장하며, 스키마가 고정되어 있지 않고 유연하게 데이터를 다룰 수 있다.
MongoDB의 역사[편집 | 원본 편집]
2007년에 10gen이라는 회사에서 처음 개발되었고, 2009년에 공개되었다. 이후 MongoDB Inc.로 사명을 바꾸고, 계속해서 성능과 기능을 개선해왔다. MongoDB는 현재 클라우드 기반 데이터베이스 서비스인 MongoDB Atlas도 제공한다.
MongoDB의 특징[편집 | 원본 편집]
- 스키마 유연성: 데이터가 문서 기반으로 저장되기 때문에 스키마가 유연하여, 구조가 다른 데이터를 같은 컬렉션에 저장할 수 있습니다.
- 수평적 확장성: MongoDB는 샤딩을 통해 데이터베이스를 여러 서버에 분산하여 처리할 수 있습니다.
- 고성능: 대규모 데이터 처리와 고속 쓰기/읽기 성능을 제공합니다.
- BSON 형식: JSON과 유사한 바이너리 포맷을 사용해 데이터 크기를 줄이고, 다양한 데이터 타입을 지원합니다.
- 풍부한 쿼리 기능: 복잡한 쿼리를 지원하며, 인덱싱 및 집계 기능을 통해 효율적으로 데이터를 조회할 수 있습니다.
- 복제 및 고가용성: MongoDB는 복제를 통해 데이터의 가용성과 내구성을 보장합니다.
MongoDB 데이터 구조[편집 | 원본 편집]
- 데이터 저장 형태: MongoDB는 데이터를 BSON 포맷으로 저장하고, JSON 형태로 조회할 수 있어 직관적이다. 예를 들어, e-커머스 애플리케이션에서 제품 정보를
{ "name": "Laptop", "price": 1200, "specs": {"cpu": "i7", "ram": "16GB"} }형태로 저장할 수 있다. - 쿼리 예시: MongoDB는 복잡한 쿼리를 지원한다. 예를 들어, 사용자의 주문 내역을 필터링할 때
db.orders.find({ "user_id": 12345, "status": "delivered" })와 같은 쿼리로 데이터를 조회할 수 있다.
샤딩[편집 | 원본 편집]
MongoDB의 샤딩은 데이터베이스가 커지면서 한 서버에 데이터를 모두 저장하기 어려운 경우, 데이터를 여러 서버(샤드)로 분산 저장하는 방법이다. 샤딩을 통해 MongoDB는 수평적 확장을 가능하게 하며, 대규모 데이터를 처리하는 애플리케이션에서 성능을 유지하는 데 유리하다. 예를 들어, 대규모 온라인 상거래 시스템에서 `order_id` 필드를 샤드 키로 설정해 주문 데이터를 분산시킬 수 있다. 고객이 주문을 할 때, Mongos가 적절한 샤드에 주문 데이터를 저장하고, 나중에 그 데이터를 조회할 때도 빠르게 해당 샤드로 접근해 결과를 가져올 수 있다.
MongoDB의 샤딩은 대규모 데이터를 처리하는 시스템에서 필수적인 기능이지만, 샤드 키와 클러스터 구성을 잘못 설정하면 성능이 떨어질 수 있으니 신중한 설계가 필요하다.
샤딩의 주요 개념[편집 | 원본 편집]
- 샤드(Shard)
- 각 샤드는 데이터의 일부를 저장하는 독립적인 MongoDB 서버다. 샤드는 서로 다른 데이터를 저장하며, 각 샤드는 자신이 처리할 데이터에만 책임이 있다. 이는 수평적 확장을 가능하게 하며, 데이터가 늘어남에 따라 새로운 샤드를 추가할 수 있다.
- 샤드 키(Shard Key)
- 데이터를 여러 샤드에 나눠 저장하기 위해서는 기준이 필요하다. 이 기준이 되는 것이 바로 샤드 키이다. 샤드 키는 컬렉션 내의 특정 필드로, MongoDB는 이 키를 기준으로 데이터를 분산시킨다. 샤드 키를 잘못 선택하면 데이터가 고르게 분산되지 않아 성능 저하가 발생할 수 있다.
- 예를 들어, `user_id` 같은 필드를 샤드 키로 사용하면 사용자가 고르게 분산될 수 있지만, 날짜 필드를 샤드 키로 사용하면 특정 날짜에 쏠림 현상이 발생할 수 있다.
- 데이터를 여러 샤드에 나눠 저장하기 위해서는 기준이 필요하다. 이 기준이 되는 것이 바로 샤드 키이다. 샤드 키는 컬렉션 내의 특정 필드로, MongoDB는 이 키를 기준으로 데이터를 분산시킨다. 샤드 키를 잘못 선택하면 데이터가 고르게 분산되지 않아 성능 저하가 발생할 수 있다.
- Config 서버
- 샤딩을 관리하는 데 필요한 메타데이터(샤드 구성, 샤드 키 등)를 저장하고, 클러스터의 상태를 관리하는 서버다. Config 서버는 샤드의 위치와 데이터를 어떻게 분배할지에 대한 정보를 저장하며, 클러스터에 필수적인 요소다.
- 몽고스(Mongos)
- Mongos는 샤드 클러스터에서의 라우터 역할을 한다. 클라이언트는 Mongos를 통해 데이터베이스에 접근하며, Mongos는 적절한 샤드로 요청을 라우팅한다. 클라이언트는 MongoDB가 샤딩되어 있다는 것을 알 필요 없이, Mongos가 데이터 요청을 각 샤드에 전달하고 결과를 취합한다.
샤딩의 장점[편집 | 원본 편집]
- 수평적 확장
- 데이터나 트래픽이 많아질 경우, 더 많은 샤드를 추가하여 데이터베이스의 크기나 처리 능력을 확장할 수 있다. 이는 서버 성능을 개선할 수 있는 경제적 방법이다.
- 성능 향상
- 여러 서버에 데이터가 분산되므로, 한 서버에서 처리할 데이터 양이 줄어들어 성능이 향상된다. 샤딩을 통해 읽기/쓰기 작업이 병렬로 처리되며, 큰 쿼리도 여러 샤드에 분산되어 더 빠르게 처리될 수 있다.
- 높은 가용성
- 샤딩과 복제를 함께 사용할 경우, 데이터 손실 위험이 줄어들고 가용성이 향상된다. 샤드 중 하나에 장애가 발생해도 다른 샤드들이 계속 작동할 수 있다.
샤드 키 선택 시 고려 사항[편집 | 원본 편집]
- 균형된 데이터 분배
- 샤드 키는 데이터가 고르게 분산될 수 있도록 설계해야 한다. 특정 샤드에 데이터가 몰리면 그 샤드가 과부하가 걸리며 성능이 저하된다.
- 쿼리 효율성
- 샤드 키는 자주 사용되는 쿼리에 영향을 줄 수 있다. 예를 들어, 특정 필드에 대해 자주 검색하는 경우, 그 필드를 샤드 키로 사용하면 검색 속도가 빨라질 수 있다. 그러나 적절하지 않은 샤드 키는 쿼리 성능을 저하시킬 수 있다.
기타[편집 | 원본 편집]
스키마 설계
MongoDB는 스키마가 고정되지 않은 스키마리스 데이터베이스지만, 데이터를 효율적으로 다루기 위해서는 스키마 설계가 중요하다. 데이터 구조를 너무 자유롭게 하면 나중에 관리가 어려워질 수 있다. 일반적으로, 자주 함께 조회되는 데이터는 한 문서에 포함시키고, 독립적으로 자주 변경되는 데이터는 별도로 분리하는 방식으로 설계해야 한다.
인덱싱
MongoDB는 다양한 인덱스 타입을 지원하는데, 성능을 최적화하려면 적절한 인덱싱이 필요하다. 예를 들어, 자주 검색되는 필드에 인덱스를 추가하면 조회 속도가 크게 향상된다. 하지만 너무 많은 인덱스를 사용하면 쓰기 성능이 저하될 수 있으니 균형을 맞추는 것이 중요하다.
복제 및 고가용성
MongoDB는 Replica Set을 사용하여 데이터 복제본을 유지하고, 장애 발생 시에도 고가용성을 제공한다. 하나의 노드가 장애를 일으키면 다른 노드가 자동으로 Primary 역할을 수행해 서비스 중단을 최소화할 수 있다.
트랜잭션
MongoDB는 NoSQL이지만 트랜잭션을 지원한다. 4.0 버전부터 다중 문서 트랜잭션을 사용할 수 있으며, 관계형 데이터베이스처럼 ACID 특성을 유지한 상태에서 복잡한 작업을 처리할 수 있다. 다만, 트랜잭션을 사용하면 성능에 영향을 줄 수 있으므로 필요한 경우에만 사용해야 한다.
MongoDB Atlas
MongoDB의 클라우드 서비스인 Atlas는 사용자가 직접 서버를 관리할 필요 없이 MongoDB를 클라우드 환경에서 쉽게 배포하고 관리할 수 있는 옵션을 제공한다. Atlas는 자동 백업, 보안 관리, 자동 확장 기능을 제공해 개발자의 부담을 줄여준다.
보안
MongoDB는 인증 및 권한 부여, 데이터 암호화 등 다양한 보안 기능을 지원한다. 데이터베이스에 접근할 수 있는 사용자와 권한을 세밀하게 설정할 수 있으며, 데이터 전송 중이나 저장 중에도 암호화를 통해 보안을 강화할 수 있다.
