캐시를 확인하는 것도 결국 약간의 지연이다.
- Cache Hit : 캐시에 접근했을 때 찾고 있는 데이터가 있는 경우
- Cache Miss : 캐시에 접근했을 때 찾고 있는 데이터가 없는 경우
- Eviction Policy : 캐시에 공간이 부족할 때 어떻게 공간을 확보할 지
- Caching Strategy : 언제 캐시에 데이터를 저장하고, 언제 캐시를 확인하는 지에 대한 전략
대표적 Caching Strategy
1. Cache-Aside => Lazy loading
✔️ 특징
- 조회가 목적인 경우!
- 옆에 캐시를 두고 진행하자.
- 데이터가 캐시에 없었으면 추가를 하고, 있으면 해당하는 데이터를 반환해줌.
- 첫번째 사용자는 1~3번 다 거쳐 수행.
- 두번째 요청부터는 캐시에서 처리! -> DB까진 안감.
✔️ 단점
- 첫 요청은 느림 (1~3번을 다 거쳐야 하기 때문)
- 최신 보장이 안됨. 캐시에 데이터가 들어간 후 POST로 DB에 새로운 데이터가 들어간 경우 모름!
-> 적당한 시점마다 캐시를 비워서 새로운 데이터 업데이트 시켜야 함.
2. Write-Through
✔️ 특징
- 항상 최신 데이터 유지
✔️ 단점
- 새로운 데이터가 많이 사용되는 데이터라는 보장이 없음.
- 자주 사용하지 않는 데이터도 캐시에 저장
- 무조건 캐시에 거치기 때문에 조금 오래 걸린다.
3. Write-Behind
✔️ 특징
- 캐시에 데이터 잔뜩 저장
- 캐시의 사이즈가 쌓이면 DB 원본에 한번씩 반영
- 데이터베이스에 걸리는 부하가 적다.
100개의 INSERT문보다는 1개의 INSERT문이 부하가 더 적기 때문
✔️ 단점
- 캐시! 원본 적용 전에 데이터가 유실될 수 있음
원본에 반영 전에 캐시가 사라진다면..?...??????....??????????
때문에 인메모리 데이터베이스도 클러스터로 구성해서 여러 컴퓨터에 걸쳐 나눠서 저장하기도 함.
례코드