몽고디비란? mongoDB

몽고 DB의 기본 개념

MongoDB는 고성능, 고가용성 및 쉬운 확장성을 제공하는 NoSQL, Document 지향 데이터베이스입니다.

데이터를 배열 및 중첩 Document와 같은 복잡한 데이터 유형을 효율적으로 저장할 수 있는 유연한 JSON과 유사한 형식인 BSON(Binary JSON)으로 저장합니다.

 

JSON <=> BSON 직렬화, 역직렬화 과정에서 CPU 리소스가 많이 사용될 수 있으나,

이를 내부 최적화 알고리즘으로 개선했고,
텍스트 보다 적은 용량을 사용해 저장공간의 용이성도 가져온다.
일반적으로 데이터베이스 I/O 연산이 더 큰 병목 현상을 일으키 때문에 

효율적인 방법 같다.

 

---

몽고 DB의 유연과 확장

몽고 DB의 장점을 두 개의 키워드로 뽑으면 유연과 확장이라고 말할 수 있을 것 같다.

아래와 같은 특징이 유연과 확장에 용이한 db라고 생각하는 이유이며, 빠르게 변화하는 비즈니스 요구에 유연하게 대응하기에 적합하지 않나 싶다.

 

1. 스키마 없음 (Schema-less):
   MongoDB는 스키마 없는 데이터베이스로, 데이터의 구조를 미리 정의하지 않아도 됩니다. 이로 인해 애플리케이션의 요구 사항이 변경되거나 다양한 데이터 형식을 저장할 수 있어 유연성이 높습니다.
   
   
2. 동적 스키마 (Dynamic Schema):
   MongoDB는 동적 스키마를 지원합니다. 이는 컬렉션 내에서 각 문서가 독립적으로 다른 필드를 가질 수 있음을 의미합니다. 필요에 따라 필드를 추가하거나 제거할 수 있어, 데이터 모델의 변화에 쉽게 대응할 수 있습니다.
   
   
3. 수평적 확장 (Horizontal Scalability):
   MongoDB는 쉽게 클러스터를 형성하여 데이터베이스를 확장할 수 있습니다. 이는 샤딩(sharding) 기능을 통해 데이터를 여러 노드에 분산시키고, 높은 트래픽과 대규모 데이터를 처리할 수 있게 해줍니다해 줍니다.
   
   
4. 인덱싱 (Indexing):
   MongoDB는 다양한 인덱싱 옵션을 제공하여 쿼리 성능을 최적화합니다. 필드에 인덱스를 추가하면 데이터 검색과 정렬이 빨라져서 애플리케이션의 응답 시간을 개선할 수 있습니다.
   
5. 다양한 데이터 모델 지원:
   MongoDB는 Document 지향 데이터베이스로서, 배열, 중첩된 문서, 기본 타입 등 다양한 데이터 유형을 지원합니다. 이로 인해 복잡한 데이터 구조를 표현하고 쿼리할 수 있습니다.

 

---

 

몽고 DB  어떤 경우에 적합한가?

 

MongoDB를 사용해야 할 때:

1. 유연성이 필요한 경우: 스키마가 자주 변경되거나 복잡한 데이터 구조를 가진 애플리케이션에 적합합니다.
   
   
2. 빠른 개발과 프로토타이핑: 데이터 모델을 빠르게 반영하고 수정할 수 있어, 초기 개발 단계에서 빠른 프로토타이핑이 필요한 경우에 적합합니다.
   
   
3. 대규모 데이터와 높은 트래픽: 수평적 확장이 용이하므로, 대규모 데이터 집합과 높은 트래픽을 처리해야 하는 애플리케이션에 적합합니다.
   
   
4. 다양한 데이터 모델: 배열, 중첩된 문서, 기본 타입 등 다양한 데이터 유형을 지원하므로, 복잡한 데이터 구조를 관리해야 하는 경우에 적합합니다.
   
   
5. 실시간 분석과 집계: MongoDB는 실시간 집계와 분석을 위한 쿼리 기능을 제공하여 빠른 데이터 분석이 필요한 경우에 적합합니다.
   
   

MongoDB를 사용하면 안 될 때:

1. ACID 트랜잭션 필요: MongoDB는 ACID 트랜잭션을 제한적으로 지원합니다. 복잡한 트랜잭션 처리가 필요한 애플리케이션의 경우 관계형 데이터베이스가 더 적합할 수 있습니다.
   
   mongoDB는 ACID 가 아닌 BASE 기반 트랜잭션을 사용합니다.
   
   구조화된 특성을 감안할 때
   - ACID 호환 DB는 일관성, 예측 가능성 및 안정성이 필요한 프로젝트에 적합한 것 같고,
   - BASE는 더 쉽게 확장할 수 있고 더 많은 유연성을 제공해주나, BASE 모델의 한계를 알고 다루는 숙련된 개발자가 필요해 보인다.
   
   

속성	BASE	ACID
적용분야	NOSQL	RDBMS
일관성측면	약한 일관성	강한 일관성
중점사항	Availability	‘Commit’에 집중
시스템측면	성능에 초점	엄격한 데이터관리
효율성	쿼리디자인이 중요	테이블 디자인이 중요

 

