RDB vs Elasticsearch 검색 성능 비교

상품 조회 시 트래픽 증가로 성능 저하문제가 발생했다.

상품데이터는 100만건, 상품 검색 조회 시 JPA QueryDsl을 사용하여 검색 조회를 하였고 소요시간은 꽤나 걸렸다.

 

1. RDB 상품 검색 목록 조회 평균 응답시간

 

 

• RDB 정상 범위 데이터 4건의 평균 소요 시간
  • 2897 + 2639 + 2663 + 2624  = 10823
• 평균 소요 시간
  • 10,823 ÷ 4건 
  • 약 2.7초

 

1.1 Full-Text Index 적용

Full-Text Index를 적용하고 기존 Like 문을 변경했다.

WHERE  	 P.NAME LIKE '%니트%'

WHERE  MATCH(P.NAME) AGAINST ('니트');

 

EXPLAIN ANALYZE를 실행해보니 예상대로 Full-text index가 성공적으로 적용되어 소요시간이 줄어든것을 확인

그러나 조회되는 rows=0 

 

무슨 문제일까 알아보니

기본적으로 MySQL은 3글자 미만의 단어는 인덱싱하지 않아서 한글의 경우 2바이트 문자이므로 이 설정의 영향을 받을 수 있다.

 

 

검색조건을 니트 -> 알파카 3글자로 변경하니 잘 반환된다.

사용자가 한글을 무조건 3글자 이상 검색하지는 않을것이다. 다른 방법을 적용해보자

 

2. 엘라스틱서치 적용

2.1 데이터 동기화 방법 고민

동기 처리

1. 하나의 트랜잭션안에서 DB와 엘라스틱 저장해서 실시간으로 데이터 저장

 

동기 처리 고민

1. 브랜드에서 상품 등록 시 얼마나 트래픽이 발생할까?

2. 실시간으로 처리가 필요한가?

3. 엘라스틱서치 동기화 장애로 인해 상품노출이 누락된어 보여지지 않고 있다면? 차라리 동기식으로 처리하여 등록 시 오류가 있다는걸 알면 좋지 않을까 -> 빠르게 문의가능

 

비동기 처리

1. logstash 사용하여 주기적으로 엘라스틱서치에 데이터 동기화

2. DB저장 후 이벤트 발행

 

비동기 처리 고민

1. 브랜드에서 대량의 상품을 한번에 등록하는 경우가 많다.

2. 또 이미지와 상세설명 등 데이터가 크다.

3. 등록 즉시 검색될 필요는 있으나 약간의 지연은 큰 문제가 아닐 수 있다?

4. 대부분 logstash 사용하여 주기적으로 DB와 엘라스틱서치 데이터 동기화를 하는것으로 보인다.

 

 

결론

보편적으로 많이 사용하는 Logstash 파이프라인 방식으로 데이터 동기화 진행

상품검색시 조회되는 쿼리 데이터를 엘라스틱서치 index로 설정

 

 

동기화 문제 해결

1. Logstash와 MySQL이 서로 다른 도커 컨테이너에서 실행 되어 Logstash가 MySQL 주소 찾지 못하는 문제
   • 하나의 docker-compose.yml에서 실행으로 해결
2. RDB와 엘라스틱서치 중복 데이터 제거
   • Logstash 파이프라인에서 document_id => "%{product_id}" 추가하여 해결
3. sql_last_value를 활용한 데이터 변경 추적
   • Logstash 파이프라인의 sql_last_value값을 created_at, updated_at과 비교하여 생성, 수정된 데이터 변경 감지

 

 

 

2.2 Elasticsearch 상품 검색 목록 조회 평균 응답시간

 

• Elasticsearch 정상 범위 데이터 4건의 평균 소요 시간 
  • 100 + 58 + 47 + 49 = 254 ms
• 평균 소요 시간
  • 254 ÷ 4건
  • 약 0.06초 (63.5ms)

 

3. 검색 성능 개선 결과

RDB vs Elasticsearch

• RDB: 약 2.7초 (2,705ms) 
• Elasticsearch: 약 0.06초 (63.5ms)
• Elasticsearch가 RDB보다 약 42.6배 더 빠른 검색 속도를 보여줌