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 장애시 Slave가 Master로 역할 전환

     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

▪ 꼭 필요할때만 제한적으로 사용하기를 권장 : 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가 빈번한 시스템 ▪ Update중 Document 크기가 증가하는 경우는 단편화(Fragmentation) 발생 가능 → 성능 저하 (MongoDB)