0

mongodb를 처음 사용시 NoSQL 개념을 사용하고 있으며, 내 목적에 가장 부합 할 수있는 스키마를 모델링 할 수없는 시점에서 멈추었습니다.포스트와 공유에 대한 몽고브 스키마

게시물을으로 정렬하여 내 최종 결과가 인 방식으로 스키마를 디자인해야합니다.


옵션 1 :이를 위해 나는 두 가지 옵션을 고려 다른 게시물에 대한 수집 및 공유을 같은 :

스키마 포스트 모음 :

var postSchema = mongoose.Schema({ 
    postText: String, 
    postedBy: String, 
    privacy: Number, 
    updatedOn: { type: Date, default: Date.now }   
}, { collection: 'posts' }); 

스키마 공유 컬렉션

var shareSchema = mongoose.Schema({ 
    dis_Id: { type: mongoose.Schema.Types.ObjectId }, // Id of post that is shared 
    shareBy: { type: mongoose.Schema.Types.ObjectId }, 
    shareText: String, 
    share_privacy: Number, 
    shareOn: { type: Date, default: Date.now } 
}, { collection: 'shares' }); 

옵션 2 : 포스트

var postSchema = mongoose.Schema({ 
    postText: String, 
    postedBy: String, 
    updatedOn: { type: Date, default: Date.now }, 
    privacy: Number, 
    share: { 
    shareBy: { type: mongoose.Schema.Types.ObjectId }, 
    shareText: String, 
    share_privacy: Number, 
    shareOn: { type: Date } 
    }  
}, { collection: 'posts' }); 

지금은 게시물에 포함 된 공유 자체

새 스키마 더 나은 선택이 될 수있는이 무엇입니까? 옵션 1은 mongodb에 조인이 없으므로 쿼리에 문제가 있으며 옵션 2는 동일한 데이터의 복제로 이어지고 수십만 명의 사용자에게 수십억 번 이상 커질 수 있습니다.

+0

제 1의 옵션이 실행 가능하지 않은 이유는 아직 명확하지 않습니다. 온라인 쿼리를 위해 mongodb에서 조인이 지원되지 않는다는 것에 동의합니다. 그러나이 [post] (https://stackoverflow.com/questions/5681851/mongodb-combine-data-from-multiple-collections-into-one-how)를 사용하면 오프라인 프로세스에 join을 사용할 수 있습니다. 어떻게 첫 번째 옵션이 목적을 무효로하는지 명확하지 않습니다. 당신은 정교 할 수 있습니까? –

+0

** MapReduce ** 기술은 최대 ** 16MB 크기 ** 일 수있는 ** BSON 문서 **를 반환하므로 게시물 개수 및 게시 당 공유 수가 증가하고 결과 문서의 크기가 16MB가됩니다 –

+0

승인. 나는 map-reduce usecase에 관해 당신과 동의합니다. 하지만 여전히 제 1 옵션이 도움이되지 않는 이유를 이해할 수 없습니다. api 요청을 정의하거나 사례를 정의 할 수 있다면 더 명확합니다. –

답변

0

확인. 이미 이름을 가지고 있기 때문에

  1. , 당신은 sort를 사용하여 정렬 된 순서로 해당 ID에 해당하는 게시물의 목록을 검색 할 수 있습니다 : 나는 다음과 같은 접근 방식을 제안한다.

  2. 각 게시물을 반복하면 위에서 사용한 것과 같은 정렬을 사용하여 정렬 된 순서로 공유를 가져올 수 있습니다.

여기서 중요한 것은 설정하려는 색인을 이해하는 것입니다. 나는 당신이 다음의 색인을 가져야한다.

post_schema :에 복합 인덱스 {사용자 이름, updatedOn}

share_schema : {dis_Id, shareOn}에 복합 인덱스입니다.

복합 색인을 사용하지 않으면 많은 수의 레코드에 대해 응용 프로그램의 크기가 조정되지 않습니다.

+0

여기 하나 더 문제가있다 : 나는 ** 포스트 **와 ** 몫 **를 소트 한 순서에서 각각 얻는다 그러나 나는 포스트와 몫의 혼합물로 더 분류를 필요로한다. ** 예 : **의 경우 : 오전 9시에 게시되는 if (A)는 오후 3시에 (A1) 공유되고 오후 12시에는 게시됩니다. UR 로직에 따르면 나는 A보다 B가 A1보다 B가 더 높을 것이지만 나는 A와 B가 필요하다. –

+0

좋아요, 내가 알기로는이 공유/게시물을 병합하는 사용자 지정 논리를 작성해야 할 것입니다. 모든 레코드를 단일 행에 추가하는 경우 mongo의 map-reduce 기능은 도움이되지 않습니다. 그러나 게시/공유의 단일 레코드가 단일 행이되도록 처리하면 MR을 사용하여 수행 할 수 있습니다. 결론을 내려면 사용자 지정 논리를 작성해야합니다. –

0

모든 필수 데이터를 함께 가져올 때 포함 된 문서로 작업하기 쉽습니다. 따라서 옵션 2가 좋습니다. 그러나 문서 크기가 16MB 이상으로 증가 할까 염려하면 옵션 1로 이동하십시오.이 경우 수집 작업을 수행하는 데 시간이 오래 걸리기 때문에 집계 쿼리를 사용하지 마십시오. 그러면 모든 작업을 먼저 수행 한 다음 동작 건너 뛰기. 대신 각 컬렉션을 개별적으로 쿼리하고 사용자 정의 논리를 사용하여 완전한 응답을 직접 작성해야합니다.

+0

글쎄,이 점을 염두에 두어 옵션 2로 어떻게 할 수 있겠습니까? 여기에 또 다른 문제가 있습니다. 게시물과 공유를 각각 정렬 된 순서로 얻지 만 게시물과 공유가 혼합 된 상태에서 추가 정렬이 필요합니다. 예 : if (A)가 오전 9시에 게시되면 오후 3시에 공유 (A1)되고 오후 12시에 게시됩니다. UR Logic에 따르면 A보다 B가 A1을 얻지 만 순서 A와 B가 필요하고 A1 –

+0

을 입력하면 사용자 정의 코드를 작성해야합니다. 원하는 컬렉션에서 문서를 가져와 필요한 순서대로 병합하십시오. – Ricky

+0

그리고 어떻게 병합해야합니까? 집계 또는 다른 방법 사용? –