Today I Learned ...
오늘도 어김없이 V3 고도화 작업을 진행했다!
🖥️ 번쩍 팀프로젝트 #14
오늘은 레디스 기반 위치 조회 작업을 시작했다!
레디스에서는 Geospatial이라는 이름으로 위치를 등록하고, 조회할 수 있는 서비스를 제공한다.
Redis Zset 형식을 이용해 이름과 좌표를 넣으면 좌표를 위치 데이터로 바꾸어 저장하고, 내가 원하는 기준 좌표와 조회하고자 하는 거리를 입력하면, 해당 거리 안에 있는 데이터들의 이름을 반환해준다.
이 내용 또한 스프링에서 간단하게 사용할 수 있도록 지원해주는데,
geoOperations.add(CACHE_GEO_KEY, point, name); 이렇게 위치를 레디스에 등록할 수 있고,
GeoResults<GeoLocation<String>> geoResults = redisTemplate.opsForGeo().radius(CACHE_GEO_KEY, searchArea, args); 이렇게 기준점을 통해 조회한 결과를 받을 수도 있다.
사실 Geospatial 자체에서 데이터를 삭제하는 기능을 지원하지는 않지만, Zset 형식으로 데이터를 저장하기 때문에 redisTemplate.opsForZSet().remove(CACHE_GEO_KEY, name); 이렇게 데이터를 삭제할 수도 있었다.
이걸 기반으로 일단 모임이 생성될 때 레디스에 위치 데이터를 등록하고, 모임이 수정된다면 갱신을, 삭제된다면 레디스에서도 삭제를 진행했다.
여기에 추가로 모임 상태가 COMPLETED로 변경될 때도 레디스에서 삭제해보려고 한다.
하지만, 레디스를 통해 조회할 때는 앞서 저장한 이름 값만 받아올 수 있다는 한계가 있다.
우리 서비스에서는 목록 조회 시, 모임의 일부 내용들이 함께 반환되어야 하는데, 레디스에서 그런 내용들까지 처리해주지는 못한다.
그래서 일단 레디스를 통해 1차적으로 필터링을 진행하고, 반환받은 리스트 결과를 중심으로 DB에서 조회하려고 한다.
SELECT *
FROM meetings
WHERE MBRContains(ST_LINESTRINGFROMTEXT('LINESTRING(37.598466 126.892119, 37.508533 126.778680)', 4326), meetings.point);기존에는 이렇게 원하는 BoundingBox를 만들어서 조회했다면,
SELECT *
FROM meetings
WHERE meetings.id in (4928, 1847, ...);레디스를 사용하면 이렇게 조회할 수 있게 되는 것이다.
레디스를 사용할 때는 항상 빠르지만 비용이 증가한다는 단점이 있는데, 지금 상황에서는 사실 레디스가 훨씬 빠르다는 확신이 생기지 않는다.
그래서 어디까지 레디스를 도입해서 사용해야할지에 대한 고민이 생기고 있다.
그래서 이 부분을 확실히 하기 위해 내일은 레디스를 사용할 때와 DB에서 직접 조회할 때의 성능 차이를 비교 분석해보려고 한다.
우리 팀이 작성한 코드는 깃허브를 통해 업로드해두었다.
GitHub 보러가기
🙃 오늘의 느낀점
사실 오늘 중간에 '위치 기반 서비스'라는 색에 대해 피드백을 받았고, 이 부분에 대해 수정하느라.. 정작 위치 조회 기능을 끝내지 못했다.
앞으로 해야할 것들과 하고 싶은 것들이 정말 많은데.. 내일은 정말 위치 조회 기능을 끝내고, 다음 단계인 알림, SSE를 시작해봐야겠다.
