2. > post = {"title" : "My Blog Post",
... "content" : "here's my blog post.",
데모 : 설치 ... "date" : new Date() }
{
"title" : "My Blog Post",
"content" : "here's my blog post.",
$ bin/mongod --dbpath ~/db "date" : ISODate("2012-01-27T17:17:44.026Z")
=> http://localhost:28017/ 접속 }
> db.blog.insert(post)
$ bin/mongo > db.blog.find()
> x = 200 {
200 "_id" : ObjectId("4f22dc6dc7aca8fc32e67afb"), "title" : "My
>x/5 Blog Post", "content" : "here's my blog post.", "date" :
40 ISODate("2012-01-27T17:17:44.026Z") }
> db >
test > db.blog.findOne()
> use foobar {
switched to db foobar "_id" : ObjectId("4f22dc6dc7aca8fc32e67afb"),
> db "title" : "My Blog Post",
foobar "content" : "here's my blog post.",
"date" : ISODate("2012-01-27T17:17:44.026Z")
}
}
3. 데모 : 설치
> post.comments = [ ]
[]
> db.blog.update({title : "My Blog Post"}, post)
> db.blog.findOne()
{
"_id" : ObjectId("4f22dc6dc7aca8fc32e67afb"),
"title" : "My Blog Post",
"content" : "here's my blog post.",
"date" : ISODate("2012-01-27T17:17:44.026Z"),
"comments" : [ ]
}
>
> db.blog.remove({title : "My Blog Post"})
> db.blog.find()
>
4. Tip 1. 속도가 중요하면 복제를 , 데이터
무결성이 중요하면 참조를 사용하라
여러 문서가 공동으로 사용하는 데이터는
● 내장(embedded)되거나 => 비정규화
● 참조될 수 있다 => 정규화
결정 요인
● 읽기 수행시 비용 발생 여부
● 데이터 변경이 드문가
● 일관성이 얼마나 중요한 요소인가
● 읽기는 빨라야 하는가
5. Tip 1. 속도가 중요하면 복제를 , 데이터
무결성이 중요하면 참조를 사용하라
● 비정규화
○ 데이터 일관성(consistency) 해칠 수 있다.
○ 데이터 불일치가 상대적으로 덜 중요하거나
나중에 보정해도 괜찮을 때 사용
○ 한번의 쿼리로 수행. 성능 저하 요인이 없음
● 정규화
○ 아주 짧은 기간의 불일치도 허용할 수 없을 때
○ 추가적인 쿼리를 수행하기 때문에 성능 저하
○ 원자성 유지한 채 수정 가능
8. Tip 2. 데이터가 미래에도 유용한 상태
이기를 원하면 정규화하라
● 데이터는 지속적으로 발달한다.
● 오래된 데이터는 갱신되거나 잊혀진다.
● 새로운 쿼리에 맞는 데이터베이스 최적화
나중에 다른 애플리케이션에서 다른 방식으로
데이터에 대한 쿼리를 수행하도록 하려면 데이
터를 정규화해야 한다.
9. Tip 3. 단일 쿼리로 데이터를 가져오라
MongoDB 스키마는 하나의 쿼리가 하나의 애플
리케이션 단위를 수행하도록 설계해야 한다
● 사례 1 : 블로그
○ posts 컬렉션에 저장된 최근 10개의 포스트
○ 해당 태그가 달린 최근 20개 포스트
> db.posts.find( {}, {"title" : 1, "author" : 1, "slug" : 1, "_id" : 0} ).sort(
... {"date" : -1}).limit(10)
> db.posts.find( {"tag" : someTag}, {"title" : 1, "author" : 1,
... "slug" : 1, "_id" : 0} ).sort( {"data" : -1} ).limit(20)
> db.authors.findOne( {"name" : authorName} )
10. Tip 3. 단일 쿼리로 데이터를 가져오라
● 사례 2 : 사진 게시판
○ 애플리케이션 단위 : 스레드 하나의 메시지 중 스무
개를 표시하는 것
> db.posts.find( {"threadId" : id} ).sort( {"date" : 1} ).limit(20)
> db.posts.find( {"threadId" : id, "date" : {"$gt" : latestDateSeen}} ).
... sort( {"date" : 1} ).limit(20)
● 하지만 현실은 만만치 않다!
Q : latestDateSeen
11. Tip 4. 의존적인 필드는 내장하라
● 어떤 문서를 내장할지 참조할지 고려할 때는
그 필드에 저장된 정보 자체가 필요한지 아
니면 그 필드가 속한 문서의 구조가 필요한
지를 자문해보자. (ex. 태그, 댓글)
● 어떤 데이터를 사용하는 문서가 단 하나뿐이
라면 그 정보는 그 문서에 내장한다.
Q : 조인 테이블?
12. Tip 5. 특정 시점의 데이터는 내장하라
어떤 데이터의 특정 시점의 스냅샷을 원하는 경
우에는 데이터 내장 방식을 사용한다.
ex> orders 문서의 주소를 나타내는 필드
고객이 주소를 수정했다고 해서 이전 주문내역
의 배송지 주소까지 바뀌는 것을 원하지 않는
다.
13. Tip 6. 계속해서 커지는 필드는 내장하
지 말라
MongoDB가 데이터를 저장하는 방식 때문에...
● 많은 양의 서브문서를 내장하는 것은 상관없
으나
● 배열의 끝에 계속해서 데이터를 추가하는 것
은 상당히 비효율적이다.
=> 댓글같이 애플리케이션마다 다양한 양상을
보이는 극단적 케이스에서는 별개의 문서에 저
장하는 것을 고려하자