320x100
320x100

NoSQL

: 수평 확장 가능한 분산 시스템

: Schema-less 

: 완화된 ACID

 

 

NoSQL vs RDBMS

NoSQL과 RDBMS의 차이

 

 

MongoDB의 특징

- Document

ㆍDatabase -> Collection -> Document -> Field 구조

MongoDB와 RDBMS의 구조 차이

 

ㆍMongoDB의 JSON 데이터 형태

MongoDB의 JSON형태

 

ㆍ자바스크립트 엔진인 SpiderMonkey를 사용하여 API에 접근하여 데이터를 조작

indert Qery

- BASE

: ACID와 대립되는 개념

ㆍBasically Available

: 언제든지 사용할 수 있는 가용성

ㆍSoft state

: 외부의 개입이 없어도 정보가 변할 수 있음

: 네트워크 파티션 등 문제로 인해 일관성이 유지되지 않는 경우 일관성 유지를 위해 데이터를 자동으로 수정

ㆍEventually consistent

: 일시적으로 일관성을 잃더라도 일정 시간 후 일관적인 상태가 되어야 함

: 장애 발생시 일관성을 유지하기 위해 이벤트 발생

 

=> 일관성을 어느정도 포기하고 가용성을 우선시

※ MongoDB 4.0 부터 Multi-Document Transaction을 제공하여 ACID 충족

※ MongoDB 4.2 부터 Shard Cluster Transaction을 제공하여 분산 트랜잭션까지 지원

 

- Open Source

: https://docs.mongodb.com/manual/tutorial/getting-started/

 

 

 

MongoDB의 탄생배경

: 대규모 데이터 처리에 대한 RDBMS의 한계성

: 일관성과 무결성 대신 읽기 성능과 수평 확장을 선택

 

ㆍCAP 이론

: 그 어떤 분산 시스템이라도 일관성, 가용성, 분할 내성을 모두 만족할수 없다는 이론

: Consistency (일관성, 모든 노드가 같은 시간에 같은 데이터를 볼 수 있음)

: Availability (가용성, 하나의 노드가 손상되어도 다른 노드를 통해 데이터 제공 가능)

: Partition tolerance (분할 내성, 노드 간 통신에 실패해도 시스템이 계속 동작)

 

ㆍPACELC 이론

: CAP이론에서 네트워크 장애로 인한 P상황(네트워크 파티션)은 꼭 발생한다는 것을 인정하여 정리한 이론

: Partition (Availability / Consistency) <네트워크 파티션이 발생한 상태>

: Else (Latency / Consistency) <정상상태>

=> MongoDB는 네트워크 파티션 상황시 가용성 중시 / 정상상태에는 일관성 중시

 

 

 

MongoDB Replica Set

: MongoDB의 가장 간단한 클러스터 구성방법

ㆍPSS

: 하나의 Primary와 두 개의 Secondary 클러스터

: Primary 장애 발생시 Secondary중 하나가 Primary 역할

ㆍPSA

: 하나의 Primary와 Arbitor, 여러개의 Secondary로 구성

: Primary 장애 발생시 Secondary와 Arbitor 중 새로운 Primary 선출

 

 

 

 

MongoDB  패턴

Mpodel Tree Structure

ㆍParent Reference

: 부모 Document를 바로 찾아야 하는 경우

[
  { _id: "MongoDB", parent: "Databases" },
  { _id: "dbm", parent: "Databases" },
  { _id: "Databases", parent: "Programming" },
  { _id: "Languages", parent: "Programming" },
  { _id: "Programming", parent: "Books" },
  { _id: "Books", parent: null }
]

ㆍChild References

: 자식 Document를 바로 찾아야 하는 경우

[
  { _id: "MongoDB", children: [] },
  { _id: "dbm", children: [] },
  { _id: "Databases", children: [ "MongoDB", "dbm" ] },
  { _id: "Languages", children: [] },
  { _id: "Programming", children: [ "Databases", "Languages" ] },
  { _id: "Books", children: [ "Programming" ] }
]

ㆍArray of Ancestors

: 조상 Document나 자식 Document를 모두 찾아야 하는 경우 / 여러 부모 Document를 가진 경우 부적합

[
  { _id: "MongoDB", ancestors: [ "Books", "Programming", "Databases" ], parent: "Databases" },
  { _id: "dbm", ancestors: [ "Books", "Programming", "Databases" ], parent: "Databases" },
  { _id: "Databases", ancestors: [ "Books", "Programming" ], parent: "Programming" },
  { _id: "Languages", ancestors: [ "Books", "Programming" ], parent: "Programming" },
  { _id: "Programming", ancestors: [ "Books" ], parent: "Books" },
  { _id: "Books", ancestors: [ ], parent: null }
]

ㆍMaterialized Paths

: Array of Ancestor와 유사하나 정규식 이용 / 하위트리를 찾는데 빠르나 공통 부모를 찾을때는 느림

[
  { _id: "Books", path: null },
  { _id: "Programming", path: ",Books," },
  { _id: "Databases", path: ",Books,Programming," },
  { _id: "Languages", path: ",Books,Programming," },
  { _id: "MongoDB", path: ",Books,Programming,Databases," },
  { _id: "dbm", path: ",Books,Programming,Databases," }
]

ㆍNestes sets

: 하위트리를 찾는데 가장 빠르고 효율적인 방법

: CRUD가 없는 정적인 구조에 적합

[
  { _id: "Books", parent: 0, left: 1, right: 12 },
  { _id: "Programming", parent: "Books", left: 2, right: 11 },
  { _id: "Languages", parent: "Programming", left: 3, right: 4 },
  { _id: "Databases", parent: "Programming", left: 5, right: 10 },
  { _id: "MongoDB", parent: "Databases", left: 6, right: 7 },
  { _id: "dbm", parent: "Databases", left: 8, right: 9 }
]

 

 

 

Referrence

: https://kciter.so/posts/about-mongodb

: 그외 패턴

 

MongoDB 이해하기

사내에서 MongoDB를 잘 쓰기위한 스터디를 하게되어 이번 기회에 관련 자료를 정리하기로 했다. MongoDB가 왜 필요한지, 더 잘사용하기 위해서 무엇이 필요한지를 중심으로 처음 MongoDB를 사용할 때

kciter.so

 

300x250
728x90