인프런 커뮤니티 질문&답변
작성한 질문수
두번째 이후 후기들은 왜 관계형인것인가요?
작성
·
230
1
강의감사합니다.
질문이있습니다.
후기의 첫페이지는 조건이필요없으므로, 내장으로 처리를하고, 이후 페이지들은 다양한 조건들이 필요하므로 관계형으로 처리를 한다고 이해하면 될까요?
답변 2
1
모든 후기들을 내장할 수는 없어요. 후기 수가 10개가 될수도 있고 수백 수천개도 될 수 있으니깐요. 무작정 다 내장하면 문서 크기 한계인 16MB를 초과할 수도 있고요. 페이스북, 유투브 등 대부분 보면 모든 댓글들을 한번에 보여주지 않아요. 처음에는 게시글 내용과 최근 댓글 일부만 보여주죠. 이후 댓글들은 "더 보기"를 누르면 추가로 로딩을 하게 되죠.
그래서 블로그 문서에는 처음에 블로그가 로딩되었을 때 보여줄 최근 댓글들만 내장을 하면 좋겠죠. 이후 후기들은 유저가 보고 싶을 수도 있고 안보고 싶을 수도 있으니깐요. 보고 싶으면 "더 보기"를 누를거고 이 때 추가적으로 불러오면 됩니다.
근데 이렇게 일부를 저장하는게 무조건 정답은 아닙니다. 만약 Jon님께서 만든 블로그 서비스에는 다른 서비스들과 다르게 "댓글 보기" 버튼을 누르기 전에는 댓글이 블로그 게시글 화면에 전혀 노출이 안된다고 가정을 해볼게요. 그러면 댓글을 내장할 필요가 없을 수도 있겠죠. 즉 서비스 기획에 따라 최적의 디비 설계가 달라집니다.
좀 더 나아가서 실제로 이럴거 같진 않지만 이런 가상의 상황이 있을 수도 있어요. 사용자들의 패턴을 분석해봤더니 10명 중 9명이 모든 댓글들을 보진 않지만 적어도 "더 보기"를 한번은 누르더라. 이런 통계 데이터가 확보되었다면 그 다음 페이지의 댓글 10개까지 추가로 해서 총 20개까지 내장을 할 수도 있겠죠. 이정도 디테일한 문서 내장 설계는 처음부터 하기는 쉽지 않고 사용자 데이터를 분석하면서 점진적으로 최적화하면 되요.
0
답변 감사합니다.
이해가 너무 잘되었습니다.
여기에 대하여, 추가질문이있습니다.
그렇다면 Blog document만으로 Comment의 최근댓글들만 보여주면,
프론트에서 더보기를 눌렀을때 page를 0이 아닌 1로 설정을하고 불러야하겠네요.
또한 Blog의 내장 Comment 수와 Comment API의 limit과 일치시켜야하구요.
API를 사용하는 클라이언트에게 API호출방식을 제대로 전달하지 못하면 휴먼에러가 발생할 확률이 높아질것같은데,
애초에 Blog, Comment Document 를 따로따로 분리한다면 Comment를 작성하는 API에서도 Blog를 처리하는 로직없이 순수 Comment만 관리할 수 있고, 위의 휴먼에러도 줄일수있을것같은데,
이러한 호출하는 방식에 대해서는 어떻게 생각하시나요?
아 정말감사합니다. 전체적인 강의를 완주하고, 답변들을 하나씩 찬찬히 읽어봤습니다.
어떤 말을 하시려는지 이제 이해가되었고, 강의내용들또한 한번 더 이해가 되었습니다.
사실 저는 여태까지 몽고디비를 관계형처럼쓰고있었는데, 강의에서배운 nesting 들을 트래픽을보며 부분적으로 적용하면서 튜닝을 해봐야겠습니다!
실제로 부하같은것도 저는 프론트엔지니어라 백엔드 데이터를 다룰일이없어서, 강의에서의 설명 또는 이렇게 글로만봐선 이해가 잘 안되는부분이있었어서...
이건 개인적인 요청이지만 몽고 디비의 부하테스트를 해보면서 하나씩 튜닝해나가는 강의같은것은 어떻게 생각하시는지 ...ㅎㅎ
몽고디비에 대해 전반적으로 이해할 수 있는 좋은 강의였습니다. 감사합니다.
오늘하루도 좋은하루되십쇼!
강의에서도 언급했듯이 최적의 성능을 내기 위함이에요.
따로 저장되어 있으면 관계형디비에서는 JOIN을 해야하고 몽고에서는 디비를 두번 요청(populate)를 해야되겠죠. 쉽게 말해서 디비가 하는 일이 늘어나요. 디비는 특히 관계형 디비는 stateful(강의 후반에 나옵니다)하기 때문에 부하에 취약해요. 따라서 디비에 부하를 줄여주는게 장기적으로 봤을 때는 좋아요.
처음에는 관계형, 몽고디비 뭘 사용하든 정규화해서 사용하셔도 전혀 지장이 없어요. 문제는 트래픽이 증가했을 때에요.
서비스를 처음에 론칭할 때는 기능들도 많이 바뀌고 트래픽도 적을테니 애매한 부분들은 정규화를 해두었다가 점진적으로 문서 데이터 구조를 최적화하시면 되요. 디비 부하는 잘못하면 비용이 기하급수적으로 증가하거나 서버가 터지게 되는 사태들이 발생해요. 그에 반면 휴먼 에러는 관리가 가능해요. 그래서 테스트 코드랑 타입스크립트가 프러덕션에서 기본으로 쓰이죠. 큰 기업들은 QC(Quality Control)팀도 있을거고요. 더 나아가서는 Event Driven Architecture를 이용한 백엔드 설계방법도 있는데요. 여기서 설명드리기에는 너무 방대한 내용이지만 휴먼 에러를 줄이는 장점도 있습니다.