본 문서는 Elasticsearch와 PostgreSQL 간의 검색 성능 차이를 정량적으로 분석하기 위해 작성되었다. PostgreSQL 기반 검색 기능을 별도로 구현한 후, 동일 조건 하에서 양 시스템의 성능을 비교·평가하였으며, 이를 통해 Elasticsearch 도입의 실질적 이점 여부를 검토하고자 한다.
본 비교 분석의 공정성을 확보하기 위해, 단순 LIKE 연산자 기반의 문자열 검색 방식은 채택하지 않았다. 해당 방식은 PostgreSQL 및 Elasticsearch 양측 모두에 대해 적절한 성능 평가 기준이 될 수 없다고 판단하였으며, Elasticsearch가 제공하는 검색 품질 수준에 최대한 부합하도록 PostgreSQL 측 검색 기능을 설계하였다.
이를 위해 Nori 형태소 분석기와 PostgreSQL의 tsvector 기능을 활용하여 검색 파이프라인을 구현하였으며, 전체 처리 흐름은 다음과 같다.
먼저, 사용자가 경매 생성(Create) 요청을 전송하면, Spring 서버가 해당 경매의 명칭 및 설명 텍스트를 Nori 형태소 분석기를 통해 어휘소(lexeme) 단위로 분해한다.
이후, 분해된 어휘소를 PostgreSQL의 tsvector 형식으로 변환하여 데이터베이스에 저장한다. 추후 사용자가 검색을 수행할 경우, 검색어 역시 동일한 형태소 분석 과정을 거쳐 어휘소로 분해된 후 tsquery로 변환되며, 이를 기저장된 tsvector와 대조하여 검색 결과를 반환한다.
한편, 형태소 분석을 PostgreSQL 내부가 아닌 Spring 애플리케이션 계층에서 수행하는 구조를 채택하였는데, 이는 AWS RDS PostgreSQL 환경에서 Nori 형태소 분석기의 설치 방법을 확인할 수 없었기 때문이다.
테스트 수행 시점에서 충분한 규모의 경매 데이터를 자체적으로 보유하고 있지 않았으므로, 외부 공개 데이터셋을 활용하였다. 구체적으로는 Wikimedia에서 제공하는 한국어 Wikipedia 덤프 데이터를 사용하였으며, 해당 데이터는 아래 경로에서 확보할 수 있다.
https://dumps.wikimedia.org/other/mediawiki_content_current/kowiki/
상기 데이터셋의 페이지 제목을 경매 명칭으로, 페이지 본문 콘텐츠를 경매 설명으로 각각 매핑하여, 총 약 500,000건의 경매 데이터를 시스템에 적재하였다.
부하 테스트는 K6 도구를 활용하여 수행하였다. 기존 시스템 아키텍처상 검색 요청 시 Elasticsearch를 우선적으로 호출하고, Elasticsearch 장애 발생 시에만 PostgreSQL 기반 검색으로 전환(fallback)하는 구조로 설계되어 있으므로, 양 시스템의 독립적 성능 측정을 위해 별도의 테스트 전용 엔드포인트를 다음과 같이 구성하였다.