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는 동일한 데이터의 복제로 이어지고 수십만 명의 사용자에게 수십억 번 이상 커질 수 있습니다.
제 1의 옵션이 실행 가능하지 않은 이유는 아직 명확하지 않습니다. 온라인 쿼리를 위해 mongodb에서 조인이 지원되지 않는다는 것에 동의합니다. 그러나이 [post] (https://stackoverflow.com/questions/5681851/mongodb-combine-data-from-multiple-collections-into-one-how)를 사용하면 오프라인 프로세스에 join을 사용할 수 있습니다. 어떻게 첫 번째 옵션이 목적을 무효로하는지 명확하지 않습니다. 당신은 정교 할 수 있습니까? –
** MapReduce ** 기술은 최대 ** 16MB 크기 ** 일 수있는 ** BSON 문서 **를 반환하므로 게시물 개수 및 게시 당 공유 수가 증가하고 결과 문서의 크기가 16MB가됩니다 –
승인. 나는 map-reduce usecase에 관해 당신과 동의합니다. 하지만 여전히 제 1 옵션이 도움이되지 않는 이유를 이해할 수 없습니다. api 요청을 정의하거나 사례를 정의 할 수 있다면 더 명확합니다. –