[DB]MongoDB란?

MongoDB?

• MongoDB는 일반적으로 사용되는 RDBMS(관계셩 데이터베이스, MySQL, OracleDB, PostgersSQL 등)가 아닌 NoSQL 데이터베이스 입니다.
  RDBMS에는 몇가지 한계성이 존재합니다. 첫번째로는 데이터 스키마가 고정적이라는 것 입니다. 스키마란 데이터베이스에 어떤 형식의 데이터를 넣을지에 대한 정보를 가리킵니다.
  예를 들어 회원 정보 스키마라면 사용자 ID, E-mail, username 등이 될 것이며, 새로 등록하는 데이터 형식이 기존에 있던 데이터들과 다르다면,
  기존 데이터를 모두 수정해야 새 데이터를 등록할 수 있게 됩니다. 그래서 데이터 양이 많을 때에는 데이터베이스의 스키마를 변경하는 작업이
  매우 번거로워 질 수 있습니다.
  두번째로는 확장성입니다. RDBMS는 저장하고 처리해야 할 데이터양이 늘어나면 여러 컴퓨터에 데이터를 분산 시키는 것이 아니라,
  해당 데이터베이스 서버의 성능을 업그레이드하는 방식으로 확장해주어야 했습니다.

• MongoDB 는 이러한 한계를 극복한 문서 지향적 NoSQL 데이터베이스 입니다. MongoDB에 등록하는 데이터블은 유동적은 스키마를 지닐 수 있습니다.
  또 한 종류가 같은 데이터라고 하더라도, 새로 등록해야 할 데이터의 형식이 바뀐다고 하더라도 기존 데이터까지 수정할 필요는 없습니다.
  서버의 데이터양이 늘어나도 한 컴퓨터에서만 처리하는 것이 아니라 여러 컴퓨터로 분산하여 처리 할 수 있도록 확장하기 쉽게 설계되어 있습니다.
  단 그렇다고 해서 무조건적으로 MongoDB 가 좋은 것은 아닙니다. 프로젝트에서 까다로운 조건으로 데이터를 필터링해야 하거나,
  ACID 특성을 지켜야 한다면 RSBMS가 더 유리할 수 있습니다.

• ACID 특성은 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability)의 앞 글자를 따서 만든 용어로,
  데이터베이스 트랜잭션이 안전하게 처리되는 것을 보장하기 위한 성질을 의미합니다.

MongoDB 문서?

• 위이 설명에서 말하는 문서는 RDBMS의 레코드와 개념이 비슷합니다, 문서의 데이터 구조는 한 개 이상의 키와 값 쌍으로 되어 있습니다.

    {
        "_id": ObjectId("5099803df3d4948db2f98391"),
        "username": "velopert",
        "name": { first: "K.T", last: "Kim"}
    }

• 문서는 BSON(바이너리 형태의 JSON) 형태로 저장되기 때문에 나중에 JSON 형태의 객체를 데이터베이스에 저장 할 때, 큰 공수를 들이지 않고도
  데이터를 데이터베이스에 등록 할 수가 있습니다.
• 만약 새로운 문서를 만들면 _id 라고 하는 고유값을 자동을 생성하는데, 이 값은 시간, 머신 아이디, 프로세스 아이디, 순차 번호로 되어있어 값의 고유성을 보장합니다. 여러 문서가 들어 있는 곳을 컬렉션이라고 하는데 기존의 RDBMS에서는 테이블 개념을 사용하므로 각 테이블 마다 같은 스키마를 가지고 있어야 합니다.
  새로 등록해야 할 데이터가 다른 스키마를 가지고 있다면, 기존 데이터들의 스키마도 모두 바꾸어 주어야 하는데 MongoDB는 다른 스키마를 가지고 있는 문서들이
  한 컬렉션에서 공존 할 수 있습니다.

    {
        "_id": ObjectId("594948a081ad6e0ea526f3f5"),
        "username": "veloper"
    },
    {
        "_id": ObjectId("59494fca81ad6e0ea526f3f6"),
        "username": "veloper",
        "phone": "010-1234-5678"
    }

• 위의 예시에서 첫번째 문서에는 phone 정보가 없는데, 두번째 문서에서는 phone 정보가 있습니다. 기존에 사용되는 RDBMS에서는 한 테이블의 모든 데이터가 같은 스키마를
  가져야 하기 때문에, 기존 데이터 전체를 일일이 수정해야하는데, MongoDB 에서는 컬렉션 안의 데이터가 같은 스키마를 가질 필요가 없으므로 위의 예시와 같이 사용이 가능합니다.

MongoDB 구조?

• MongoDB의 구조는 위의 이미지와 같이 서버 하나에 데이터베이스를 여러개 가지고 있을 수 있으며, 각 데이터베이스에는 여러 개의 컬렉션이 있으며,
  컬렉션 내부에는 문서들이 들어있습니다.

MongoDB 스키마 디자인?

• MongoDB에서 스키마 디자인을 하는 방식은 기존의 RDBMS에서 스키마를 디자인 하는 방식과 전혀 다릅니다.
  만약 RDBMS에서 블로그용 데이터 스키마를 디자인한다면, 각 포스트, 댓글마다 테이블을 만들어 필요에 따라 Join해서 사용하는 것이 일반적입니다.

• 하지만 NoSQL에서는 그냥 모든 것을 문서 하나에 넣으면 됩니다.

    {
        _id: ObjectId,
        title: String,
        body: String,
        user_id: String,
        reg_dt: Date,
        commments: [
            {
                _id: ObjectId,
                text: String,
                reg_dt: Date
            },
        ],
    },

• 만약 위와 같은 상황이라면 보동 MongoDB는 댓글을 포스트 문서 내부에 넣습니다. 문서 내부에 또 다른 문서가 위치할 수 있는데,
  이를 서브도큐먼트(subdocument) 라고 합니다. 서브도큐먼트 또한 일반 문서를 다루는 것 처럼 쿼리할 수 있습니다.
  문서 하나에는 최대 16MB 만큼 데이터를 넣을 수 있는데, 만약 100자 댓글 데이터라면 대략 0.24KB를 차지합니다.
  16MB는 16,384KKB이니 문서 하나에 댓글 데이터를 약 68,000개를 넣을 수 있는 크기입니다.
  만약 서브도큐먼트에서 이 용량을 초과할 가능성이 있다면 컬렉션을 분리시키는 것이 좋습니다.