3주차 멘토링

2021-11-09

참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우, 성지현 멘토님
시간
- 19:30 ~ 20:30

멘토님 문의 드릴 사항

현재 도큐먼트 사이즈를 줄였는데, 2MB초과 경고가 뜬다. 도큐먼트를 나누는 방법?
현재 폴리곤 정보를 프론트에서 캐싱해서 사용하고 있는데, 메모리에 저장해서 사용하고 있다. 혹시 localStorage 등을 사용하면 더 나을지? 아니면 더 나은 방법이 있을지?
복합 인덱스 VS 따로 인덱스 VS 그냥 -> 거의 차이 없음
성능 최적화를 위해, 요청 줄이기 + 캐싱을 했는데 다른 방법 더 생각하시는 게 있으신지?

멘토님 말씀

https왜 안됨?
- ip가 아니라 domain을 활용해서 kakao map api에 요청해야 한다.
DB
- 쿼리 문제? 네트워크 문제?
  - 네트워크 문제(인터넷 대역폭 이슈, 컴퓨터 자체적인 성능 이슈)
- Compass (MongoDB client)로 DB 요청만 날려보았는가?
  - codeLength index가 사용 안 됐었다..? 인덱스가 잘못 걸려있던 듯
  - 인덱스 제대로 걸었더니 빨라지긴 했는데 여전히 많이 느리다. 20MB면 전혀 큰 사이즈가 아니다.
  - Atlas 머신 이슈일 수 있다. 머신 스펙, 서버 위치 등.
  - 미국 region인데 그냥 네트워크 이슈인듯. 일본, 동남아 등
- ncloud내에서 mongodb를 만들면 local에서 만든 것처럼 빨라질 가능성이 있다
  - 여유가 되면 replica 세팅까지 해서
  - primary 1, secondary 2 or primary, secondary, arbiter
- Document 사이즈 2MB 초과한다는 경고가 자꾸 뜨는데 특별히 문제가 되는가?
  - Document 사이즈는 데이터 업데이트할 때 성능 문제 발생
  - 폴리곤 데이터는 거의 static한 데이터라서 업데이트가 자주 있지는 않다.
UI framework
- 사용해도 괜찮을듯 e.g. Material UI
Webpack
- code splitting
- 앱이 커지면 로딩 시간이 길어진다. Code splitting하면 보통 페이지별로 나누어짐
- 하려면 eject해서 custom 해야 함
- bundlefile을 갖고 오지 못할 때, 어떻게 처리할지도 생각해보기
index 관련 질문
- text(주소)와 codeLength에 복합 인덱스를 걸었었는데..
  - 텍스트 인덱스라서 이슈가 있는것 같다고 하신다.
  - 인덱스 prefix가 안 먹었던 것 같은데 봐야할듯?
cache
- 괜찮은 아이디어.
- 클라이언트 메모리 혹사시키는 것 같은데 괜찮은가?
  - 어느정도 타협을 해야 한다.
  - localStorage: 5MB가 최대.
  - localStorage를 사용할 거면 5MB 선에서 캐싱을 하는 건 괜찮다
  - 메모리에 캐시해둬도 괜찮다.
  - localStorage는 영구 저장소라는 것을 생각하고 무엇을 저장할지 결정해야 할듯.(데이터 변경 고려)
Document 2MB 이상인 것에 대한 이슈
- Select만 하는 것이고 업데이트가 없는 형상이므로 굳이 고려하지 않아도 될 것으로 보임
- document 크기가 이슈가 되는 이유는 mongodb가 memory에 다 올려서 하기 때문에 따라서 update하는 경우 이슈가 됨
화면에 꽉차게 폴리곤을 그려줘야 하지 않을까? 인접지역
- 중앙에 마커 두고 사용자가 어딜 볼지 선택하도록 하면 될것 같다.
검색 기능(자동 완성)
- ES 사용하면 간편하게 할 수 있을 것이다
- 시군/구/동 text와 center 좌표를 넣으면 될 것이다
- 이미 저장하고 있고 데이터가 그다지 많지도 않아서 그냥 Map 컬렉션 사용해도 될듯?
  - 좌표만 빼고 컬렉션을 만들던지 쿼리 날릴 때 좌표만 빼고 가져오도록
- covered index 사용 : index만 갖고도 데이터를 뽑을 수도 있다고 한다(document까지 보지 않아서 빠르다)
mongodb의 text index보다 ES가 더 최적화 되어 있고 플러그인도 많다