Monew 프로젝트: 뉴스기사 목록조회 PostgreSQL 복합 인덱스로 뉴스 목록 조회 성능 개선

저번에 조회 쿼리 구조 개선 이후 NAVER 뉴스기사 45,000건에 대해 실행 시간은 약 20ms 수준까지 감소했다.

단순 API 응답 속도만 보면 충분히 빠른 수준이라고 볼 수 있다.

 

Seq Scan on news_articles
→ Sort
→ Limit 11

하지만 실행 계획을 보면 최종적으로는 11개의 기사만 필요하지만 DB는 여전히 news_artilces 전체를 스캔한 뒤 정렬을 수행하고 있다.

특히 메인 화면 뉴스 목록 조회는 서비스에서 가장 자주 호출될 가능성이 높은 API였기때문에 단일 요청의 실행 시간뿐 아니라 반복적인 DB 부하까지 함께 고려할 필요가 있었다.

 

따라서 전체 스캔 자체를 줄이고, 정렬 비용을 제거하고 limit 11개를 더 효율적으로 가져오기위해

"복합 인덱스"를 추가했다.

---

Redis의 고려?

메인 목록 조회는 캐시적용도 고려할 수 있는 구조이다.

이번 개선에서는 먼저 데이터베이스 조회 구조와 실행 계획자체를 개선하는 방향을 선택하였다.

 

1. DB단에서 개선 여지가 남아있다.

병목은 불필요한 JOIN, GROUP BY, 정렬 비용, Seq Scan이고 캐시 이전에 DB가 비효율적으로 동작하는 원인을 먼저 해결하는게 우선이라고 생각했다.

 

2. 메인 조회 패턴이 고정적이다.

WHERE source = 'NAVER'
AND is_deleted = false
ORDER BY published_at DESC, created_at DESC
LIMIT 11

WHERE + ORDER BY 패턴이 명확해서 복합 인덱스를 통해 DB 레벨에서 충분히 최적화 가능하다고 생각했다.

 

3. Redis의 운영 복잡도..?

• 아직 Redis에 대해 깊이있는 이해가 부족하다.
• 캐시 만료 전략, 데이터 동기화, 장애대응등... 운영 고려사항이 필요하다.

---

인덱스 설계

CREATE INDEX idx_news_articles_source_deleted_published_created
ON news_articles (
  source,
  is_deleted,
  published_at DESC,
  created_at DESC
);

source와 is_deleted는 where 필터고

published_at은 메인 정렬, created_at은 보조정렬이라서 인덱스를 다음과 같이 설계하였다.

 

---

인덱스 설계 전 Seq Scan -> Sort -> Limit : 약 22ms

인덱스 후: 0.08ms

99.64% 감소 275배....

 

 

1. 인덱스는 WHERE만이 아니라 ORDER BY까지 고려해야 한다.
2. LIMIT 쿼리는 정렬 순서까지 맞는 복합 인덱스에서 효과가 크다.
3. 실행계획에서 Seq Scan -> Index Scan 변화 여부를 반드시 확인해야 한다.
4. 실제 메인 조회 패턴 기준으로 인덱스를 설계해야 한다.