1. 정교한 쿼리 최적화: MongoDB는 강력한 쿼리 기능을 제공하지만, 관계형 데이터베이스의 SQL 쿼리 최적화 능력에는 미치지 못할 수 있습니다.
   
   
2. 정교한 인덱싱: MongoDB는 다양한 인덱싱 옵션을 제공하지만, 관계형 데이터베이스의 정교한 인덱싱 기능에 비해 제한적일 수 있습니다.
   
   
3. 고정된 스키마: 애플리케이션의 데이터 모델이 고정된 스키마를 필요로 하는 경우, 관계형 데이터베이스가 더 적합할 수 있습니다.
   
   
4. 엄격한 보안 요구: MongoDB는 강력한 보안 기능을 제공하지만, 일부 고급 보안 요구사항을 충족시키기 위해서는 추가적인 설정과 관리가 필요할 수 있습니다.

 

 

---

 

몽고 DB의 Index

- index는 한 쿼리에 한 index만 유효합니다. 따라서 두 개의 index 가 필요하다면 복합 index를 사용합니다.
- index는 read 작업 위주의 애플리케션에서 유용하고 읽기보다 쓰기 작업이 많으면 index를 추가하는 것은 고려해야 합니다.

 

 

Single Field Index(단일 필드 인덱스)

하나의 필드 인덱스를 사용하는 것을 단일 필드 인덱스라고 합니다. MongoDB에는 기본적으로 컬렉션에 _id라는 단일 필드 인덱스가 생성됩니다.

단일 필드 추가 방법은 아래와 같습니다. 원하는 field를 입력합니다. 
단일 필드 인덱스에서는 1은 오름차순 -1은 내림차순을 의미합니다.
하지만 단일 필드 인덱스에서는 오름차순인지 내림차순인지 중요하지 않습니다. 
왜냐하면 어떤 방향으로 가도 동일하게 접근하기 때문입니다.

 

> db.user.createIndex({score:1})

 

 

Compound Index(복합 인덱스)

두 개 이상의 필드를 사용하는 인덱스를 복합 인덱스라고 부릅니다.

아래와 같이 인덱스를 생성한다면, 아래 그림과 같이 userid는 오름차순으로 정렬됩니다.
그리고 같은 userid를 지니면 score로 내림차순 정렬하게 됩니다.
예를 들면 동일한 userid 인"ca2"는 score가 내림차순으로 정렬되어 있음을 그림에서 확인할 수 있습니다.

 

> db.user.createIndex({userid:1 ,score:-1})

 

ttps://docs.mongodb.com/manual/core/index-compound/

 

- 특징 1. sort 연산 시 인덱스 순서를 고려하여 생성하자.

 복합 인덱스에서는 키의 순서가 매우 중요합니다. 만일 복합 인덱스에서 순서가 userid-score가 아니라 score-userid로 생성하는 것은 다른 인덱스를 생성한 것입니다.

정렬 시 인덱스 순서와 조회 시 순서가 동일해야 합니다.

예를 들어 아래와 같이 인덱스 a-b순서로 생성하면 a-b 정렬은 지원을 하지만, b-a로 정렬은 지원하지 않습니다.

 

- 특징 2. 단일 인덱스와 다르게 복합 인덱스는 정렬 방향을 고려하자.

 검색 쿼리에서 복합 인덱스를 사용하는 경우 지정된 정렬 방향은 index와 일치해야 합니다.
예를 들어 아래와 같이 두 필드 정렬이 역으로 생성된 경우라면 역으로 조회하는 쿼리는 지원하지만, 동일한 정렬을 하는 쿼리는 지원하지 않습니다.

 

---

사용 TIPS

mongoDB 핸즈온 워크샵에서 들은 내용들..

 

Insert Replication

• 기본 3개의 노드로 구성된 클러스터 환경으로 데이터 복제를 위한 옵션 제공
• 비동기 형태의 보장하기 위해 write concern 제공
• Default한 설정 권장

 

Array Search 시

• Array 검색 시 elemMatch 사용

 

 

Index

 

• Single Field { year: 1 }

       ASC : 1, DESC: -1

 

• Compound Field { year: 1, rated: -1 }
  
  
• Multikey { languages: 1 }
  Array index
  include element search
• Geospatial
  x B-tree
  
  
• Text
  한국에서 사용하기 어렵 -> altas search 대체
  
  
• Hashed { did: hashed }
  샤딩을 제외면 독립적으로 쓰기 어려움

 

 

 

Query plan

• winningPlan 위주로
• COLLSCAN 무조건 지양 -> 무조건 index를 통한 SCAN

 

 

인덱스 생성 시 고려사항(ESR) - 아래 순서대로 인덱스 구성

• Equality (최대한 앞으로)
• Sorting
• Range

 

필드 지정 순서에 대한 고려

쿼리 패턴을 고려

읽어들인 인덱스키와 document가 같을 수록 성능이 좋다.