캐시 패턴의 경우 크게 3가지가 있습니다.
- No caching
- Cache-Aside
- Cache-Through
위 세가지에 대해 간단히 정리하고자 합니다.
No Caching
제목 그대로 캐시를 적용하지 않는 일반적인 형태입니다.
애플리케이션에서 직접 DB로 요청하는 방식이며 별도 캐시한 내역이 없으므로 매번 DB와 통신이 필요합니다.
또한, 부하가 유발되는 SQL이 지속 수행되면 DB의 I/O에 영향을 주게되어 전체적으로 성능 저하가 발생할 수 있습니다.
(출처 : https://cla9.tistory.com/100)
Cache-Aside
애플리케이션에서 캐시를 직접 사용합니다.
즉, 애플리케이션 코드가 DB가 아닌 캐시를 먼저 탐색하고 만약 캐시가 찾던 데이터가 존재하면 캐시에서 바로 반환시켜 줍니다.
이후에 동일한 요청을 반복하면, 캐시에 데이터가 존재(cache hit)한다면 DB 조회없이 바로 데이터를 전달 받을 수 있습니다.
하지만, 캐시에 데이터가 존재하지 않는다면(cache miss) DB에서 데이터를 조회한 후 캐시에 다시 적재를 진행합니다.
Pseudocode for reading values
v = cache.get(k)
if (v == null) {
v = sor.get(k)
cache.put(k, v)
}Pseudocode for writing values
v = newV
sor.put(k, v)
cache.put(k, v)
(출처 : https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/)
Cache-Through
cache miss가 발생했을 때 애플리케이션이 아닌 캐시에서 데이터를 처리한 다음 애플리케이션에 전달합니다.
즉, Cache-Aside에서는 데이터 처리에 대한 책임이 애플리케이션에 있었다면 Cache-Through는 캐시에게 위임합니다.
Read-Through
애플리케이션에서 데이터 요청 시 Cache hit이면 캐시에서 데이터를 전달해주고 cache miss이면 캐시에서 DB를 조회하여 캐시 내에 적재합니다.
(출처 : https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/)
Write-Through
애플리케이션에서 데이터 쓰기 요청 시, 애플리케이션은 쓰기 요청만 캐시로 전달 한 뒤 캐시에서 DB로 데이터 쓰기 요청을 하여 DB에 적재한다.
(출처 : https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/)
Write-Behind
애플리케이션에서 데이터 쓰기 요청 시, 캐시에 데이터를 반영한 다음 일정시간 비동기적으로 캐시에서 DB로 데이터 적재를 요청합니다.
Write-Behind의 경우 애플리케이션에서 데이터 쓰기에 대한 성능은 향상시킬 수 있지만 캐시가 다운될 경우 유실 가능성이 존재합닏.
(출처 : https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/)
참고
