검색 구현 후 느린 검색 속도
•
도입 이유
•
문제 상황
◦
검색에 7~10초 가량 소요될 정도로 시간이 오래걸림
◦
→ 이 시간이 오래걸리는것이, 페이징 때문인지 파악하기가 어려움.
◦
→ 콘솔 로그에서 단순 시간 체크를 해보니 전체 페이지숫자를 연산하는것때문에 느리다
•
해결 방안 의견
◦
%KEYWORD%와 같은 like절의 키워드 검색 속도를 개선 할 수 있는 방법이 없을지 파악 필요
◦
검색 쿼리 최적화: 검색 쿼리를 최적화하여 불필요한 부하를 줄이고 더 효율적으로 데이터를 가져올 수 있도록 개선하는 것이 중요
◦
Full-Text Search Index 검색은 자연어 처리에 기반하고 있어 사용자가 검색할 때 사용하는 언어의 특성을 고려할 수 있어요. 이를 통해 더 유연한 검색이 가능하며, 대용량의 텍스트 데이터에서 효과적으로 활용될 수 있다.
◦
Elasticsearch나 Solr 같은 검색 엔진을 도입하면 검색 엔진은 대용량 데이터에서 빠르고 효율적인 검색을 지원하며, 다양한 기능과 유연성을 제공
◦
캐싱 활용 자주 사용되는 검색어나 결과를 캐싱하여 중복 검색 요청 개선
◦
파티셔닝 및 샤딩: 데이터를 파티셔닝하거나 샤딩하여 검색 범위를 축소
검색 결과가 다수 나타날 때 [페이징] 자체가 성능을 좌우하는 문제
•
도입 이유
◦
도서 키워드 검색 시 키워드 검색 결과에 대해서도 페이징 처리가 추가되어있음
◦
해당 페이징 링크를 이동할 때도 첫 키워드 검색과 유사한 시간이 소요됨
유저 - 도서 대출 등 서비스 이용용도 도서 검색 기능 화면
관리자 - 도서 관리용 도서 검색 화면
•
문제 상황
◦
검색 이후 결과가 10개 이상인 경우 페이지 링크는 다음처럼 키워드를 유지하도록 작성한 상태
▪
따라서 다음 페이지 링크를 클릭하는 행위은 결과적으로 키워드 검색+2페이지 이동 요청임
▪
사실상 페이징 링크를 들어가는것 = 검색을 또하는것
▪
→ 검색이 10초 걸린다면 페이지 이동시 마다 10초가 소요된다.
▪
우선 이것 자체가 검색 성능의 문제인가?
▪
실제로 검색 성능은 1초 미만으로 미미한 상태이며
▪
과도한 시간이 소요되는 것은 페이징 카운트 연산에서 소모되고 있다.
•
그럼 이것을 해결한 이후에 검색 성능에 집중해서 테스트 해야 실제 검색성능 개선이 아닐까?
•
우선 페이징 최적화가 우선 필요하다는 말.