본문 바로가기

빅데이터/nosql

NoSQL강의) Document Database 개요 및 설명

Document Database란

Document를 저장하는 데이터베이스

▪  XML, JSON, BSON - 계층적 트리 데이터

▪  _id : PK, RowID
  - 사용자가 설정 가능

▪  Embedded Document
  - 여러개의 테이블을 하나의 Document 내에 모아둘 수 있음 - 조회시 한번의 조회로 필요한 데이터 획득. Join 기능을 대체

대표 사례

Mongodb
CoucbDB, CouchBase

Hadoop, Spark와의 통합 지원

mongoDB기반 데이터를를 hive에서 집계, spark로 집계와 같은 기능.

Document Database의 특징

Array와 Embedded Document을 잘활용하는 것이 핵심

  - 컬럼 없음 → Schema 없음
  - Document 내에 Field를 정의함 ( Key : Value )
  - Key에 대한 값은 Document가 될 수 있음 ( Embedded Document )
  - Key에 대한 값은 배열이 될 수 있으며, 배열의 값으로 Document를 포함할 수 있음

  - 집합적 데이터 모델 : 관계형 DB에서의 여러개 테이블 데이터를 하나의 Document에 모아둘 수 있음

{
  "_id" : "mspark11",
  "name" : "박명수",
  "phones" : [ "010-2452-8864", "02-2214-3521" ],
  "title" : "수석 컨설턴트",
  "team" : { "name" : "기술컨설팅팀", "code" : "Z03212" }, "schedules" : [
    { "time" : "20150311130000", "loc" : "과천", "work" : "업무협의" },
    { "time" : "20150402150000", "loc" : "강남역", "work" : "제휴상담" },
    { "time" : "20150211100000", "loc" : "종로", "work" : "전략회의", "done": true },
    { "time" : "20150211170000", "loc" : "삼성동", "work" : "세미나 참석", "done" :true }
  ] 
}

가용성

▪  복제 (Replication)
  - Master/Slave : 수동으로 복구해야 함.
  - Replica Set : 자동 장애 극복 지원. Master 장애시 SlaveMaster로 역할 전환

     ex) mongoDB에서는 primary, secondary라고 부름.

     ex) 운영시 최소 size가 p1+s2 이렇게 홀수로 구성.

  - 쓰기는 Master, 읽기는 Master, slave 모두 가능

조회

▪  다른 모델에 비해 비교적 관계형 데이터베이스 쿼리와 유사한 측면이 있음

▪  인덱스 지원, 힌트 지원, 쿼리 실행 계획 확인 기능 지원

▪  뷰 지원(Couchbase)

▪  자체 집계 기능 지원

일관성

Replica Set을 기본 고려한 데이터베이스
  - WriteConcern : 애플리케이션에서 일관성 수준을 결정할 수 있음.

   ex) writeConcern 1 : 1개의 node에 저장되면 저장완료

   ex) writeConcern 2 : 2개의 node에 저장되면 저장완료

WriteConcern의 값은 application단위에서 지정할 수 있다. 

  - 쓰기 일관성과 성능은 Trade Off 관계

읽기 일관성
  - 'Secondary 읽기 우선' 설정은 성능 ▲, 읽기 일관성 ▼

트랜잭션

대부분 원자적 트랜잭션만을 지원

mongodb의 트랜젝션 : https://medium.com/@marchpig/mongodb-multi-document-transactions-d51e047f811d

 

[MongoDB] Multi-Document Transactions - Sangwoo Lee - Medium

MongoDB의 Multi-Document Transaction을 예제와 함께 알아본다.

medium.com

 꼭 필요할때만 제한적으로 사용하기를 권장 : performance가 1/10 이하로 떨어짐.

엄격한 트랜잭션 처리가 필요하다면...

  - 애플리케이션 측에서 처리를 하거나
  - 관계형 데이터베이스를 사용하는 것을 고려한다
.

확장성

▪ replication set에서의 Slave 읽기 설정 : 읽기 부하 분산

▪ 샤딩
  - RDB의 파티셔닝과 유사함. 수평적 파티셔닝(범위 기반, 해시기반)

  - 선택적 샤딩 : 1 node사용하다가 multi node 사용 가능.
  - 자동 샤딩 : 노드간 데이터가 균등하게 분배될 수 있도록 자동 조정됨.

Document Database 사용?

적합한 경우 부적합한 경우

로깅 시스템
로그의 중앙집중화된 저장소로 사용하기에 적합함.
  - ex) MongoDB : 각 서버의 Text Log → FluentD → MongoDB 로 저장

 

인터넷 상거래 시스템

비즈니스 요구사항의 변경에 능동적으로 대처
  - 잦은 스키마의 변경이 있어도 데이터베이스 변경에 따른 비용은 적음   

  - 잦은 변경에도 유연하게 대처할 수 있음  Schemaless

 

SNS 서비스

블로그나 SNS 서비스 데이터에 적합

CMS(Content Management System)

  - Schema가 없기 때문에 다양한 컨텐츠를 취합하여 저장 관리 가능함.

 

Agile 개발

엄격한 다중 트랜잭션이 요구되는 애플리케이션
Document 데이터베이스는 대부분 원자적 트랜잭션!!

 

엄격한 일관성, 무결성이 요구되는 경우

Join을 지원하지 않음
비정규화를 통해 데이터 중복을 허용함.

 

Update가 빈번한 시스템

UpdateDocument 크기가 증가하는 경우는 단편화(Fragmentation) 발생 가능  성능 저하 (MongoDB)