캐시를 옆에 두고 필요할 때만 데이터를 캐시에 로드하는 전략이다.
- 처음 사용자가 요청했을 때, 캐시 스토리지에는 아무 데이터도 없는 상황
- 애플리케이션은 먼저 캐시 저장소에 데이터가 있는지 조회한다. 하지만 데이터가 없다.
- 애플리케이션은 Contents DB에서 데이터를 조회하고 사용자에게 제공한다.
- 애플리케이션은 Contents DB에서 가져왔던 데이터를 캐시 저장소에 저장한다.
- 다음 사용자가 요청했을 때는 이미 캐시 저장소에 데이터가 있는 상황
- 애플리케이션은 먼저 캐시 저장소에 데이터가 있는지 조회한다. 캐시 저장소에 저장되어있는 데이터를 제공한다.
장점
- 읽기가 많은 워크로드에 적합하다.
- 인메모리 데이터베이스인 Redis가 가장 많이 쓰이며 캐시 분리를 사용하였기 때문에 캐시 오류에 대해 탄력적이다. 즉, 캐시 클러스터가 다운되어도 시스템 전체의 오류로 가지 않는다.
- 캐시를 분리하여 데이터베이스의 모델과 다를 수 있다.
단점
- 캐시에 없는 데이터인 경우, 더 오랜시간이 걸리게 된다.
- 캐시가 최신 데이터를 가지고 있는가? (동기화 문제가 중요하게 된다.)
Read Through 캐시는 데이터베이스와 일렬로 배치된다. 캐시 미스가 발생하면 데이터베이스에서 누락된 데이터를 로드하고 캐시를 채우고 이를 애플리케이션에 반환한다.
캐시를 제외하고 읽기를 통한 전략 모두 데이터를 느리게 로드한다. 즉, 처음 읽을 때만 데이터를 로드한다.
Cache Aside와의 차이점은 애플리케이션이 캐시를 채우는 역할을 하느냐 마느냐에 따라에 있다.
장점
- 읽기가 많은 워크로드에 적합하다.
단점
- 데이터베이스의 모델과 다를 수 없다.
- 데이터를 처음 요청하면 항상 캐시 누락이 발생한다. 또한 그에 따른 패널티가 발생한다. 해결 방법으로 개발자가 직접 쿼리를 실행하여 첫 요청 캐시 미스를 나지 않게 하는 방법을 사용하기도 한다.
Write Through 캐시는 Read Through와 반대로 구성된다.
데이터를 데이터베이스에 작성할 때마다 캐시에 데이터를 추가하거나 업데이트한다. 이로 인해 캐시의 데이터는 항상 최신 상태로 유지할 수 있지만, 여러가지 단점이 있다.
장점
- 항상 동기화 되어있다.
단점
- 쓰지 않는 데이터도 캐시에 저장되기 때문에 리소스가 낭비된다.
- 쓰기 지연 시간이 증가한다.
여러 장점과 단점이 있지만, Write Through 캐시 Read Through 캐시를 함께 사용하면 Read Through 캐시의 모든 이점을 얻을 수 있으며 데이터 일관성 보장도 얻을 수 있다.
데이터는 데이터베이스에 직접 기록되며, 읽은 데이터만 캐시에 저장된다.
Write Around는 Read Through와 결합될 수 있으며, Cache-Aside와도 결합될 수 있다. 데이터가 한 번 쓰여지고, 덜 자주 읽히거나 읽지 않는 상황에서 좋은 성능을 제공한다.
에를들어 실시간 로그 또는 채팅방 메시지가 있다.
애플리케이션은 즉시 확인하는 캐시에 먼저 데이터를 쓰고, 약간의 지연 후에 데이터를 다시 데이터베이스에 쓴다.
장점
- 쓰기가 많은 워크로드에 적합하다.
- Read Through와 결합하여 가장 최근에 업데이트되고 액세스 된 데이터를 항상 캐시에서 사용할 수 있는 혼합 워크로드에 적합하다.
- 데이터베이스에 대한 전체 쓰기를 줄일 수 있어, 해당 비용을 감소할 수 있다.
단점
- 위와 반대의 경우 적합하지 않습니다.
- 일부 개발하는 Cache Aside와 Write Back 모두 Redis를 사용하는데 가장 큰 단점은 캐시에서 오류가 발생하면 데이터를 영구 소실 하는 것이다.