DB설계 전략

1. 캐시 읽기 전략: Look-aside vs Read-through

Look-aside 전략

작동 방식:

애플리케이션이 먼저 캐시(Redis)에서 데이터를 조회.

캐시에 데이터가 없는 경우(PostgreSQL에서 조회) 필요한 데이터를 DB에서 가져오고, 가져온 데이터를 캐시에 저장.

이 프로젝트와의 적합성:

크롤링된 모든 데이터의 캐싱:

이 프로젝트는 챗봇이 크롤링 데이터를 처리한 후 Redis와 PostgreSQL에 모든 데이터를 저장합니다.

사용자 요청 시 Redis에서 우선 데이터를 조회하고, 캐시에 없는 경우에만 PostgreSQL에서 데이터를 가져옵니다.

효율적인 사용자 요청 처리:

사용자 요청 시 캐시를 먼저 조회하여 빠르게 데이터를 제공하며, Redis에서 데이터를 찾지 못할 경우 PostgreSQL을 조회하여 필요한 데이터를 가져옵니다.

데이터 갱신과 유연성:

Redis는 크롤링 후 모든 데이터를 저장하되 TTL(1일)을 설정하여 최신 데이터를 유지합니다.

사용자 요청 시 필요한 데이터를 동적으로 관리할 수 있어 Look-aside 전략의 유연성을 유지합니다.

Read-through 전략과의 비교

왜 Read-through를 선택하지 않았는가?:

자동 캐싱 오버헤드: Read-through는 모든 데이터를 캐시에 자동으로 저장하므로, 요청되지 않은 데이터도 캐시를 차지해 메모리 낭비가 발생할 수 있습니다.

효율성 부족: 주기적으로 크롤링된 데이터 중 일부만 사용자 요청으로 활용되므로, Read-through는 캐시에 필요 이상으로 많은 데이터를 저장하게 됩니다.

실시간 맞춤형 처리 부족: 이 프로젝트는 사용자 요청 시점에 동적으로 데이터를 관리하는 것이 중요하므로 Look-aside가 더 적합합니다.

2. 캐시 쓰기 전략: Write-through vs Write-around vs Write-back

Write-through 전략

작동 방식:

데이터를 PostgreSQL과 Redis에 동시에 저장.

업데이트나 생성 작업 시 데이터 일관성을 유지.

이 프로젝트와의 적합성:

데이터 일관성 보장:

Redis와 PostgreSQL에 데이터를 동시에 쓰므로, 캐시와 DB의 데이터가 항상 동기화됩니다.

크롤링 데이터를 챗봇이 처리한 즉시 Redis와 PostgreSQL에 저장하여 실시간 요청 처리에서 최신 데이터를 제공합니다.

단순한 캐시 관리:

캐시와 DB를 동시에 업데이트하기 때문에 추가적인 캐시 무효화(invalidation) 로직이 필요 없습니다.

실시간 데이터 업데이트:

크롤링한 데이터와 챗봇 처리 결과가 Redis와 PostgreSQL에 즉시 반영되므로, 사용자 요청 시 데이터를 바로 제공할 수 있습니다.

Write-around 전략과의 비교

왜 Write-around를 선택하지 않았는가?:

캐시 미스 증가: Write-around는 캐시에 데이터를 저장하지 않고 DB에만 저장하므로, 사용자가 새로운 데이터를 요청할 때 캐시 미스가 발생하고, PostgreSQL에 불필요한 부하를 줄 수 있습니다.

실시간 데이터 제공 한계: 새로운 데이터를 캐시에 저장하지 않기 때문에 실시간 요청 처리에서 Redis의 장점을 살릴 수 없습니다.

Write-back 전략과의 비교

왜 Write-back을 선택하지 않았는가?:

데이터 손실 위험: Write-back은 캐시에만 데이터를 저장하고 나중에 DB에 반영하므로, Redis 장애 시 데이터 손실 가능성이 있습니다.

복잡한 동기화: 캐시와 DB 간의 동기화 로직을 추가로 구현해야 하므로 관리 복잡성이 증가합니다.

프로젝트의 실시간 요구사항 미충족: Write-back은 데이터베이스에 반영이 지연되기 때문에, 최신 데이터를 제공해야 하는 실시간 서비스에는 부적합합니다.