프로젝트/개인 프로젝트 V36 Elasticsearch vs MySQL FullText 인덱싱 성능 비교 테스트 FullText와 Elasticsearch 비교하려는 목적 : 더 적합한 검색 기능 구현 방식 찾기기존에 LIKE 방식에서 MySQL FullText 방식으로 변경하면서 검색 성능을 높일 수 있었다. 200만 데이터 기준으로 성능 테스트를 진행한 결과, MySQL FullText 방식이 LIKE 방식보다 35배 빠른 성능을 보였다. 또한, '과일마켓 스티커'를 검색했을 때, LIKE 방식은 '과일마켓'과 '스티커' 단어를 포함한 결과만 반환했지만, FullText 방식은 '과일', '마켓', '스티커' 단어가 각각 포함된 결과를 가져왔다. 과일', '마켓', '스티커'와 같은 단어들의 적절한 조합을 포함한 검색 결과를 제공할 수 있어, 사용자 입장에서 더 관련성 높은 검색 결과를 얻을 수 있다고 생각하여.. 2025. 3. 23. Full Text Search를 이용한 DB 성능 개선 상품 검색 기능 개선like의 한계LIKE 검색은 인덱스를 활용하지 못하기 때문에 대량의 데이터에서 성능 저하를 유발한다고 한다. 검색 성능 테스트를 하면서, 실제로 데이터 수가 40 → 200만으로 증가했을 때, 검색 속도가 0.4초 → 4.5초로 느려짐을 확인할 수 있었다. 검색 기능 개선방향: MySQL의 FullText N-gram, ElasticSearch현재 구현한 방식인, LIKE '%검색어%' 구문은 문자열의 중간 검색을 수행하므로 B-tree 인덱스를 사용하지 못하고 Full Table Scan을 해야 한다. 보통 like 키워드 검색 성능 최적화를 위해 MySQL의 FullText N-gram이나 ElasticSearch으로 해결한다고 한다. 나의 경우는 Like에서 FullText으로.. 2025. 3. 6. 검색 쿼리 리팩토링 이번 시간에는 페이징 기능을 구현하며 상품 검색에 필요한 조회 성능을 개선한 과정을 정리하고자 합니다. 기존 검색 구현 방식에서는 상품과 연관된 데이터를 개별적으로 모두 조회한 후, Stream을 사용해 조건에 맞는 데이터를 필터링하고 매핑했습니다. 그러나 이 과정에서 상품 조회와 관련된 쿼리 코드에 중복이 많았고, 실행되는 쿼리 수도 많았습니다.이 문제를 해결하기 위해 개선 전 코드와 개선한 코드를 비교하고, 성능 테스트 코드를 통해 개선 효과를 확인해 보겠습니다. 해당 트러블 슈팅에 대해서 Github에도 정리했으니 참고해주세요.리팩토링 전리팩토링 전 코드는 아래와 같습니다. 데이터 조회 및 처리 로직이 길고 복잡했습니다. 각 태그(userDefinedTag, recommendedTag) 정보.. 2024. 12. 10. 거래요청에 대한 동시성 테스트 주문시 트랜잭션처리와 예외처리에 대한 생각상품 거래 시스템을 만들 때 신경 써야 하는 부분이 많았었습니다. 그 중에서 동시성 관리는 중요한 요구사항 중 하나였습니다. 주문 처리 시 상품이 단일 상품으로 정의되었기 때문에, 동시에 주문 요청이 들어오는 상황에서 동시성 제어가 필요했습니다. 특히, 다수의 사용자가 동시에 주문을 시도할 경우 데이터 무결성을 보장해야 했습니다. 단일 상품으로 재고가 1개이기에 중복 거래요청이 발생하면 구매자와 판매자 모두에게 곤란한 상황을 만들게 됩니다. 주문 생성 및 판매 요청처리 단계에서 트랜잭션을 어떻게 사용해야 할지 고민했습니다. 이번 시간에는 동시성 문제를 해결한 과정을 다루겠습니다. 주문 처리 흐름에서의 트랜잭션과 예외처리리포지토리 인터페이스 JPA에서 제공하는 비관.. 2024. 12. 6. 이전 1 2 다음
