두번째 이후 후기들은 왜 관계형인것인가요?

모든 후기들을 내장할 수는 없어요. 후기 수가 10개가 될수도 있고 수백 수천개도 될 수 있으니깐요. 무작정 다 내장하면 문서 크기 한계인 16MB를 초과할 수도 있고요. 페이스북, 유투브 등 대부분 보면 모든 댓글들을 한번에 보여주지 않아요. 처음에는 게시글 내용과 최근 댓글 일부만 보여주죠. 이후 댓글들은 "더 보기"를 누르면 추가로 로딩을 하게 되죠.

그래서 블로그 문서에는 처음에 블로그가 로딩되었을 때 보여줄 최근 댓글들만 내장을 하면 좋겠죠. 이후 후기들은 유저가 보고 싶을 수도 있고 안보고 싶을 수도 있으니깐요. 보고 싶으면 "더 보기"를 누를거고 이 때 추가적으로 불러오면 됩니다.

근데 이렇게 일부를 저장하는게 무조건 정답은 아닙니다. 만약 Jon님께서 만든 블로그 서비스에는 다른 서비스들과 다르게 "댓글 보기" 버튼을 누르기 전에는 댓글이 블로그 게시글 화면에 전혀 노출이 안된다고 가정을 해볼게요. 그러면 댓글을 내장할 필요가 없을 수도 있겠죠. 즉 서비스 기획에 따라 최적의 디비 설계가 달라집니다. 

좀 더 나아가서 실제로 이럴거 같진 않지만 이런 가상의 상황이 있을 수도 있어요. 사용자들의 패턴을 분석해봤더니 10명 중 9명이 모든 댓글들을 보진 않지만 적어도 "더 보기"를 한번은 누르더라. 이런 통계 데이터가 확보되었다면 그 다음 페이지의 댓글 10개까지 추가로 해서 총 20개까지 내장을 할 수도 있겠죠. 이정도 디테일한 문서 내장 설계는 처음부터 하기는 쉽지 않고 사용자 데이터를 분석하면서 점진적으로 최적화하면 되요.

답변 감사합니다.
이해가 너무 잘되었습니다. 

여기에 대하여, 추가질문이있습니다. 

그렇다면 Blog document만으로 Comment의 최근댓글들만 보여주면, 

프론트에서 더보기를 눌렀을때 page를 0이 아닌 1로 설정을하고 불러야하겠네요. 

또한 Blog의 내장 Comment 수와 Comment API의 limit과 일치시켜야하구요. 

API를 사용하는 클라이언트에게 API호출방식을 제대로 전달하지 못하면 휴먼에러가 발생할 확률이 높아질것같은데, 

애초에 Blog, Comment Document 를 따로따로 분리한다면 Comment를 작성하는 API에서도 Blog를 처리하는 로직없이 순수 Comment만 관리할 수 있고, 위의 휴먼에러도 줄일수있을것같은데, 

이러한 호출하는 방식에 대해서는 어떻게 생각하시나요?