.gif&blockId=11b00c82-b138-8050-a58b-dcbceda2ef8f)
NoSQL?
•
Not Only SQL : 기존의 RDBMS의 한계를 극복하기 위해 만들어진 새로운 형태의 데이터저장소
•
관계형 DB가 아니므로, RDMS처럼 고정된 스키마 및 JOIN이 존재하지 않는다.
Document?
•
Document Oriented 데이터베이스
== RDMS의 record
•
데이터 구조 : 한개이상의 field-value pair (JSON)
{
"_id": ObjectId("5099803df3f4948bd2f98391"),
"username": "velopert",
"name": { first: "M.J.", last: "Kim" }
}
JSON
복사
•
여기서 _id, username, name 은 field고 그 오른쪽에 있는 값들은 value
•
_id 는 12bytes의 hexadecimal 값으로서, 각 document의 유일함(uniqueness)을 제공.
•
이 값의 첫 4bytes 는현재 timestamp, 다음 3bytes는 machine id, 다음 2bytes는 MongoDB 서버의 프로세스id, 마지막 3bytes는 순차번호입니다 추가될때마다 값이 증가
•
Document는 동적(dynamic)의 schema 보유.
•
같은 Collection 안에 있는 Document 끼리 다른 schema 를 갖고 있을 수 있다. 서로 다른 데이터 (즉 다른 field) 들을 가지고 있을 수 있다.
Collection
•
MongoDB Document의 그룹
•
Document들이 Collection내부에 위치.
•
RDMS의 table과 비슷한 개념, RDMS와 달리 schema를 따로 가지고 있진않다.
Database?
•
Collection들의 물리적인 컨테이너
•
각 Database는 파일시스템에 여러파일들로 저장.
RDMS와의 비교
Relational Database Management System (관계형 데이터베이스 관리 시스템)은 행과 열로 된 2차원의 table로 데이터를 관리하는 데이터베이스 시스템
ex) Mysql, Oracle Database, DB2 등
RDBMS | MongoDB |
Database | Database |
Table | Collection |
Tuple / Row | Document |
Column | Key / Field |
Table Join | Embedded Documents |
Primary Key | Primary Key (_id) |
Database Server & Client | |
mysqld | mongod |
mysql | mongo |
Data Modelling
schema 디자인 할 때 고려사항
•
사용자 요구 (User Requirement) 에 따라 schema를 디자인한다.
•
객체들을 함께사용하게 된다면 한 Document에 합쳐서 사용한다. (예: 게시물-덧글 과의 관계)그렇지 않으면 따로 사용한다 (그리고 join 을 사용하지 않는걸 확실히 해둔다)
•
읽을때 join 하는게아니라 데이터를 작성 할 때 join 한다.
예제
간단한 블로그를 위한 데이터베이스를 디자인한다고 가정해보다. 요구사항을 나열하면?
•
게시글에는 작성자 이름, 제목, 내용이 담겨져 있다.
•
각 게시글은 0개 이상의 태그를 가지고 있을 수 있다.
•
게시글엔 덧글을 달 수 있다. 덧글은 작성자 이름, 내용, 작성시간을 담고 있다.
{
_id: POST_ID,
title: POST_TITLE,
content: POST_CONTENT,
username: POST_WRITER,
tags: [ TAG1, TAG2, TAG3 ],
time: POST_TIME
comments: [
{
username: COMMENT_WRITER,
mesage: COMMENT_MESSAGE,
time: COMMENT_TIME
},
{
username: COMMENT_WRITER,
mesage: COMMENT_MESSAGE,
time: COMMENT_TIME
}
]
}
JSON
복사
