'데이터베이스'에 해당되는 글 12건

mongodb는 nosql이다. no sql이 아닌 not only sql 이다.

sql 처럼 테이블 조인을 할 수는 없지만 이와 비슷한 기능을 제공해 준다.


바로 collection간의 population이라는 기능이다. 


There are no joins in MongoDB but sometimes we still want references to documents in other collections. This is where population comes in.

Population is the process of automatically replacing the specified paths in the document with document(s) from other collection(s). We may populate a single document, multiple documents, plain object, multiple plain objects, or all objects returned from a query. Let's look at some examples.


var mongoose = require('mongoose')
  , Schema = mongoose.Schema
  
var personSchema = Schema({
  _id     : Number,
  name    : String,
  age     : Number,
  stories : [{ type: Schema.Types.ObjectId, ref: 'Story' }]
});

var storySchema = Schema({
  _creator : { type: Number, ref: 'Person' },
  title    : String,
  fans     : [{ type: Number, ref: 'Person' }]
});

var Story  = mongoose.model('Story', storySchema);
var Person = mongoose.model('Person', personSchema);




위와 같이 두개의 collection을 정의하여 놓는다.

psersonSchema는 stroySchema를 embedding하고 있다. 

즉 일대다 관계이다. storySchema도 역시 personSchema를 참조하고 있다. 

이 경우에 population을 구현해보자.

우선 새로운 document를 만들고 이를 save하면서 stroy document도 save한다. 



var aaron = new Person({ _id: 0, name: 'Aaron', age: 100 });

aaron.save(function (err) {
  if (err) return handleError(err);
  
  var story1 = new Story({
    title: "Once upon a timex.",
    _creator: aaron._id    // assign the _id from the person
  });
  
  story1.save(function (err) {
   
 if (err) return handleError(err);
    // thats it!
  });
})




그리고 다음과 같이 stroy collection에서 population을 구현할 수 있다.

_creator를 populating 함으로써 person객체를 받아와 객체안의 이름을 populating 하고 있는 것이다.



Story
.findOne({ title: 'Once upon a timex.' })
.populate('_creator')
.exec(function (err, story) {
  if (err) return handleError(err);
  console.log('The creator is %s', story._creator.name);
  // prints "The creator is Aaron"
})



'데이터베이스 > mongodb' 카테고리의 다른 글

mongoose static method vs instance method  (0) 2015.02.11
node.js mongoose에서의 virtual model  (0) 2015.02.10
mongodb에서의 join  (1) 2015.02.10
mongodb modeling  (0) 2015.02.09
블로그 이미지

종환 Revolutionist-JongHwan

github.com/alciakng 항상 겸손하자.

댓글을 달아 주세요

modeling in mongodb don't same to modeling in sql.

몽고db에서의 모델링은 sql의 모델링과 다르다. 

몽고 db에서의 모델링은 2가지 방법이 있다. 

Multiple-Collection방법과 Embedde 방법.

공식홈에서는 이렇게 가이드를 하고 있다.

1) 1:1 관계인 경우.

{
   _id: "joe",
   name: "Joe Bookreader"
}

{
   patron_id: "joe",
   street: "123 Fake Street",
   city: "Faketon",
   state: "MA",
   zip: "12345"
}

위와 같이 1:1 관계에 잇는 document의 경우 

{
   _id: "joe",
   name: "Joe Bookreader",
   address: {
              street: "123 Fake Street",
              city: "Faketon",
              state: "MA",
              zip: "12345"
            }
}

위와 같이 embedding하는 모델링을 쓸 경우 더욱 효율적인 쿼리를 할 수 있게 된다.

2) one to many case

일대다 관계인 경우에는 embedding 방식과 multiple collection 방식으로 나뉘게 된다. 

일대일 경우인 경우에는 embedding 했을때 embedding된 데이터가 동적으로 계속해서 늘어나지 않기 때문에 document의 사이즈를 걱정할 필요가 없다. 

하지만 one to may case의 경우에는 embedding 된 데이터의 크기가 계속해서 증가하게 될 경우. document의 사이즈 제한을 넘기는 경우 골치가 아픈일이 생기게 된다. 

mongodb 공식홈에서도 documents in MongoDB must be smaller than the maximumBSON document size

라고 설명하고 있다. collection안의 document는 Bson maximm보다 작아야 한다.

그렇다면 embedding방식의 데이터와 multiple collection을 어떻게 구분하여 써야 할까?

So, separate collections are good if you need to select individual documents, need more control over querying, or have huge documents.

Embedded documents are good when you want the entire document, the document with a $slice of comments, or with no comments at all.

seperate collection(multiple collection)은 

 1. query의 다양성

 2. 위에서 말했듯이 document 의 사이즈가 무척 클때.. 

embedded document는

 1. 성능 issue가 있을 때..(속도가 빠르다)

 2. slice를 통해 range 쿼리를 할 때 유용(paging 처리를 구현할때 유용)

일반적인 룰(general rule)은 

As a general rule, if you have a lot of "comments" or if they are large, a separate collection might be best.

Smaller and/or fewer documents tend to be a natural fit for embedding.

만약 많은 예)코멘트(댓글) 이나 dccument 사이즈 크기가 클 경우에는 seperate collection이 유리하고 그렇지 않은 경우에는  embedding이 유리하다.

현재 내가 제작하고 있는 사이트는 

1. 회원정보

2. 회원들의 글 

3. 회원들의 댓글 

크게 세가지 collection이 필요할 것으로 예상된다.

그런데 댓글의 경우 아무리 많은 양이 달려도 16mb 를 넘지 않을 것으로 에상되어 

3을 2에 embedding 시키고 두개의 collection으로 구현하려고 한다.

Don't freak out, The Complete Works of William Shakespeare is around 5.5MB

(세익스피어의 완본의 크기가 5.5mb 이니까 16mb 만큼의 댓글을 달지는 않겠지..)

'데이터베이스 > mongodb' 카테고리의 다른 글

mongoose static method vs instance method  (0) 2015.02.11
node.js mongoose에서의 virtual model  (0) 2015.02.10
mongodb에서의 join  (1) 2015.02.10
mongodb modeling  (0) 2015.02.09
블로그 이미지

종환 Revolutionist-JongHwan

github.com/alciakng 항상 겸손하자.

댓글을 달아 주세요