Skip to content

Commit

Permalink
Update README.md
Browse files Browse the repository at this point in the history
  • Loading branch information
youngreal authored Feb 18, 2024
1 parent d0c475c commit a9c11db
Showing 1 changed file with 4 additions and 1 deletion.
5 changes: 4 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -378,13 +378,16 @@ where ..
## 5. LIKE %word%로 게시글 검색 시 full table scan이 발생해 레이턴시가 증가하는 문제를 fulltext-search로 개선하기

### 문제 발견
- LIKE %word% 쿼리는 인덱스를 적용할 수 없어서 테이블 풀 스캔으로 검색 결과를 찾아야 하는 문제를 인식하였고, 수치 확인을 위한 테스트를 진행했습니다.
- like %word% 검색 사용중 대부분은 limit으로인해 전체 테이블을 스캔하는 일이 거의 없었지만, 검색결과에 해당하는 로우가 하나도 없는 검색어 입력시 전체 테이블을 스캔하는 문제가 있었습니다.
- 검색 결과에 해당하지 않는 게시글 검색 시 테이블의 데이터 수가 50만건일 때 쿼리 응답속도가 3초, 약 200만 건이 넘어가는 순간부터 쿼리 응답속도만 5초 이상이 소요되는 문제 발견했습니다.
![image](https://github.com/youngreal/inflearn/assets/59333182/c0be383a-0bb5-4df9-b196-9c9e008706d7)
- 현재 페이징으로 20개의 결과만 가져오기 때문에 운 좋게 테이블 전체를 스캔하지 않고 20개의 결과를 먼저 찾는 경우 조금 더 빠를 수 있지만, ``검색어의 해당하는 결과가 없는 최악의 경우`` full-table scan으로 5초까지도 소요됩니다.


**문제 발견후 사고과정**
- 서비스 특성상 “자바”, “스프링” 같은 키워드에대한 검색결과가 많을것으로 예상되는데, 이들을 인기검색결과 테이블을 따로 분리하고, like 쿼리를쓰는 방법을 고려하였으나 실제 서비스 하지 않았기 때문에 수치가 어느정도 되는지 알 수 없는 한계가 있었습니다.
- 그러면 위의 방법을 해결하지 못한다고 가정했을 때

- 학습비용, 복잡도를 고려해 mysql의 fulltext-search를 선택하였습니다.
- like %word% 쿼리와 Full-text search 쿼리의 성능 비교 후 , 검색 결과에 따라 성능이 달라지는 것을 발견했습니다.
- 검색결과가 0건인경우 쿼리응답 속도
Expand Down

0 comments on commit a9c11db

Please sign in to comment.