PostgreSQL 캐싱: 기본 동작과 추가 캐시의 선택 기준

PostgreSQL은 데이터 페이지와 실행 계획은 캐싱하지만 쿼리 결과는 저장하지 않음. 데이터가 메모리에 있어도 같은 조회를 반복하면 결과를 만드는 계산은 다시 수행함 캐시 적중률이 높아도 CPU는 포화될 수 있음. 디스크에서 데이터를 읽느라 느린지, 같은 쿼리를 너무 많이 실행하는지가 캐시 선택의 출발점임 반복되는 집계에는 구체화 뷰, 자주 조회하는 결과에는 Redis 같은 애플리케이션 캐시나 프록시 캐시를 활용할 수 있으며, 갱신 비용과 관리 방식이 서로 다름 Readyset과 PgCache는 DB의 변경 내역을 받아 캐시를 갱신하거나 무효화해 애플리케이션의 부담을 줄이지만, 변경 사항이 반영되기까지 지연이 생길 수 있음 반복 조회가 적거나 쓰기가 많으면 캐시 효과가 작고 관리할 것만 늘어날 수 있음. 캐시를 추가하기 전에 인덱스와 쿼리부터 점검하는 편이 저렴하고 간단함 데이터 페이지 캐시와 OS 캐시 PostgreSQL은 테이블과 인덱스를 8KB 페이지로 저장하고, 최근 접근한 페이지를 shared_buffers에 보관해 반복 접근 시 디스크 읽기를 피함 shared_buffers의 기본값은 128MB이며, 직접 운영하는 전용 데이터베이스 서버에서는 시스템 RAM의 25%가 일반적인 시작점임 변경하려면 재시작이 필요함 RDS, Cloud SQL 등 관리형 서비스는 이미 합리적인 값으로 설정하므로 직접 운영하는 서버에 해당하는 조언임 OS 캐시와 데이터가 중복되므로 메모리를 늘린 만큼 효과가 커지지는 않으며, 보통 RAM의 40%를 넘게 할당할 가치는 적음 페이지 교체에는 LRU를 근사하는 clock-sweep 알고리듬을 사용함 페이지별 사용 횟수는 최대 5이며, 순회할 때 감소해 자주 쓰는 페이지는 남고 나머지는 제거됨 shared_buffers의 4분의 1보다 큰 테이블을 순차 스캔하면 약 256KB의 작은 링 버퍼를 사용해 자주 쓰는 페이지가 밀려나는 것을 방지함 pg_prewarm으로 시작 후 버퍼 풀을 자동으로 다시 채울 수 있음 PostgreSQL은 버퍼드 I/O를 사용하므로 shared_buffers에 없는 페이지도 OS 페이지 캐시에서 읽을 수 있음 PostgreSQL 통계의 ‘디스크 읽기’가 실제 디스크 접근이 아니라 RAM 접근일 수 있음 effective_cache_size 는 메모리 할당 설정이 아니라 실행 계획 수립용 힌트임 인덱스 스캔이 활용할 수 있는 shared_buffers와...