검색 성능 개선을 해오면서 고민했던 기록들을 정리해보았습니다. 📔 테스트 항목 검색 기능 가게 이름, 도로명 주소, 업종 가게 이름, 도로명 주소, 업종 평점n점 이상 검색 가게 이름, 도로명 주소, 업종 리뷰n개 이상 검색 가게 이름, 도로명 주소, 업종 평점 높은순 검색 가게 이름, 도로명 주소, 업종 리뷰 많은순 검색 약 200만건의 데이터에 대한 검색 성능 개선 (1초 이내) 개선율 1000% 이상 달성 검색 정확도 향상 검색 기능 ( 가게 이름, 도로명 주소, 업종) 각 카테고리별 평점n점 이상 검색 각 카테고리별 리뷰n개 이상 검색 각 카테고리별 평점 높은순 검색 각 카테고리별 리뷰 많은순 검색 성능 개선에 대한 기술적인 시도들 full scan B-TREE Index 색인 검색 coverin..
Elastic Search 주소 검색 시 Stop-word Parser와 ngram Parser의 문제 현재 가게 이름은 Ngram parser, 도로명 주소는 stop-word 방식으로 인덱싱 되어있다. 현 상태에서 검색 키워드를 “화곡”으로 검색한다면 ⇒ 화곡동으로 검색 시 11427건의 데이터가 있는것을 확인할 수 있음 ⇒ 이때, 키워드를 “화곡”으로 검색한다면 어떠한 검색 결과도 얻을 수 없다. 이유는 주소는 Stop-word 인덱싱 방식이기 때문에 “화곡동”이라는 키워드로만 검색을 할 수 있다. ⇒ 해당 인덱싱 방식에서는 “화곡동”과 “화곡”은 다른 단어가 된다. “강서구 화곡동 화곡빌딩”을 인덱싱 한다면? stop-word ⇒ 강서구 / 화곡동 / 화곡빌딩 ngram ⇒ 강서 / 서구 / 구화..
ElasticSearch 기술적 선택 이유 mySQL의 Index 방식으로는 특정 키워드에서 검색 성능을 개선하기에 어려움이 있었던 것으로 확인을 했고 그에 따라 좀 더 강력한 검색 엔진이 필요했다. 따라서 기존의 index처럼 트리구조(Log(N))의 자료구조가 아닌 해시테이블 방식의 Log(1)구조인 Elastic Search를 적용하고자 했다. 적용이유 첫번째 시간복잡도 Full-text index O(LogN) > ElasticSearch O(1) full-text index가 더 오래 걸린다. Full-text index Full-text index는 MYSQL에서 제공하는 index 방식 중 하나로 DB에서 제공하는 모든 인덱스는 B-TREE 구조로 정렬 및 저장된다. 색인하는 과정으로 해당 ..
full text index + Composite Index limit 적용 이유 프로젝트 특성상 무한스크롤 등의 페이지 기능이 있는 것이 아니라 상위 10개의 검색 결과 값을 받아서 지도에 마커를 찍어서 사용자에게 보여주게 되는데 아예 limit을 걸어서 검색 성능을 높이는 방법을 고려해서 적용해보기로 했다. full text index + Composite Index limit - Limit X 업종별 리뷰 높은 순 3.21초 소요 - Limit O 업종별 리뷰 높은 순 0.29초 소요 ⇒ 약 90.97% 검색 소요 시간 단축 Full-Text Index 방식으로는 개선할 수 없을까? 결론부터 얘기하자면, 어려움이 있는것을 확인하였다! full-text index Limit X full-text in..
full text index + Composite Index 적용 이유 Full Text Index는 결론적으로는 복합인덱스를 적용할 수가 없다. 하지만 full-text index로 검색할 경우 특정 키워드에서 검색 성능이 크게 개선되지 않는 현상이 있었기 때문에 복합인덱스의 장점을 취해서 개선하고자 했다. 즉 full-text index를 적용하고 일부 검색 조건에 대해서는 composite index를 적용해서 성능을 개선하고자 했다. Full-text Index + Composite Index 도입 이유 : Full-Text Index를 사용 하였지만, 업종부분에서는 성능 개선이 되지 않았음. ⇒ “한식” 키워드로 검색할 경우 조회되는 데이터량이 많고 중복되는 데이터가 많기 때문에 업종 관련 검색..
왜 Full-Scan보다 결과가 적게 나왔을까? 이유는 Stop-word parser와 ngram parser 때문 Stop-word parser 방식은 공백을 기준으로 인덱싱을 하는데, 한글의 특성을 생각 했을 때 적합한 방식은 Ngram 방식일 것 같아서 ngram방식으로 리인덱싱을 하였음 2차 테스트 결과 비교: Full-Scan Full-Text Index(Stop-word) 검색 Full-Text Index(Ngram) 검색 ⇒ 테스트 결과 : Stop-word parser > Full Scan > ngram parser 왜 Full-Scan보다 결과가 많이 나왔을까? ngram parser를 적용하여 “순대국”뿐만 아니라 순대라는 단어까지 포함되었기 때문이다. ngram은 최소 2글자로 잘라서..
Full-text index를 적용하고 난 이후 검색 성능은 굉장히 개선되었지만 Full-text index가 내가 검색어를 검색했을때 그 해당하는 검색어가 포함하는 경우를 찾아주는것이라 생각했는데 특정 문자열은 검색이 안되는 현상이 있었다. 문제현상 Full-text index 적용확인 %검색어%로 검색했을때 “성수감자탕”을 포함하는 가게가 아주 잘 나오는 것을 볼 수 있다. Full-text-index로 검색했을때 “성수감자탕”을 포함하는 가게가 없다고 한다. 해결시도 코드에서 먼저 확인을 했다. debug를 했을때 코드는 정상적으로 읽히는 것을 확인을 했고 where절의 Full-text index 쿼리도 잘 날아가는 것을 볼 수 있다. 문제의심 select * from store where mat..
full text index 기술 적용 이유 이전 index에서 설명했듯이 like%처럼 검색어의 앞글자만으로는 검색어를 포함하는 경우가 있는 우리의 검색 기능들을 처리할 수 없겠다라는 판단이 들어서 full text index를 적용하기로 했다. index를 적용해서 검색을 할 경우 검색어로 시작하는 경우만 향상된 검색 성능을 가질 수 있다. select * from store where store_name like “성수%” 하지만 성수로 시작하는 가게이름이 아닌 성수가 포함된 가게이름까지 같이 검색해야한다면 적용해뒀던 index는 사용할 수 없고 %like% 쿼리를 사용할 경우 full scan을 하게 된다. 이러한 상황에서 적용할 수 있는 기술이 full text index이다. 검색 성능 향상 ..
