업체 검색 : NativeQuery에서 QueryDsl 도입 및 FullText를 이용한 성능 테스트까지

[hongxeob]

1. 순수 SQL Like문 vs Full Text (feat. 짧은 검색어, 긴 검색어)

2. QueryDSL (NoOffset) vs Full Text

   ---

1. Like문(No QueryDSL) VS Full Text 쿼리

데이터는 모두 5만건 기준

검색어가 짧은 경우 (떡볶이)

Like문 - 290ms

FullText문 - 411ms

검색어가 긴 경우 (떡볶이가 무지하게 맛있어서 환장하는 집)

Like문 : 278ms

FullText문 : 178ms

1. 전체 텍스트 검색의 복잡성: Full Text Search는 일반적으로 검색 알고리즘이 더 복잡하며, 텍스트 색인을 활용하여 결과를 더 정확하게 산출합니다. 이는 데이터베이스가 추가적인 작업을 수행해야 하므로 LIKE 문보다 더 많은 리소스가 소모될 수 있습니다.
2. 검색어의 길이: 검색어가 짧을수록 Full Text Search의 이점이 줄어듭니다. Full Text Search는 주로 긴 문장이나 단락에서 유용하며, 검색어의 길이가 짧을 경우 일반적인 LIKE 문이 더 효과적일 수 있습니다.
3. 인덱스 구조의 차이: Full Text Search는 전용 인덱스 구조를 사용하며, 이는 일반적인 인덱스와는 다릅니다. 인덱스의 구조가 서로 다르기 때문에 Full Text Search가 항상 더 느리지는 않지만, 특정 상황에서는 그렇게 나타날 수 있다고 판단했습니다.

1차 결론 : 우리 서비스에서는 검색어의 길이가 길지 않을 것(업체명, 음식명 정도)이라고 판단하여 Full Text를 사용하는게 효율적이지 않다고 판단!

---

1. Like문(feat QueryDSL) VS Full Text 쿼리

처음 조회 (lastId=null) : 506ms

조회된 마지막 값의 ID를 넘겨주었을 때 (ex : lastId=10) : 232ms

뒤로 갈수록 시간이 줄어든다?! (No-Offset의 장점?!)

• 50,000건의 데이터중 LastId가 30,000 : 177ms

• 50,000건의 데이터중 LastId가 49,990 : 52ms

NoOffset을 사용하는 간략 이유

• 페이징을 Offset 형태로 할 때에는 페이징 쿼리가 뒤로 갈수록 느려지는데 이유는 결국 앞에서 읽었던 행을 다시 읽어야 하기 때문입니다.
• 예를 들어 offset 10000, limit 20 이라 하면 최종적으로 10,020개의 행을 읽어야 합니다. (10,000부터 20개를 읽어야하니)
• 그리고 이 중 앞의 10,000 개 행을 버리게 됩니다. (실제 필요한건 마지막 20개뿐이니)
• 뒤로 갈수록 버리지만 읽어야 할 행의 개수가 많아 점점 뒤로 갈수록 느려지는 것입니다.
• No Offset 방식은 바로 이 부분에서 조회 시작 부분을 인덱스로 빠르게 찾아 매번 첫 페이지만 읽도록 하는 방식입니다.
  • (클러스터 인덱스인 PK를 조회 시작 부분 조건문으로 사용했기 때문에 빠르게 조회됩니다.)

---

추후 ES 도입 후 성능 테스트 비교 및 부하 테스트까지 진행 예정입니다!

[Dev-Yesung]

역시 DB고수 맹수호빵님 글 잘읽었습니다~