아이템 검색 API 개발 및 조회성능을 위한 레디스 연동

[gwo1004]

아이템 검색 API

1. 기본 검색 : 필터를 적용하지 않고 BidDB에 등록되어있는 모든 아이템들에 대한 조회 결과 출력 기능 구현

• 대용량 트래픽의 경우 처리속도를 고려하여 어떻게 조회결과를 보여줄 것인지

2. 상세 검색 : SQL조회시의 WHERE절을 사용한 필터기능 구현

• 자료구조 List 또는 Map을 사용하여 필터 저장, 스트림을 적용하여 구현하기

3. 검색 후 정렬 기능 구현

• 각각의 카테고리(아이템 이름, 남은 시간, 입찰 가격, 즉시 구매 가격)에 대한 정렬기능 구현

---

캐싱은 어떠한 경우에 사용할 것인지?
확장성을 고려하여 트랜잭션을 어떻게 처리할 것인지?

[gwo1004]

캐싱을 어떠한 경우에 사용할 것인지에 대한 해결 방법
: 검색시의 Redis를 사용하여 데이터 캐싱을 사용하여 조회결과를 향상시켰습니다.

Redis의 장점

1. Redis의 경우 데이터를 메모리에 저장하는 특징을 가지고 있습니다.
2. 1번의 특징으로 인해 MySQL DB에 접근시보다 더 낮은 데이터 처리속도를 보장합니다.
3. 또한 Redis데이터는 Redis의 설정에 따라 String,Set,List,JSON 등의 다양한 데이터 타입을 지원합니다.
4. 서버에서 장애가 발생하더라도 Redis에 저장된 데이터를 사용하여 복구가 가능합니다.

Redis의 단점

1. 싱글 스레드 형태를 가지고 있습니다.
2. 1번의 이유를 통해 하나의 명령어가 완료되기 전까지는 다른 명령어들은 블로킹이 되어 성능 저하가 발생할 수 있습니다.

단점을 해결하기 위한 방법
과정
시간복잡도 O(n)을 가지고 있는 RedisTemplate의 Keys(Pattern)의 경우 대용량 트래픽일수록 처리시간이 높으며, 해당 Keys 명령어가 수행되기 전까지 다른 명령어들은 블로킹되는 현상이 있었습니다.
해결
Keys를 사용한 전체 데이터에 대한 조회를 ScanOptions를 사용하여 count의 수만큼 끊어서 명령어를 실행하여 성능 저하에 대한 원인을 해결하였습니다.