[ TIL ] 최종 프로젝트_Day 9

오늘 진행한 내용들 🧐 

최근 검색 기록 조회 성능 개선

오늘은 최근 검색 기록 조회에 인덱스도 적용해 보고 레디스도 적용해 보며 성능 개선을 확인해 봤다.
먼저 복합 인덱스를 적용해서 (userId, createdAt DESC)로 설정해 주었고, 성능이 개선되는지 확인해 보았다. 복합 인덱스를 다음과 같이 설정한 이유는 데이터를 userId를 통해 찾아오고 최근 저장 기준으로 상위 10개를 가져오기 때문에 createdAt DESC를 함께 설정하면 정렬 필요 없이 가져올 수 있는 장점이 있다.
성능을 확인한 결과 type이 ALL에서 ref로 변경되었고, Using where; Using filesort에서 Using index로 변경되었다. 실제 실행 시간도 약 23% 감소하는 것을 확인했다.

인덱스 적용 전 EXPLAIN 결과

인덱스 적용 전 EXPLAIN 결과

인덱스 적용 후 EXPLAIN 결과

인덱스 적용 후 EXPLAIN 결과

하지만 여기서 멈추지 않고 생각을 했던 부분이... 사용자가 검색어를 통해 채용 공고를 검색하게 되면 검색어가 History 테이블에 추가될 텐데 이렇게 자주 Insert가 일어나는 테이블에 인덱스를 적용하는 것이 과연 맞을까..? 하는 의문이 생겼다.
새로운 데이터를 테이블에 삽입한 후, 인덱스 페이지에도 해당 데이터의 키를 반영해야 하므로 성능이 저하될 수 있고 B-Tree 기반 인덱스는 균형을 유지하기 위해 노드 분할(Split)과 재조정(Rebalancing)이 발생할 수 있어서 더 많은 성능 저하를 유발할 수 있다.

이러한 이유로 Redis를 적용해서 Redis에 검색어를 저장해 놓고 조회할 때 Redis에서 조회한다면 빠른 속도로 확인할 수 있지 않을까 생각하게 되었다.
그래서 바로 Redis를 적용해 봤다. 적용하고 DB에서 조회하는 것과 Redis에서 조회하는 것의 속도 차이를 확인했다.

DB에서 최근 검색 기록 조회 속도

Redis에서 최근 검색 기록 조회 속도

Redis를 적용하기 전과 후가 확실하게 속도 차이를 보였다. 이런 결과로 Redis를 확실하게 적용하게 되었고, 검색어를 Redis에 저장하게 되면 DB에는 검색어가 저장되지 않기 때문에 @Scheduler를 활용해서 30분마다 DB에 존재하지 않는 값을 저장할 수 있도록 동기화했다. 그럼 DB에도 값이 최신화되고 Redis에서도 값이 최신화되어서 문제가 사라진다!

Redis를 사용하면서 팀원들마다 사용하는 버전이 달랐는데, 이 부분도 찾아보면서 뭐가 더 효율적인지 정리해 보았다.

함께 사용했을 때의 장점

• RedissonClinet는 분산 락, 동기화, 복잡한 데이터 구조 관리에 강점이 있다.
• RedisTemplate은 Spring Boot와의 연동, 간단한 캐싱, 기본적인 Redis 데이터 조작에 더 적합하다.
• 그래서 함께 사용할 경우 각각의 장점을 최대로 활용할 수 있다.

이렇게 최근 검색 조회에 대한 성능 개선을 마무리하고 Elasticsearch로 넘어가기로 했다.

 

오늘 하루 정리 ✏️

계속 성능 개선에 대해 생각하고 진행하는 연습을 할 수 있었던 것 같다.

해당 기술을 사용하면 왜 사용하는지, 왜 사용하면 안 되는지에 대해 찾아보고 고민하는 습관을 기를 수 있었고 아직 부족하지만 프로젝트를 통해 성장하고 있는 것 같다.

ElasticSearch까지 사용하고 나면 어느 정도 성능 개선이 마무리될 것이라고 생각한다.

 

내일 계획 ⏰

• Elasticsearch 설치 및 설정
• Elasticsearch 공부
• 전체 페이지 조회에 적용해 보기

+ 추가 계획은 언제나 생길 수 있습니다~_~