10_1. 부분 Nesting & Pagination을 이용한 고급스러운 API 만들기 - 섹션 소개
- 내장(Nesting)
- 내장하려는 자식문서가 너무 많으면 안된다.
- 너무 많으면 부분만 내장한다.
- 관계(populate)
- 내장해야될 때 정보가 너무 많으면 관계를 사용한다.
- 탐색속도를 개선
- 인덱스
- 페이지네이션
10_1_1. 내장(Nesting), 페이지네이션 적절하게 같이 사용해서 고급스러운 API를 만들어보자.
- 댓글이 정말 많은 경우 (예를 들어, 1000개)
- 그럼 내장(Nesting)을 다 포기해야될까?
아니다. 이 1000개를 다 내장할 필요는 없다.
DB랑 API 설계할 때, 클라이언트에서 어떻게 사용할지를 상상하면서 설계하라고 했다.
댓글이 이렇게 많다고하더라도, 이 댓글을 화면에 한번에 나열하진 않는다.
적절하게 필요한 만큼만 나열을하고, 페이지네이션을 적용해서 필요할 때 그 다음 내용을 보여줄 것이다. (무한스크롤)
필요한 만큼만 화면에 랜더링하는 것이다. - 즉, 블로그에 최신 댓글들만 내장해주면된다.
그럼 댓글이 아무리 많아져도 내장되는 댓글은 많아지지 않을 것이다.
내장되는 댓글 갯수를 제한한다면 딱 그만큼만 내장될 것이다. - 그리고 그 다음 정보(댓글)들을 보고싶다면, 그때 관계(populate)된 데이터를 페이지네이션 적용(skip, limit)한걸로 불러오면된다.
- 그럼 내장(Nesting)을 다 포기해야될까?
10_1_2. 댓글 총 갯수 보여주고싶을 수도 있고, 아니면 무한스크롤링 같은 페이지네이션이아닌 1, 2, …, 6, 7, 8, …, 99, 100 이런 페이지네이션이라면?
- 댓글 총 갯수 보여주고싶을 때
- 1, 2, …, 6, 7, 8, …, 99, 100 이런 페이지네이션일 때, 100이 끝 페이지란걸 의미하는 것.
즉, 끝 페이지를 알려주고 싶을 때
이런 경우엔 총 댓글 갯수가 몇개인지 알아야된다.
이번 세션에서 이런걸 복합적으로 사용할 수 있는, 응용할 수 있는 고급스러운 API를 만들도록 하겠다.
10_1_3. 이번 세션에서 해볼거
- 댓글 페이지네이션 처리
- 댓글 총 몇개있는지 확인하기
- 블로그의 최신 댓글들만 내장하기
10_1_4. 부분 정보만 내장하면 어떤 이점이 있는가
위와 같이 부분(id만) 내장하더라도 관계처럼 똑같이 populate로 불러와야되는데, 어떤 이점이 있길래 이걸 사용하는걸까?
- 부분 내장일 경우: 그냥 populate
- 내장 안할경우: virtual populate
이런 차이인데, 사실상 DB에 한번 호출이 들어가는건 똑같다.
그런데 부분만 내장할 경우, 여태 document를 생성해서 알겠지만, document(문서)를 생성할 때, _id 각 문서의 고유 id는 무조건 생성이되고, 무조건 인덱스 처리가된다. unique 처리도된다.
이미 id가 생성이 되어있는 것이다.
따라서 부모 문서에 자식 문서의 _id가 내장되어있으면(부분 내장), 인덱스된 키로 불러올 수 있다.
따로 인덱스 처리할 필요가 없는 것이다.
그런데 1000 < N 이 경우엔 좀 다르다.
왜냐하면, 자식문서(댓글)의 _id는 인덱싱이 자동으로 되어있지만, 댓글의 blog엔 인덱스가 되어있지 않잖아?
그래서 부분 내장일 때의 효과랑 똑같은 효과를 보고싶으면, 댓글에도 blog의 id를 인덱스를 걸어줘야된다.
- 즉, 쉽게말하면
1000 < N이 경우에 추가적인 인덱스가 걸리고, - 부분 내장인 경우엔 추가적인 인덱스가 걸리지 않는다라는 것이다.
인덱스는 메모리를 차지하기 때문에 (메모리는 비싸다고 했잖아?)
즉, 부분내장을 사용하면 인덱스를 아낄 수 있는 것이다.
그런데 만약, 인덱스가 이미 걸려있다면, 사실 부분내장은 큰 의미는 없다.
- 댓글에서 blog id 인덱스를 걸지 않았거나 그럴 땐 부분내장이 유용할 수 있다.
부분내장을 사용하면 하드디스크 용량 차지는 늘어날 것이다.
blog에 댓글 id를 내장하니깐.
하지만 하드디스크는 메모리에비하면 훨씬 싸다는 것!
10_1_5. ObjectId
일반 긴 string을 그대로 저장하는 것보다 ObjectId 형식으로 저장을하면, 용량이 줄어든다.
_id는 모두 인덱스가 걸린다고 했잖아?
인덱스는 메모리를 차지하고, 메모리는 비싸고, 즉, ObjectId를 통해 _id의 용량을 줄이는 것도 의미가 있다.
그래서 ObjectId를 사용한다.
- 댓글 페이지네이션 처리
- 댓글 총 몇개있는지 확인하기
- 블로그의 최신 댓글들만 내장하기