• 카테고리

    질문 & 답변
  • 세부 분야

    모바일 앱 개발

  • 해결 여부

    해결됨

캐싱에 대하여 궁금한 점이 있습니다.

23.06.07 10:04 작성 조회수 239

0

상품 리스트나 레스토랑 리스트, 레스토랑 상세 정보 등은 캐싱을 이용해서 데이터를 어느정도 저장시키고 로딩을 빠르게 끝낼 수 있도록 하는 것이라고 이해를 했습니다.

 

그럼 DB에서 값이 바뀐 경우에는 어떻게 해야 되나요?

캐싱된 데이터를 가져오게 되면 옛날 값이 아닌가용?

답변 1

답변을 작성해보세요.

1

안녕하세요!

모든 캐시는 기본적으로 저장되는 순간부터 'stale' 상태입니다. 말씀하신대로 '옛날 값'이 되는거죠.

100% 데이터베이스와 리얼타임으로 싱크를 맞추고 있지 않는한 어떻게 구현하든 모든 캐시에 해당됩니다.

그리고 100% 싱크를 맞추게되면 더이상 캐시가 아니게 되겠죠.

캐시를 사용하는 방식이 프로젝트별로 모두 다른 이유는 stale한 정도와 퍼포먼스의 밸런스를 어떤 비율로 맞춰야 황금비율인지가 프로젝트별로 다르기때문입니다.

말씀하신대로 이미 삭제된 데이터를 캐시에서 계속 들고 있을 수 있지만 이게 크게 중요하지 않은 경우도 많습니다 (단순 로그등)

그리고 절대로 캐싱되면 안되는 값들도 있습니다. (예금 현황, 주식현황등)

대부분의 기능은 이 두 극단적인 수치 사이에 위치하기때문에 캐싱을 얼마나 잘 사용하냐에따라 효율을 크게 개선 할 수 있습니다.

감사합니다!

유제환님의 프로필

유제환

질문자

2023.06.07

답변주셔서 감사합니다!😀😀

그렇다면 pull to refresh 등을 이용해서 DB 와 싱크를 맞추는 것도 하나의 방법인가요?
그렇다면 사용자에게 옛날 값이 보여지는 것은 어쩔 수 없는 것이고 싱크를 맞추는 기준 등은 로직이나 개발문화 혹은 방식에 따라 다른 것으로 이해하면 되는 걸까요?

pull to refresh를 할경우 보통 새로운 데이터를 서버로부터 받아오기때문에 최신 데이터를 가져오는 기법입니다. websocket/socketio 등을 사용해서 서버에서 변경이 있을때마다 변경사항을 리얼타임으로 업데이트 받을수도 있지만 이건 유의미한 리소스 사용일수도 있고 의미 없는 리소스 낭비일수도 있습니다. pull to refresh 같은경우 사용자의 의도를 전달받는 형태지만 polling 같이 프로그램적으로 주기적 업데이트를 할수도 있습니다. 얼마나 정확히, 자주 싱크가 맞아야하는지는 기획에따라 다릅니다.

유제환님의 프로필

유제환

질문자

2023.06.07

아! 넵 이해했습니다

감사합니다! 😀