feat: 맛집 상세 정보 API 고도화 작업

[jooda00]

🎟️ 관련 이슈

Fixes #38

👩‍💻 구현 내용

• RedisConfig 파일 작성
• Point타입 역직렬화 정적 클래스 및 메소드 작성
• 리뷰 개수 10개 이상인 맛집 데이터 redis에 저장(24시간 동안 유지)

💬 코멘트

1. Point 객체를 직렬화, 역직렬화 하고 redis에 저장, 반환 시 반영하는 부분을 개발 시간의 90% 정도 할애한 것 같네요..
   직렬화는 도은님께서 작성해주신 클래스 사용했습니다!(감사해요🤗)

✅ 직렬화
캐시에 저장할 때 Point객체를 Json으로 바꿔주어야 했습니다. 그래서 RedisConfig파일에서

@Bean
public ObjectMapper objectMapper() {
        ObjectMapper mapper = new ObjectMapper();
        SimpleModule module = new SimpleModule();
        module.addSerializer(Point.class, new GeoUtils.PointSerializer());
        mapper.registerModule(module);
        return mapper;
}

objectMapper를 사용해서 Point객체를 직렬화하는 클래스를 넣어주고 반영했습니다.

✅ 역직렬화
캐시에 저장된 Restaurant타입의 맛집 데이터를 가져올 때 Point객체를 역직렬화 해주어야 했습니다.

/**
* JSON을 Point 객체로 역직렬화하는 메서드 (redis에서 데이터를 가져올 때 필요)
**/
public static class PointDeserializer extends JsonDeserializer<Point> {
// 코드가 길어서 클래스만 첨부했습니다.
// 코드는 PointDeserializer 클래스에서 보실 수 있어요!
}

@Column(nullable = false, columnDefinition = "GEOMETRY")
@JsonDeserialize(using = GeoUtils.PointDeserializer.class)
private Point location;

@JsonDeserialize 어노테이션을 사용해서 위에서 설정해준 역직렬화 클래스를 적용해 주었습니다.

2. getRestaurantDetails() 메소드에 캐싱 처리를 주석으로 작성할까 하다가 제가 원래 주석을 잘 안 적기도 하고 + 작업하면서 쉽게 확인할 수 있게 하려고 log.info(~~~)로 작성했습니다!

3. 캐시를 사용했을 때 성능이 향상된다는 것을 테스트하기 위한 테스트 코드는 개인 과제 하면서 같이 진행해야 할 것 같습니다..!😥

💭 고려한 점

1. 어떤 기준으로 캐시에 저장할까 하다가 리뷰 개수가 10개 이상인 맛집을 기준으로 저장했습니다. 사실 10이라는 숫자는 큰 의미 없이 정해서.. 혹시 수정이 필요하면 말씀해주세요!
2. 캐시에 저장할 때 TTL을 24시간(하루)로 설정했습니다. 매일 스케쥴러를 돌린다고 알아서 24시간으로 설정했는데 확신을 가지고 한 건 아니라서 피드백 부탁드립니다!
3. Spring Boot Starter Redis를 사용하는 경우, redis를 다룰 때 RedisTemplate과 RedisRepository를 사용한다고 하네요. 뭘 사용할까 하다가 각 작업에 대해 특정 데이터 형식에 맞는 Serializer 및 Deserializer를 구성할 수 있다.라는 글을 보고 RedisTemplate으로 골랐습니다!

[hye-on]

캐시에 저장할 때 TTL을 24시간(하루)로 설정했습니다. 매일 스케쥴러를 돌린다고 알아서 24시간으로 설정했는데 확신을 가지고 한 건 아니라서 피드백 부탁드립니다!

캐싱 교체 알고리즘을 찾아보시면 좋을 것 같아요!
모바일-앱-서비스에서-lru와-lfu를-언제-사용하면-좋을까 을 참고했을 때

타겟 유저에 따라 다르겠지만 저라면 이렇게 할 것 같아요!

1. 타겟 : 직장인 -> LRU (위치가 변하지 않으니까 최근 접근한 곳을 또 접근할것이라고 가정)
2. 타겟 : 놀러 나와서 약속 장소를 잡는 사람 -> LFU (홍대, 성수 등등 유동인구 많은 위치에 가장 많이 접근할 것이라고 가정)

