반응형

몽고DB란?

  • 크로스 플랫폼 Document 지향 DBMS
  • 빠른 속도와 확장성
    • NoSQL (비관계) DBMS
      • 기존 R(관계)DBMS의 규칙을 포기하는 대신, 뛰어난 확장성이나 성능을 발전시키는 방향
    • 대표적인 NoSQL DBMS

종류

관련 언어

Key-Value Store

Redis, Dynamo

Column 지향 언어

HBase, Cassandra

Document 지향 언어

MongoDB

Graph Database

Neo4J

  • 친숙함
    • JSON과 유사항 형태로 저장하는 방식
    • Javascript를 활용할 수 있음
    • Document 지향 스토어 (Schemaless)
    • 다양한 인덱스를 지원

 

  • 쉽고 빠른 분산 컴퓨팅 환경 구성 (신뢰성-Reliability / 확장성-Scalability)
    • Replication(HA) , Sharding(분산 저장) 제공하여 쉽게 구성이 가능

신뢰성(Reliability)

  • 서버 장애에도 서비스는 계속 동작
    • Primary 와 Secondry로 구성된 ReplicaSet 구조로 고가용성을 지원

확장성(Scalability)

  • 데이터와 트래픽 증가에 따라 수평확장(scale-out) 가능
    • 데이터를 샤딩하여 수평확장(scale-out) 할 수 있음

유연성(Flexibility)

  • 여러가지 형태의 데이터를 손쉽게 저장
    • 서비스 요구사항에 맞춰 다양한 종류의 데이터가 추가되어도 스키마 변경 과정 없이 필요한 데이터를 바로 저장하고 읽을 수 있음

Index 지원
(Index Support)

  • 다양한 조건으로 빠른 데이터 검색
    • 다양한 인덱스 지원 다양한 용도로 사용이 가능

MongoDB 구조

  • MongoDB에 여러 개의 Database 가 존재
    • create 문이 존재 하지 않으며, 원하는 DB명을 생성이 아닌 선택 후 document를 insert하면 생성 됨
  • 하나의 Database 내에 여러 개의 Collection 이 존재
    • DB와 동일하게 별도의 create 문이 존재 하지 않으며, document를 생성하면 자동으로 collection이 생성
  • 하나의 Collection에는 여러 Document가 존재
    • 실질적인 데이터
  • BSON
    • Binary JSON 구조
    • 필드 뒤에 값이 오는 형태
    • 필드와 필드는 쉼표로 구분
    • Document 하나는 중괄호로 감싸져 존재
    • 필드에는 문자열만 들어가며, 값에는 배열, 숫자, 3차원 위치 좌표, 또 다른 필드와 값을 가진 오프젝트도 값으로 가질 수 있음 (유연성-Flexibility)
    • 그 외 다른 정보를 모두 표현할 수 있도록 다양한 값의 형식을 지원
      • 그 중 중요한 ObjectID 만 정리
      • ObjectID
        • Document 생성 시 PK로 "_id" 필드가 자동으로 생성
        • _id 는 서로 겹치지 않는 ObjectID 타입으로 값을 할당
        • 동시에 생성되어도 서로 다른 값이 생성되어 유일 값
        • ObjectID 값은 "유닉스시간+기기id+프로세스id+카운터" 로 구성
          • 앞에 4byte는 유닉스 시간
          • 다음 3byte는 기기의 id 값
          • 다음 2byte는 프로세스 id 값
          • 마지막 3byte는 랜덤 값부터 시작하는 카운터로 구성
        • ObjectId.getTimestamp() 하면 생성된 시점을 알아낼 수 있음. (ObjectID를 이용하면 시간 range 로 검색이 가능)
> ObjectId("507c7f79bcf86cd7994f6c0e").getTimestamp()
ISODate("2012-10-15T21:26:17Z")

use database1            // database 선택
db.collection1.insert({              // collection.명령어 document
    "name" : "Rouis.Kim"   // field : value
    , "age" : 37           // field : integer value
    , "role" : "DBA"       // field : string value
    , "exp" : [{"Dev" : 5, "DBA" : 6}, {"Game": 3, "Ecommercail":2, "Enginner":3,"etc":3}]  // field : Object value
    , "loc" : [37.504997827623406, 127.02381255144938] // field : geomentry
    , "etc" : ["2 daughters","프로이직러"] // field : array value
})
// document가 생성되지만, collection 이 존재하지 않으면 collection, database가 존재 하지않으면 database 까지 생성 됨
// schemaless (스키마 유연성)

언제 어떻게 써야 할까?

  • Schema가 자주 바뀌는 환경
    • Document 지향 스토어 방식
      • 스키마의 변경이 자유로운 편
      • 추가될 기능이 확실하지 않고 상황에 다라 App에 저장될 자료가 지속적으로 달라지는 환경(개발 방법론으로 개발 하는 곳)
      • 애자일 개발 방법론 / 나선형 모델에 최적 (미주 추가)
  • 분산 컴퓨팅 환경
    • 샤딩과 복제를 지원하기 때문에 여러 대의 컴퓨터에 구성이 용이하기 때문에 빠른 분산 컴퓨팅 환경이 구축 필요한 경우

 

RDBMS

NoSQL

Schema

  • 명확한 데이터 구조 (Join 등으로 복잡성 증가, 스키마 수정 시  비용 발생)
  • 데이터 무결성 보장
  • 수평적 확장이 힘듦(수직적 확장)

Schemaless

  • 자유롭게 데이터를 관리(중복 데이터 저장 가능하여 데이터 관리 필요)
  • Data에 대한 규격화된 결과 얻기가 힘듦
  • Join이라는 개념이 없으며, Join 가능은 하나 힘ㄷ름
  • 수평적 확장이 쉬움

ACID / BASE 관련 좋은 글

https://embian.wordpress.com/2013/06/27/nosql-2/

https://velog.io/@qoik11/MongoDB-3rk4z5de3r

 

버전 관리

  • MongoDB는 두 번째 자리 숫자가 짝수인 버전이 안정화 버전이며, 홀수인 버전이 개발 중인 버전
  • 서비스를 하는 것이라면 두 번째 자리가 짝수인 버전을 사용하는 것 추천
  • Postgresql 도 비슷한 것으로...

 


애자일 개발 방법론

  • 신속한 반복 작업을 통해 실제 작동 가능한 소프트웨어를 개발하여 지속적으로 제공하기 위한 소프트웨어 개발 방식
  • 지속적으로 요구 사항을 반영하며, 의사소통이 많으며 지속적인 테스트 가 특징
  • 명세화 부족하며 잦은 변경으로 테스트 증가. 개발자 위주라 사업 관리 부분 미흡(유지보수 비용 증가)

나선형 모델

  • 시스템 개발 시 위험을 최소화 하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 나선형 모델로 ,계속 목표설정-위험분석-개발검증-고객평가를 계속하며 점진적으로 개발
  • 리스크를 최소화 하기 위하여 "위험 분석 단계"를 추가하여 위험 부담이 큰 대형 시스템 구축에 적합.
  • 프로젝트 기간이 길며, 관리가 어려움. 위험 관리에서는 해당 전문가가 필요
반응형

+ Recent posts