PostgreSQL의 LIKE '%...' 및 OFFSET 성능 저하, Elasticsearch 도입으로 22초 → 2초 개선기

핵심 기술

본 콘텐츠는 PostgreSQL에서 LIKE '%검색어%' 패턴과 OFFSET으로 인해 발생하는 극심한 성능 저하 문제를 진단하고, 이를 해결하기 위해 Elasticsearch를 도입한 실제 경험을 공유합니다. 대용량 데이터 처리 시 발생하는 병목 현상과 해결 과정을 상세히 다룹니다.

기술적 세부사항

• 문제 정의: 2,260만 건의 대용량 데이터에서 LIKE '%검색어%'와 OFFSET 조합으로 인한 마지막 페이지 조회 시 20초 이상 소요되는 성능 저하.
• 원인 분석:
  • LIKE '%검색어%': PostgreSQL의 B-Tree 인덱스가 무용지물이 되어 전체 테이블 스캔(Full Table Scan) 발생.
  • OFFSET N: N개의 데이터를 읽고 버리는 비효율적인 처리로 인한 성능 저하.
• 해결책: Elasticsearch 도입을 통한 하이브리드 아키텍처 설계.
  • 아키텍처: 마스터 데이터는 PostgreSQL에서 관리, 검색 기능은 Elasticsearch 전담.
  • 데이터 모델링: PostgreSQL 테이블 구조를 Elasticsearch Document로 매핑 (Spring Data Elasticsearch 활용).
  • 데이터 마이그레이션: 50,000건씩 배치 처리 방식으로 2,260만 건 데이터 마이그레이션.
  • 검색 쿼리 최적화: PostgreSQL의 LIKE '%...%'를 Elasticsearch의 wildcard 쿼리로 대체.
  • Deep Pagination 해결: Elasticsearch max_result_window 설정으로 1000만 건까지 페이지 번호 확장.
• 결과: 검색 조건 + 마지막 페이지 조회 시 22.4초 → 2.9초로 86% 성능 개선 (거의 일정한 응답 속도 유지).
• 프로파일링: Elasticsearch 쿼리 실행 시간 0.012초 (기존 대비 1600배 속도 향상).

개발 임팩트

• 사용자 경험의 극적인 개선 및 시스템 응답 속도 향상.
• 잦은 Full Scan으로 인한 데이터베이스 서버 부하 감소.
• RDBMS와 검색 엔진의 역할 분담을 통한 시스템 효율성 증대.
• 문제 해결 과정에서 얻은 도구에 대한 깊은 이해 및 점진적 개선의 중요성 학습.

커뮤니티 반응

해당 콘텐츠에는 커뮤니티 반응에 대한 직접적인 언급은 없습니다.