데이터 베이스 캐싱 전략은 데이터 및 데이터 액세스 패턴에 따라 달라집니다.
오늘 공부할 것은 다양한 캐싱 전략중 Look aside Cache와 Read Through에 대해서 알아보도록 하겠습니다.
https://colevelup.tistory.com/6
캐싱 전략
Look aside Cache(Cache aside)
- Data에 접근하는 Client는 우선 Cache에 원하는 Data가 있는지 체크한다
- Cache에 원하는 Data가 있다면 Cache hit이고 Cache는 Client에게 Data를 Return 해준다.
- Cache에서 원하는 Data를 못찾는 경우 cache miss가 되며, Client는 DB에 쿼리를 날려서 데이터를 읽고 Client에 반환한다.
동일한 후속처리에 대해서 앞으로 cache hint가 발생하도록 캐시에 해당 반환한 데이터를 저장한다.
특징
- 읽기에 상당히 적합하다.
- 반복적인 호출에 적합하다.
- 캐시 시스템자체에 장애가 생길 경우를 대비하여 구성할 수 있다.
ex) Redis가 죽더라도 DB에서 데이터를 호출해서 가져올 수 있다.- But Redis와 같은 Cache에 Connection이 상당히 많았다면 Redis가 죽고 난 뒤 DB에 일시적으로 Connection이 상당히 발생하므로 DB에 부하가 올 수 있다.
- 정합성 문제 발생
- Cache Store 와 Data Store 가 가지고 있는 데이터가 서로 다를 수 있으며 정합성 문제가 생긴다.
- 초기 조회시 무조건 Data Store를 호출해야 하므로 단건 호출 빈도가 높은 서비스에 부적합하다.
- 읽기가 많은경우 상당히 적합하다.
초기에 데이터가 DB에만 저장되어있어 처음에 cache miss가 많아지기 때문에 성능 저하의 가능성이 있다.
미리 DB에서 캐시로 데이터를 넣어주는 작업이 필요하고 이를 Cache Warming이라고 한다.
Read Through
- 캐시는 데이터베이스와 인라인으로 배치되며 Cache Miss가 있는 경우 DB에서 Miss 된 데이터를 로드하고 Cache를 채우고 Application으로 반환한다.
- Cache-aside, Read-through 전략은 처음 Read 하는 경우에만 data load를 lazy 하게 진행함.
특징
- 읽기가 많은 워크 로드에 적합하다.
- Read Through 방식은 Cache Aside 방식과 비슷하지만 차이점이 존재함
- 차이점
- cache-aside에서는, Client은 데이터베이스에서 데이터를 가져오고 캐시를 채우는 역할을 함. read-through에서는 위에 로직이 라이브러리가 지원하거나 stand alone 형식의 cache provider가 지원해준다.
위 예시에서는 Database가 직접 캐시를 채움 - cache-aside와는 다르게, read-through에서 DB에서 직접 Cache를 채우기 때문에 cache의 데이터 모델은 DB의 데이터 모델과 다를 수가 없다.
- cache-aside에서는, Client은 데이터베이스에서 데이터를 가져오고 캐시를 채우는 역할을 함. read-through에서는 위에 로직이 라이브러리가 지원하거나 stand alone 형식의 cache provider가 지원해준다.
- 차이점
- Read-Through는 동일한 데이터가 여러 번 요청될 때 읽기가 많은 워크로드에 적합하다.
참조
https://velog.io/@hwaya2828/Redis-%EC%BA%90%EC%8B%9C-%EC%A0%84%EB%9E%B5
https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/
반응형
'DataBase > Cache' 카테고리의 다른 글
cash말고! 데이터 베이스 캐시(Database Cache) 활용 전략(2) (0) | 2022.11.20 |
---|---|
캐싱이란? (0) | 2022.11.19 |
댓글