몽구스 하위 문서와 중첩 스키마

몽구스 하위 문서와 중첩 스키마

---

기본 스키마에서 하위 문서와 더 깊은 계층을 사용하는 장단점에 대해 궁금합니다.

var subDoc = new Schema({
  name: String
});

var mainDoc = new Schema({
  names: [subDoc]
});

또는

var mainDoc = new Schema({
  names: [{
    name: String
 }]
});

현재 모든 곳에서 하위 문서를 사용하고 있지만 주로 발생할 수있는 성능 또는 쿼리 문제에 대해 궁금합니다.

---

docs 에 따르면 정확히 동일합니다. 그러나 스키마를 사용하면 _id필드를 추가 할 수 있으며 (해제하지 않은 경우) 하위 문서 추적에 더 많은 리소스를 사용할 수 있습니다.

대체 선언 구문

v3의 새로운 기능 하위 문서 스키마 인스턴스에 액세스 할 필요가없는 경우 단순히 객체 리터럴을 전달하여 하위 문서를 선언 할 수도 있습니다. [...]

---

모델의 다양한 부분에서 재사용되는 스키마가있는 경우 하위 문서에 대해 개별 스키마를 정의하면 자신을 복제 할 필요가 없습니다.

---

정적 문서이거나 성능 영향으로 인해 수백을 넘지 않는 내장 문서를 사용해야합니다. 나는 그 문제에 대해 잠시 전에 겪었습니다. 새로운 MongoDB 솔루션 아키텍트 인 Asya Kamsky는 "하위 문서 사용"에 대한 기사를 작성했습니다.

솔루션이나 모범 사례를 찾는 사람에게 도움이되기를 바랍니다.

http://askasya.com/post/largeembeddedarrays의 원본 게시물 . https://stackoverflow.com/users/431012/asya-kamsky에서 stackoverflow 프로필에 연결할 수 있습니다.

우선, 왜 그런 일을하고 싶은지 고려해야합니다. 일반적으로, 나는 사람들이이 문서를 가져올 때 항상 되찾고 싶은 것을 포함하도록 권합니다. 이것의 반대 측면은 문서에 다시 넣고 싶지 않은 것들을 문서에 포함하고 싶지 않다는 것입니다.

내가 수행 한 활동을 문서에 포함 시키면 모든 활동이 바로 거기에 있고 한 번의 읽기만으로 나에게 보여주고 싶은 모든 것을 다시 얻을 수 있기 때문에 처음에는 훌륭하게 작동 할 것이다. 당신의 마지막 두 의견입니다 "하지만 6 개월이 지난 후에 무슨 일이 일어나고 나는 오래 전에 한 일에 신경 쓰지 않으며 특별히 오래된 활동을 찾지 않으면 나에게 보여주고 싶지 않습니까?

먼저, 더 크고 더 큰 문서를 반환하고 더 작고 작은 부분을 돌보게됩니다. 그러나 투영을 사용하여 배열의 일부만 반환 할 수 있습니다. 실제로 고통은 디스크의 문서가 커지고 최종 사용자에게만 반환하더라도 여전히 모든 문서를 읽을 수 있다는 것입니다. 활동중인 한 내 활동이 중지되지 않기 때문에 문서가 계속 커지고 커집니다.

이것에 대한 가장 명백한 문제는 결국 16MB 문서 한도에 도달한다는 것입니다. 그러나 그것은 당신이 걱정해야 할 것이 아닙니다. 지속적으로 증가하는 문서는 디스크에서 재배치해야 할 때마다 점점 더 많은 비용이 발생하며 조각화의 영향을 완화하기위한 조치를 취하더라도 쓰기 시간이 불필요하게 길어 전체 애플리케이션의 전체 성능에 영향을 미칩니다.

응용 프로그램의 성능을 완전히 떨어 뜨리고 점점 증가하는이 배열을 인덱싱하는 것이 한 가지 더 있습니다. 즉,이 배열이있는 문서를 재배치 할 때마다 업데이트해야하는 인덱스 항목 수는 해당 문서의 인덱스 값 수에 비례하고 배열이 클수록 해당 숫자가 커집니다. 있다.

데이터 모델에 적합 할 때 배열을 사용하는 것을 두려워하지 않기를 원합니다. 문서 데이터베이스 데이터 모델의 강력한 기능이지만 모든 강력한 도구와 마찬가지로 올바른 환경에서 사용해야합니다. 주의해서 사용해야합니다.

---

기본적으로 변수 nestedDov를 만들어 여기에 넣으십시오.name: [nestedDov]

간단한 버전 :

var nestedDoc = new Schema({
  name: String
});

var mainDoc = new Schema({
  names: [nestedDoc]
});

JSON 예

{
    "_id" : ObjectId("57c88bf5818e70007dc72e85"),
    "name" : "Corinthia Hotel Budapest",
    "stars" : 5,
    "description" : "The 5-star Corinthia Hotel Budapest on the Grand Boulevard offers free access to its Royal Spa",
    "photos" : [
        "/photos/hotel/corinthiahotelbudapest/1.jpg",
        "/photos/hotel/corinthiahotelbudapest/2.jpg"
    ],
    "currency" : "HUF",
    "rooms" : [
        {
            "type" : "Superior Double or Twin Room",
            "number" : 20,
            "description" : "These are some great rooms",
            "photos" : [
                "/photos/room/corinthiahotelbudapest/2.jpg",
                "/photos/room/corinthiahotelbudapest/5.jpg"
            ],
            "price" : 73000
        },
        {
            "type" : "Deluxe Double Room",
            "number" : 50,
            "description" : "These are amazing rooms",
            "photos" : [
                "/photos/room/corinthiahotelbudapest/4.jpg",
                "/photos/room/corinthiahotelbudapest/6.jpg"
            ],
            "price" : 92000
        },
        {
            "type" : "Executive Double Room",
            "number" : 25,
            "description" : "These are amazing rooms",
            "photos" : [
                "/photos/room/corinthiahotelbudapest/4.jpg",
                "/photos/room/corinthiahotelbudapest/6.jpg"
            ],
            "price" : 112000
        }
    ],
    "reviews" : [
        {
            "name" : "Tamas",
            "id" : "/user/tamas.json",
            "review" : "Great hotel",
            "rating" : 4
        }
    ],
    "services" : [
        "Room service",
        "Airport shuttle (surcharge)",
        "24-hour front desk",
        "Currency exchange",
        "Tour desk"
    ]
}

예:

---

나는 이것이 SO의 여러 게시물에 의해 다른 곳에서 처리된다고 생각합니다.

몇 가지 :

• MongoDB 관계 : 포함 또는 참조?
• MongoDB에서이 스키마를 어떻게 구현해야합니까?
• MongoDB 스키마 디자인-많은 작은 문서 또는 더 적은 큰 문서?

가장 중요한 열쇠는 여기에 하나의 대답이 없으며 오히려 복잡한 트레이드 오프 세트 만 있다는 것입니다.

참고 URL : https://stackoverflow.com/questions/15208711/mongoose-subdocuments-vs-nested-schema