1주차 회의록
- 참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우
- 시간
- 오전 10:00 ~ 오전 12:00 / 오후 02:30 ~ 오후 07:00
- 그라운드 룰 / 팀 목표 정하기
- 각자 프로젝트를 임하는 목표를 정했습니다.🙆♂️
- git, pr, issue convention을 정했습니다.
- git 전략을 정하는데 애를 먹었습니다... merge방식, main/dev/feat브랜치를 효율적으로 사용하는 법을 찾고 있습니다.
- 아이디어 브레인 스토밍 진행
- 각자 아이디어를 생각하고 그에 대한 의견을 나누었습니다.
- 기본 개발 규칙 정하기
- 파일/변수 이름 짓는 방식, 코드 작성 규칙(eslint, prettier)를 정했습니다.(수정 가능!)
- API 명세서 만들기
- Swagger 서비스를 이용해서 만들기로 정했습니다.
-
참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우
- 성지현 멘토님
-
시간
- 오전 10:00 ~ 오후 12:00 / 오후 01:30 ~ 오후 07:00
-
안건
- 브랜치 전략, 주제 정하기, 기능 토의, 기능 명세서 구조
- 10/26(화) 멘토링
-
주제 정하기
- 아이디어 피칭 이후 부스트캠프 교육 내용을 얼마나 반영하는지, 프론트엔드와 백엔드를 모두 적정한 수준으로 포함하는지, 어느정도부터(e.g. 맨바닥에서부터) 시작해야 하는지 등을 고려하여 구루미 클론 VS 내 지역 후기로 의견을 좁혔습니다.
- 이후에 리뷰어님과의 이야기를 통해서 내 지역 후기를 선택하였고, 위치 정보를 효과적으로 처리하기 위한 기술을 찾아보기로 했습니다.
-
멘토님 미팅 회의록
- 동네 거주 후기 -> 위, 경도 최적화 db가 있으니 찾아보자, 지도 api, 위치 기반 데이터 헨들링(퍼포먼스), 위치를 어떻게 가져올것이냐, 데이터가 많이 쌓여있을 때 성능을 향상시킬 수 있는 단계적인 방법
- 지라 VS 깃허브 -> 깃허브를 주로 쓰는게 좋은것같다. 지라는 wiki를 많이 사용한다.
- 리뷰 -> 피처가 완성되면 한번씩 진행하는게 좋을것 같다.
- 경쟁력 -> 기본은 코딩테스트(많이 갈림), 면바면(cs우선? / 프로젝트(경험)우선? /)하지만, 제일 중요한건 깊은 기술적 고민 -> 기술적 고민이 제일 중요하다!
-
git branch 전략
- 1,2,3 전략 중 첫번째 전략으로 현업에서 멘토님꼐서 하고 계심
-
주제 관련 주요 기능
- 지역에 대한 전반적인 평점을 매겨보자
- 지도 축척 변경에 따라 시 - 군 - 구 레벨로 지도에서 색상 기반 구분 및 마커 표시(평점, 워드 클라우드 내용)
- 지도 위의 마커를 클릭하면 해당 후기들과 그 지역에 대한 사용자들의 반응 통계(텍스트, 평점 등)가 나옴
-
넣고싶은 기능 브레인스토밍
- 후기의 카테고리를 나누자
- 맛집, 여행, 카페, 공원 등
- 동네 랭킹
- 포함 관계를 생각하여 평점을 합산 -> 평점을 매기는 방식은? 가중치는?
- 랭킹 기준은 텍스트+평점
- 랭킹 카테고리가 있어서 맛집, 여행, 카페, 공원 등 적용
- 몇 명, 연령대 인구 공공 API
- 지역의 정보 표시
- 평점을 매기는 방식
- 시, 구, 동 단위로 세 번 매기는 것?
- 평점을 합산하는 방식?
- 치안점수, 교통점수, 문화점수, 공원점수, 교육점수 등으로 세분화해서 점수 매기는 방식이 재미있을 것 같다
- 소모임 채팅
- 동네는 내 위치 인증(중고나라처럼)
- 관심 리스트
- 장소 선정
- 후기를 내 관심 리스트 CRUD
- 번개 이벤트
- 내 근처 사람들에게 푸시알림 보내기
- 사용자 랭킹제
- 후기 많이 올리면 일반자 -> 백작 -> 공작 -> 왕 -> 태양신
- DM
- 중고거래처럼 개인 채팅 방을 개설할 수 있도록 만들기
- 영어버전 만들기
- 외국인을 위한 언어 변경
- 후기 적으면 바로 번역도 가능
- light, dark 버전 만들기
- 색상 변경하기
- 후기의 카테고리를 나누자
-
참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우
-
시간
- 오전 10:00 ~ 오전 11:00 / 오후 02:30 ~ 오후 07:00
-
요약
- git 전략을 최종적으로 결정
- upstream을 제거하고 origin만 존재하는 형태로 다시 git 명령어 정리
- 기술 스택 정하기
- 간단히 정할 수 있는 기술 스택을 생각해서 나누기
- Backend / Frontend / Infra / CI/CD 등으로 나누어서 생각하기
- 기능 구체화
- 기술 스택을 세부적으로 진행하려고 해 보니, 기능을 좀 더 구체화하지 않으면 어려울 것 같으므로, 기능을 우선 구체화하자.
- 메인 기능 작성(사용자 거주지 작성 vs 사용자 위치 인증)
- 거주지 작성으로 하자. 임의로 위치에 따라 거주지 후기를 작성하는 것을 좀 더 번잡하게 적용
- 후기는 어떤식으로 작성할까?
- 잡플래닛에 나오는 것처럼 분야별로 평점을 매기고, 태그를 보여주는 형식이 좋을 것 같다.
- 이외 맛집, 여행 좋은 곳, 공공 시설 등에 대한 자연어 후기를 게시글 부분으로 빼자
- 기본 기능에 대한 의견
- Word cloud는 데이터가 많아야 하기 때문에 카테고리를 보여주는 것이 더 나을 것 같다.
- 유저 접속 시, 거주지는 무조건 입력하도록 하는 것이 편리할 것으로 보임
- 백로그 작성
- 핵심 기능(로그인, 맵, 동네 후기, 동네 게시글)에 대한 백로그 작성
- 추가적인 기능은 내일 더 작성하도록 하자
- git 전략을 최종적으로 결정
-
기술 스택
-
frontend
- TypeScript - React - Recoil vs Redux - Recoil 1표 - App 상태 봐서 1표 - styled component vs module CSS -> Styled Component - CRA vs webpack -> CRA - 사용자 위치 정보 받아오기 HTML5 Geolocation API http://dev.youngkyu.kr/31 https://lcw126.tistory.com/191 - 지도 API 카카오 VS 네이버 -
backend
- nginx - https - TypeScript - Node.js, Express - jwt - 위도, 경도 MySQL 저장 데이터 타입 https://blog.hajs.me/82 -
Infra
- nCloud - Frontend Server : nginx - Backend Server : express - docker -
CI/CD
- jest - github action
-
-
핵심 기능 구체화
-
회원가입 / 로그인
- OAuth 및 프로필 수정 기능
- 최초 OAuth 인증 후 회원등록시 프로필 정보(주소 등) 입력
- OAuth 및 프로필 수정 기능
-
맵 기능
- 웹 페이지 UI 컨셉 : 직방
- 지도 컨셉
- 지도 API 기반의 축척 변경 및 동네 구분, Marker 삽입(총 평점)
- Marker Mouse over 시, 잡플래닛과 유사한 항목 별 평점 표시
- 여유 만들어서 추가(Word cloud 또는 카테고리)
- Marker 클릭 시, 후기 내용 우측 화면 표시
- 400자 이내 후기 글(+사진 -> 쿠팡 처럼)
- 사용자 위치 획득 / 인증
- 사용자 로그인 무관 현재 사용자 위치 기반 지도 보여주기
- 사용자는 프로필에 등록한 주소(동) 기반으로 글 작성 가능
- 후기 동네 클러스터링
- 최소 단위 : 동
- 최대 단위 : 도(광역시 포함)
- 평점 매기는 방식? 평균
-
동네 후기 CRUD
- 동네에 대한 평점 매기기 (카테고리별 세부평점 매기기)
- 동네에 대한 후기 남기기 (평점 부여시 선택, 400자 제한)
- 프로필 작성 기준 글 권한 부여
- 최신순으로 보여주기
-
동네 관련 게시글 CRUD
- 맛집, 동네에 여행하기 좋은 곳, 공공시설 등
- 사진 업로드(object storage 사용)
- 분류 설정(맛집인지, 공공시설인지 등)
- 글 적는 부분
-
DB 설계
- User
- 이름, email(oauth), 거주지,
- User
-
-
git 전략(종우)
1. origin Repository : main / dev 브랜치 생성
2. 최초 1회 Local로 dev 브랜치 clone 후 directory 이동
- (local) git clone -b dev xxx.git
- cd REPO_NAME
3. 기능별 브랜치 생성(feat/{example})
4. 개인별 작업 브랜치로 이동
- git checkout feat/{example}
- git checkout -b {example}/#?
5. Local 작업 브랜치 코드 수정 및 commit 진행
- ({example/#??) git add && git commit
6. Local 기능 브랜치(feat/{example})에 단순 merge
- (feat/{example}) git merge {example}/#??
7. Local 작업 브랜치를 origin 대상 기능 브랜치에 push
- (feat/{example}) git push origin feat/{example}
- 이 때, Conflict 발생 시, rebase 후 conflict 해소 이후 push
- (feat/{example}) git pull --rebase origin feat/{example} 진행 후 conflict 해소, commit, rebase --continue
8. origin feat/{example} -> origin dev으로 PR
- PR 리뷰 및 Squash and Merge
- Conflict 발생 시 - (Local feat/{example}) git pull --rebase origin dev (conflict 해소 후 다시 Push && PR)
- Conflict 미 발생 시 - (Local feat/{example} -> origin feat/{example}) git push feat/{example} && PR
9. 배포판 구성 시, origin dev -> origin main 으로 PR
- create and merge의 경우 origin main -> origin develop으로 fetch 해주어야 함
10. Local 작업 브랜치 fetch and rebase
- (Local dev branch) git pull --rebase origin dev
11. 신규 기능, 3번 부터 반복
- 참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우
- 시간
- 오전 10:00 ~ 오전 12:00 / 오후 01:30 ~ 오후 07:00
- 진행할 사항
- 금일 진행할 일 :
Git 전략 이해,Figma 그리기,기능 명세서 완성,기술 스택 완성,리더 정하기,기능 명세서 우선순위 선정 완료, ERD랑 인프라 구조 설계
- 금일 진행할 일 :
- 요약
-
Git 전략 관련 오전 회의 진행 및 Wiki 페이지 완성
-
지도 geoJson 및 시군구(행정구역) 폴리곤 만드는 방법 확인 필요
-
로그인 로직 관련 회의 진행
- 인증기관별(Google, Facebook, GitHub)로 애플리케이션 하나를 개설
- 로그인시, OAuth Callback URI는 프론트엔드 라우터로 처리
- 프론트엔드에서 Access Token을 발급받은 후 백엔드에 사용자 정보를 조회하는 fetch 요청
- (의문) 이미 access token을 발급받았던 사용자가 다시 발급요청을 보내면 github은 어떤 반응을 보일까 궁금합니다
- 권한 부여과정 없이 새로운 access token을 발급합니다
- 사용자 정보가 등록되어 있으면(이미 가입된 사용자)
- JWT 발급 후 메인페이지로 이동
- 사용자 정보가 등록되어 있지 않으면(가입 대상자)
- Access Token과 인증기관 uid를 담아서 주소지 입력 페이지로 이동
- 제출 후 Access Token으로 인증 기관에 사용자 정보 확인
- 인증되면 DB에 사용자 정보 저장, 회원가입 완료
- JWT 발급 후 메인페이지로 이동
-
Figma 작업 진행
-
App 메인 색상 :
- 현재 figma 색상 무시하고 아래 색상 기준으로 개발
-
로고 만들기
- 대회 : 로고 각자 만들어와서 투표를 통해 꼴찌가 1등에게 오프라인 모임 때 커피 사기!!
- 링크
-
기능 명세서(백로그) 핵심 기능 수정 완료
- 중요도 설정 완료 : 메인 기능들은 High, 애니메이션 등 Front 관련 내용 Middle, 기타 Low로 설정
-
ERD 설정
- 테이블
- User : 사용자 정보 저장
- Column: id(PK), oauth_platform_email(NN), 거주지(NN)
- Rate : 지역 평점 정보 저장 테이블
- Column: id(PK), user_id(FK), safety_rate(NN), traffic_rate(NN), food_rate(NN), enter_rate(NN), 거주지(동 단위)(NN), postscript
- Article: 게시글 정보 테이블
- Column: id(PK), user_id(FK), content(NN)
- Image: 게시글 이미지 테이블
- Column: id(PK), Article_id(FK), url(NN)
- Category: 게시글 카테고리 테이블
- Column: id(PK), Article_id(FK), category(NN)
- User : 사용자 정보 저장
- 기능 명세
- User는 oauth 기반 로그인을 할 수 있다.
- User는 거주지에 대한 평점을 매길 수 있다.(6개월 1회)
- User는 거주지에 대한 N개의 게시글을 남길 수 있다.
- 게시글에는 관련 이미지를 3개까지 첨부할 수 있다.
- 게시글은 관련 카테고리를 최대 3개까지 설정할 수 있다.
- Associations
- User - Rate (1:N)
- User - Article (1:N)
- Article - Image (1:N)
- Article - Category (1:N)
- 테이블
-
인프라 설계 구조
- 초기에는 1개 인스턴스에 Front / Back 서버 모두 구축, DB 서버는 별도 구축
- DB - MySQL 의 경우 replication 설정 직접 진행하여 Master - slave 구축하기
- 이미지의 경우 Object 스토리지 사용하여 통신
-
기술 스택
- FE
- React - Recoil vs Redux - TypeScript - styled component - CRA - HTML Geolocation API (사용자 위치 정보 받기) - 참고 - http://dev.youngkyu.kr/31 - https://lcw126.tistory.com/191 - 지도 API 네이버 / 카카오 - 행정구역 Clustering, geoJSON 설정 - 마커 표시, 마커 클릭 이벤트 - BE
- Express - TypeScript - HTTPS - NCloud - MySQL - Test
- Frontend : jest - Backend : postman - CI/CD
- github action - Infra
- nCloud - Frontend Server : nginx - Backend Server : express - Object Storage
- FE
-
참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우
-
시간
- 오전 10:00 ~ 오전 11:30, 오후 04:00 ~ 오후 05:00, 오후 06:00 ~ 오후 07:00
-
진행할 사항
- 금일 진행할 일 : PR/이슈 템플릿 만들고 테스트, README 업데이트(+기술적 도전 명세), 발표할 내용 정하기, API명세 작성, 그라운드 룰 수정
-
요약
- 템플릿 만들기 완성 및 README 예쁘게 다듬기 완료
- 발표 내용에 한 주동안의 과정(어떻게 회의하고, 어떤 과정에서, 무엇을 결정했는지 등)
- API 명세 일부 토의
- 스크럼 및 회의록 게시 당번 결정
- 10/29(금) 멘토링
-
발표 방식
- 기본적으로 readme 내용
- 프로젝트 개요 / 기술 스택 / 기술적 도전 / README에 정리한 내용
- figma
- 디자인 및 컨셉 설명
- 인프라
- 인프라 구조 초창기 설계 내용 및 추후 발전시킬 컨셉 대략 설명
- 어떻게 회의하고? 아침 10시부터 저녁 7시까지 풀 화상미팅+회의록 작성
- (1일차) groud rule 정하기
- (2일차) git 전략 회의(단계를 나눴던거)
- (3일차) 주제 정하고 기능 명세서 작성+멘토님 미팅 -> 주제를 늦게 정하게됬다
- (4일차) 백로그 작성 완료 및 figma 작성
- 협업 툴 : hackmd, google spreadsheet, figma
- 기본적으로 readme 내용
-
추가 의견
- SPA 그리고 SSR과 CSR
- CI/CD를 좀 더 Tool 기반 전문적으로 사용하기 (sourcedev, sourceComit, SourceBuild, SourceDeploy, SourcePipeline)
- 도커의 경우 CI/CD를 좀 더 잘할 수 있고, 배포판을 따로 관리한다면 좋다고 함
- 현재 인프라 구조로 구성을 한 뒤 나중에 전문적인 Tool과 docker를 사용해보기
- 다른 팀은 Socket.io, WebRTC 등의 기술을 많이 사용하려는 흔적이 보임. 우리 프로젝트에는 현재 적합하지는 않은 듯.
-
API 명세서 작성
-
회원가입(프론트엔드에서 access token 다 받은 후)
- request: GET /api/auth/sign-up
- response: 로그인 페이지로 redirect
-
로그인
- request: GET /api/auth/sign-in
- response: true/false
-
MAP
- request: GET /api/map?현재 한단계위 시/군/구
- response: 그 시/군/구에 있는 한단계 아래 모든 동네 총 별점, 카테고리별 별점, 상위 3개 태그
- 축적이 구 단위이면 가져오는 정보는 현재 구가 포함된시에 있는 모든 구 폴리곤 정보를 가져온다
- 축적 레벨에 따라서 가져오는 정보를 한 단계 위(지도 꽉 채우기)로 또는 한 단계 낮게(지도 여백 남기기) 둘 중 하나 정하기
-
사이드바(Map 클릭 시)
- 후기
- request: GET /api/postscripts?선택된 동네
- response: 현재 동네의 후기 정보 상위 5개
- 게시글
- request: GET /api/articles?선택된 동네
- response: 현재 동네의 게시글 정보 상위 5개
- 후기
-
후기 작성 Modal
- request: POST /api/postscripts
- Body : 선택 동네, 평점
- response: 후기 정보 DB 저장 결과
- request: POST /api/postscripts
-
-
swagger vs postman
- swagger 공부해보기
-
참고: ElasticSearch
- 유튜브 링크(기초 사용법)
- 개념 설명 블로그
- elastic maps
- ip정보로 위도/경도, 나라, 지역을 뽑아낼 수 있다.
- 한국도 지원을 시작했으며, 시/군/구까지 정보를 표시할 수 있다.
- 돈내는거 같다.
- http://kimjmin.net/2019/01/2019-01-korea-region-map/
- elastic stack
- elastic search + kibana + logstash
- 잘 모르겠다. 확장팩같은건가? 기능 추가되는거 같은데...
- elastic maps도 이렇게 묶음인것 같다.
- https://17billion.github.io/elastic/2017/06/30/elastic_stack_overview.html
- DB에서 유저를 빼고는 모두 elastic search에 저장해야할 것 같다.
- 그럼 이미지는 어떻게 처리할까...?
-
일요일 오전 10시 회의
- DB
- API
- 인프라 도커 적용
- 무중단 배포
-
그라운드 룰 추가
- 주차별로 스크럼, 회의록 위키에 올리는 것 담당하기
- 홍승용, 문혜현, 홍종우, 송명회
- 참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우
- 시간
- 오전 10:00 ~ 오전 12:40
- 진행할 사항
- 금일 진행할 일 : README 예쁘게 업데이트, DB 설계 회의, Docker 기반 무중단 배포 방안 회의
- swagger vs postman
- postman 결정
- Docker를 활용한 무중단 배포(참고)
- https://velog.io/@doyuni/Jenkins-NAVER-Cloud-Platform-Docker%EB%A1%9C-CICD-%EB%AC%B4%EC%A4%91%EB%8B%A8-%EB%B0%B0%ED%8F%AC-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0-1%ED%8E%B8-khk4w6hrm0
- PM2 를 사용하거나, Jenkins - Source Deploy 방식으로 활용. Jenkins에 대한 사용 경험이 없어 즉각적인 반영은 어려울 것으로 보임. 우선 초기에는 간단한 인프라로 PM2, Github actions를 따라서 배포하고 시간이 나면 고도화 진행
- CSR vs SSR with hydration
- CSR
- 이유 : 현재 우리 웹 페이지의 경우 요구되는 정적 데이터가 많지 않고 추가 데이터는 클릭 시의 fetch API를 사용하므로 SSR hydration이 불 필요할 것으로 보임
- DB: MongoDB
- User와 Rate, Article은 Link
- Link vs Embed? Embed를 쓰면 상위 Document를 참조한 뒤 아래로 내려가는 방식인데, 거주지 정보가 update되었을 때, 일관성이 필요하므로 별도로 중복 저장하는 것이 낫다고 판단. 또한 Embed의 장점은 상위 Document에서 필터링 시, 추가 필터링 필요가 없어야 하는데, 거주지 정보로 추가 필터링을 해야 하므로 이점이 없다고 판단.
- User, Rate, Article은 모두 residence key를 중복으로 가지고 있음
- Article은 Image와 Category를 embedded
- key로 Image, Category, value로 list
- time column 추가(ok)
- 성능을 고려했을 때 ranking document를 만들지 고민(멘토님께)
- 6개월 이내 데이터만 가져오므로 엄청난 대용량이 아닐 것이다
- 삭제가 아닌 비교하는 것이기 때문에 전체적으로 보는 것은 똑같다
- region을 시, 구, 동으로 나누자(멘토님께)
- index를 residence 하나에 주는 게 더 편하고, LIKE를 쓰자
- LIKE를 할 경우 비교를 한 번 더 해주는 연산이 필요하다
- 실험을 해보자
- region: [시, 구, 동] or key: 시, 구, 동
- key 3개로 할 경우 index를 다 주게 되면 괜찮은가?
- 마커의 위경도 위치, polygon 위경도
- 선거때마다 행정구역이 변한다
- 일단 주소와 좌표를 둘 다 저장하되, 행정구역이 변할 때만 DB 전체를 업데이트하는 방식으로?
- 주소: 앱 내에서 지역별 연산에 사용
- 위경도: 행정구역이 바뀔 경우(DB 업데이트 필요시) 사용
- 우선순위 낮음
- 행정구역 업데이트란?
- 판교동 -> 판교1동, 판교2동(이름바뀜)
- 위경도 바뀜
- coordinate
- 사용자의 도로명 주소 위치 위경도 값
- User와 Rate, Article은 Link
- Collection
- User
- { _id, username, residence, coordinate: { latitude, longitude } }
- Rate
- { User.id, residence, coordinate: { latitude, longitude } user_id, total_rate, category_rate: {safety, traffic, food, enterainment}, content, createdAt }
- index: residence
- Article
- { User.id, residence, coordinate: { latitude, longitude }, images: [ image1, image2, image3 ], categories: [ category1, category2, category3 ], createdAt, updatedAt }
- index: residence
- Map : 시일 때 마커, 구일 때 마커, 동일 때 마커 다 다름(데이터 보고 결정)
- { place, marker : {latitude, longitude}, polygon }
- 행정구역 중심점 정보 변환하여 사용(https://github.com/vuski/admdongkor)
- User
- 하고자 하는 것
- geoJSON 기반 지도 폴리곤(위/경도 좌표 사용) 그리기
- 지도상 행정구역 중심부에 Marker 찍기
- 행정구역 변화에 대응할 수 있는 DB 구조 설계
- 행정구역 변화 시, User, Rate, Article의 Key인 위치 정보 업데이트 (ex - 청담동 -> 청남동)
- 후기, 게시글 정보의 경우 마커 클릭 시, 해당 지역 정보만 fetch하여 보여주기
- 사용자 거주지 이전 시, 이전에 동일 사용자가 남긴 후기 정보는 사용자 거주 이전에 영향 받지 않도록 설계
- 논의한 사항
- geoJSON 정보, 행정 구역 중심지 정보 데이터 사전 저장(https://github.com/vuski/admdongkor)
- 행정구역 정보 자체를 갖는 Map 정보 Collection 저장
- 행정구역 정보를 각 Collection에 중복 저장(User, Rate(후기), Article(게시글))
- 사용자의 동네 위치를 시/군/구: text로 저장해서 앱 내에서 연산에 사용
- 동네 위치의 위경도: 행정구역 바뀜에 따른 DB(시/군/구) 업데이트에 사용
- 문의 드리고 싶은 사항
- 시/구/동 -> full text VS 시, 구, 동과 같이 나누어 저장
- 전자의 경우 regex query를 통해 조건에 맞는 데이터를 조회할 수 있고, 후자의 경우 각 key 값으로 바로 쿼리가 가능한데, 이 때의 성능차이가 심할까요?
- 둘 모두 index를 만들었을 경우 : 시/구/동 모두 index 부여 그리고 full text에 index 부여
- 행정구역 업데이트에 따른 성능 고려
- 평시 앱을 사용할 때는 시/구/동 정보를 사용토록 하고, 정기적인 구역 업데이트 시에만 전체 앱 DB 정보를 업데이트 하도록 위/경도를 사용하는 것이 좋을까요?
- 위/경도 기반으로 평점/게시글 정보를 연산해서 가져오는 것은 너무 성능에 영향이 크지 않을까요?
- 위치 정보가 바뀌었을 때 거주지를 업데이트할 시, 모든 document에 들어있는 위치 정보를 업데이트 할 수 있는 방법 고민
- 도큐멘트의 위치 정보를 중복저장할지 참조형식으로 할지 고민이 됩니다. 중복저장해야 더 성능이 좋아지고 mongoDB의 특성을 잘 살리는것 같은데, 참조 형식과의 성능차이가 많이 날까요? 행정구역에 대한 DB 지역 업데이트시에는 참조형식이 좀더 유리할것 같아서 고민이 됩니다.
- mysql의 foregin key cascade update 형식
- 데이터 중복저장이 안되기 때문에 mongoDB의 특성을 살리지 못한다
- 시/구/동 -> full text VS 시, 구, 동과 같이 나누어 저장