将评论和文章放在一起，这里我有一个疑问，当评论数量很大以后，会不会导致在查询文章列表页的时候效率低下？
如果将comments剥离到另一个collection里，这样是不是能缓解只显示文章列表的情况下的压力
{
"_id" : ObjectId(),
"author" : "",
"comment_num" : "",
"comments" : [
{
"text" : "",
"created" : ISODate(),
"author" : ""
},
],
"created" : ISODate(),
"text" : "",
"title" : ""
}
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
@halty는 좋은 지적을 하지만 그의 의견에 전적으로 동의하지는 않습니다. 댓글이 많지 않다면 조합된 디자인도 적당하고 위에서 말씀드린 내용도 아주 좋습니다. 하지만 댓글이 너무 많으면 문제가 발생합니다. 가장 중요한 것은 두 가지 기본 출발점입니다. 1. 하드 디스크가 너무 느립니다. 2. 데이터가 메모리에 있는 한 문제가 없습니다.
데이터가 매우 크면 메모리 매핑 파일이 메모리에 저장되기 때문에 디스크에서 많은 데이터를 읽어야 하지만 그 중 극히 일부만 필요합니다. 주요 문제는 OS가 페이징할 수 있다는 것입니다. 다른 데이터는 하드 디스크에 저장됩니다. 단지 기사를 나열하는 것만으로는 메모리가 효율적으로 사용되지 않습니다.
디스크 파일에서 문서가 계속해서 길어지는 경우가 여러 번 발생하는 것은 좋지 않습니다. 왜냐하면 예를 들어 새로운 코멘트가 추가되는 등 새로운 데이터가 추가되면 문서가 커지고 원래 위치에 맞지 않기 때문에 새로운 위치를 찾아야 하고 이전 구멍을 재사용하게 되기 때문입니다. 그런데 문제는 문서 위치가 변경되면 그에 관련된 모든 인덱스도 변경되어야 한다는 점이다. 댓글을 게시한 사용자의 이름과 같이 배열에 인덱스가 있는 경우 업데이트된 인덱스는 배열 길이와 선형적으로 관련됩니다.
위의 분이 이 점에 대해 좋은 지적을 하셨습니다. 16MB 상한.
결론적으로 댓글이 너무 많으면 경기력에 영향을 미치게 됩니다.
요약, 스키마 디자인을 고려해야 한다
find에서 언급한 메모리 활용 부족은 사실 큰 문제가 되지 않습니다. 인기기사의 댓글은 늘 많은 사람들이 읽게 되므로 기억해 두는 것이 좋습니다. 문서가 계속 길어지면 MongoDB는 이를 할당할 때 자동으로 더 많은 디스크 공간을 할당합니다.그러고보니 이런 어플은 대부분 댓글이 100개가 넘지 않을 것 같은데... 이때는 댓글 수백개도 활용해도 문제 없을 것 같습니다. 주제는 문제가 되지 않습니다. 질문자의 신청이 이 숫자를 넘어설 수 있었으면 좋겠습니다...
먼저 댓글 수가 많을 경우 기사 목록 페이지 조회 시 비효율성이 발생하지 않도록 주의하세요. 쿼리 결과 집합의 문서가 필드 데이터의 일부만 반환하도록 지정할 수 있습니다. (필드 데이터의 일부만 포함하는 문서를 업데이트하고 저장하면 오류가 발생할 수 있다는 점에 유의해야 합니다.) 권장되며 쉽게 네트워크 대역폭을 절약할 수 있습니다.
또한 현재 MongoDB는 단일 문서의 크기에 제한이 있습니다. 댓글이 너무 많으면 문서의 기본 크기 제한을 초과할 수 있으므로 이때 댓글을 제거해야 합니다.