-
Notifications
You must be signed in to change notification settings - Fork 1
[REFACTOR] 지도 화면 가맹점 조회 로직 개선 #121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
chaen-ing
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
수고했어~~~!!! 위에 코멘트 단 거 확인만 한번 해주면 좋을 것 같고 나머지 전부 괜찮은 것 같아!! 실행속도 측면에서도 굿.. 👍
그리고 서버에 디스크 용량은 많이 남는다고 생각해서 이 방식 유지해봐도 좋을 것 같아!
머지한 후에 해당 api들 잘 돌아가는지 확인하면서 대구 데이터 넣어놓을게!~
| // 삭제될 기존 데이터의 ID 확보 | ||
| List<Long> oldStoreIds = storeRepository.findIdsByRegion(targetRegion); | ||
|
|
||
| // 기존 데이터는 유지하며 정보 갱신, 신규 데이터는 추가 | ||
| storeJdbcRepository.upsertStores(newStores); | ||
|
|
||
| // 새로운 파일에 없는 가맹점 삭제 | ||
| storeJdbcRepository.deleteMissingStores(targetRegion); | ||
|
|
||
| // redis에 해당 지역의 기존 데이터 삭제 | ||
| redisTemplateCacheService.removeStoreLocationsBulk(oldStoreIds); | ||
|
|
||
| // 최신화된 해당 지역 데이터 조회 | ||
| List<Store> updatedStores = storeRepository.findByRegion(targetRegion); | ||
|
|
||
| // redis에 최신 데이터 저장 | ||
| redisTemplateCacheService.saveStoreLocationsBulk(updatedStores); | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
새로운 csv파일을 업로드 할 때 해당 지역의 기존 redis에 있던 데이터는 전부 삭제하고 새로운 csv 파일의 데이터를 넣는거라구 보면 될까??! 어차피 csv 파일 올리는건 횟수가 적으니까 상관없다고 생각하는뎅 그냥 궁금한점이야!!!ㅎㅎ
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
맞아 ! 우리 csv파일이 '지역'을 기준으로 되어있어서, 그 '지역'에 해당하는 데이터를 다 지우고 다시 새로 업로드 하는 방식이야 !
|
|
||
| @Operation( | ||
| summary = "가맹점 위치 데이터 강제 동기화", | ||
| description = "MySQL의 모든 가맹점 위치 정보를 Redis Geo Index로 적재합니다.") | ||
| @PostMapping("/store-locations") | ||
| public ResponseEntity<ApiResponse<Object>> syncStoreLocations( | ||
| @AuthenticationPrincipal CustomUserDetails userDetails) { | ||
| ; | ||
| return ResponseEntity.ok(ApiResponse.from(storeCacheService.syncStoreLocations())); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
이 때 중복저장 등의 문제는 없는지 궁금해용~
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorted Set은 동일한 id를 중복해서 가질 수 없대 ! 동일한 id로 데이터를 넣으려고 하면, 덮어쓰기 작업이 일어날 뿐 데이터가 중복되어 늘어나지 않는다고 합니당 !
📝 개요
지도 화면에서의 '현위치 기반' 가맹점 조회 로직을 개선했습니다.
🛠️ 작업 사항
⬅️ 기존 방식
저번 PR 에서 MySQL의 공간 함수 (
ST_Distance_Sphere) 방식을 Boundingbox + 인덱스를 통해 개선을 하였습니다.그럼에도 불구하고, 지도는 특성 상 드래그/확대/축소 시 api가 빈번하게 호출되기 때문에 더 개선할 수 있을 것 같다고 생각했습니다.
➡️ 개선 사항 -> Redis Geospatial
지도 화면 가맹점 조회 로직 개선
GEORADIUS를 이용해 반경 내 가맹점 id를 먼저 필터링한다.데이터 적재 및 정합성 보장
관리자 전용 동기화 api 생성
수동으로 전체 데이터를 동기화할 수 있는 관리자 전용 api
🚀 효과
Redis는 위경도를 GeoHash라는 52비트 정수로 변환하여 이미 정렬된 상태로 보관합니다. 검색 시 특정 범위의 숫자들만 뽑아내기 때문에 연산 부하가 거의 없습니다. 기존 방식은 사용자가 지도를 움직일 때마다 db에서 연산을 수행해야 했습니다. Redis에는 아이디와 위경도만 저장하며 CPU 사용을 거의 하지 않습니다.
그래서 기존 방식 대비 응답 속도가 약 5배정도 빨라졌습니다. 리스트는 여전히 Bounding Box + 인덱스 방식을, 지도는 redis geospatial을 사용하는데 지도 부분 API는 속도가 많이 개선된 것을 볼 수 있습니다. 리스트 부분은 그냥 두었는데, 지도만큼 api 호출이 되지 않는 것 같아서 !! 조금 더 고민해보고 개선할 수 있으면 할 수 있을 것 같아요 !

🔗 관련 이슈 / JIRA
✅ 테스트
요 3가지가 다 잘 되는지 확인 부탁드립니당... !!
/api/v1/cache/store-locations를 호출하여 db에 있는 데이터가 redis에 가맹점의 id, 위경도가 들어갔는지 확인/api/v1/store/mapapi 호출을 통해 호출이 잘 되는지 확인🙏 기타 사항
나 db에 이번에 모니터링 회의에서 업데이트가 필요한 지역(인천, 부산)들은 다 db에 넣었엉 !! 대구 지역 쭉 한 번 해줫 !! 👍🏻
📝 참고 문서
https://wonyong-jang.github.io/bigdata/2021/05/12/BigData-Redis-Geospatial.html