[hye-on]

고생하셨습니다 👍

[jooda00]

🙋‍♀️ 이거 왜 ci 작업이 안되는지 모르겠네요.. 좀 찾아보겠습니다.

[jooda00]

1. 어떤 기준으로 캐시에 저장할까 하다가 리뷰 개수가 10개 이상인 맛집을 기준으로 저장했습니다. 사실 10이라는 숫자는 큰 의미 없이 정해서.. 혹시 수정이 필요하면 말씀해주세요!

캐싱 교체 알고리즘을 찾아보시면 좋을 것 같아요! 모바일-앱-서비스에서-lru와-lfu를-언제-사용하면-좋을까 을 참고했을 때

타겟 유저에 따라 다르겠지만 저라면 이렇게 할 것 같아요!

1. 타겟 : 직장인 -> LRU (위치가 변하지 않으니까 최근 접근한 곳을 또 접근할것이라고 가정)
2. 타겟 : 놀러 나와서 약속 장소를 잡는 사람 -> LFU (홍대, 성수 등등 유동인구 많은 위치에 가장 많이 접근할 것이라고 가정)

우와.. 제가 너무 간단하게 생각한 것 같네요..! 좋은 피드백이랑 자료까지 너무 감사드려요!!👍 디벨롭 할 수 있으면 해보겠습니다😎

[hye-on]

1. 어떤 기준으로 캐시에 저장할까 하다가 리뷰 개수가 10개 이상인 맛집을 기준으로 저장했습니다. 사실 10이라는 숫자는 큰 의미 없이 정해서.. 혹시 수정이 필요하면 말씀해주세요!

캐싱 교체 알고리즘을 찾아보시면 좋을 것 같아요! 모바일-앱-서비스에서-lru와-lfu를-언제-사용하면-좋을까 을 참고했을 때
타겟 유저에 따라 다르겠지만 저라면 이렇게 할 것 같아요!

1. 타겟 : 직장인 -> LRU (위치가 변하지 않으니까 최근 접근한 곳을 또 접근할것이라고 가정)
2. 타겟 : 놀러 나와서 약속 장소를 잡는 사람 -> LFU (홍대, 성수 등등 유동인구 많은 위치에 가장 많이 접근할 것이라고 가정)

우와.. 제가 너무 간단하게 생각한 것 같네요..! 좋은 피드백이랑 자료까지 너무 감사드려요!!👍 디벨롭 할 수 있으면 해보겠습니다😎

2번에 대한 의견이었는데 잘못 적었네요..!

pr 1번에 대한 의견은
다애님이 하신것처럼 리뷰 수로 해도 되고
1번 타겟으로 한다면 최근 접근 한것을 저장해도 되고
2번 타겟으로 한다면 다애님이 하신 것처럼 리뷰 수나 평점으로 할 수 있을 것 같아요!

근데 저도 캐싱을 안해봐서 너무 신뢰하지 마세요 하하 개인적인 의견이었습니다!!

[toughCircle]

👍

[toughCircle]

많은 도움이 되었습니다 👍 고생하셨습니당! :)

[uijin-j]

🙋🏻‍♀️ 저 코드 다 보진 못했는데, 개인적으로 궁금한 점이 있어서 여쭤봅니당!
레스토랑 데이터 수정(예를 들면 리뷰가 추가되어서, 리뷰 평점이 변경됨)으로 캐시 데이터와 DB 데이터가 불일치할 때는 이런 불일치를 일부 허용하는 방식일까요? 아니면 수정 시 캐시 값도 변경을 하나용?

[jooda00]

🙋🏻‍♀️ 저 코드 다 보진 못했는데, 개인적으로 궁금한 점이 있어서 여쭤봅니당! 레스토랑 데이터 수정(예를 들면 리뷰가 추가되어서, 리뷰 평점이 변경됨)으로 캐시 데이터와 DB 데이터가 불일치할 때는 이런 불일치를 일부 허용하는 방식일까요? 아니면 수정 시 캐시 값도 변경을 하나용?

놀랍게도.. 그 부분은 생각도 못했네요.. 테스트할 때 같이 고민해서 진행해 볼게요! 좋은 지적 너무 감사합니다!🤗