🚢 WishList가 장바구니? (Redis 의 Hash타입 사용)

문제

우선 좀 더 명확한 요구사항이 나오게 되면서 깨닳게 된것이 WishList라는 것이 찜같은 것이 아니라 장바구니의 역할을 하게 된다는 것이였다. 이유는 WishList와 관련된 서비스가 User에 존재하지 않고 Order에 존재했기 때문이다. 사용자가 찜을 해서 사용자가 자신의 마이페이지에 갔을때 찜한 목록을 보는 것이다 라고 생각한다면 해당 서비스는 User에 생겨야 한다고 생각했지만 요구사항에서 Order에 존재한다는 것은 해당 내용이 주문으로 이어진다는 이야기이고 그것은 곧 장바구니이다. 라고 생각이 떠올랐다

 

Redis(Shopping Cart)

이번에 Redis를 공부하게 되면서 장바구니 하면 떠오르는 것이 바로 redis이다. 왜냐하면 사용자의 입장에서 장바구니를 접근하는 횟수는 다른 요청에 비해서 어마어마하게 많은 상황을 생각 할 수 있다. 마음에 드는 물건을 집기만 해도 장바구니를 접근하고 내가 고른 물건이 뭐였었는지 기억이 나지 않을때마다 장바구니를 들어와서 확인을 하고 주문의 내용을 확인할 때도 장바구니를 들어온다. 그러한 사용자가 점차 쌓여서 많아지게 되면 정말 많은 데이터 접촉이 일어나게 될텐데 이때 만약 DB를 사용하게 되면 응답속도가 점차점차 느려지게 될 것이 확실해진다.

 

또한 장바구니에 대한 만료시간도 설정할 수 있다. 

 

결과 확인

일반 DB사용

1) 찜추가

 

2) 찜리스트 확인

 

Redis

1) 장바구니 추가

 

2) 장바구니 확인

---

• 많은 테스트를 진행하지는 못했지만 Time을 보면 장바구니를 넣는 과정에서는 응답속도가 50%가 넘는 정도로 줄어들었다. 역시 Redis를 통해 데이터를 다루기 때문에 훨씬 빠른 것이다
• 하지만 그에 비해 조회는 그렇게 드라마틱한 반응이 없다. 왜냐하면 Redis는 해당 해쉬 키를 통한 전체 탐색을 하는 것이 O(N)의 시간 복잡도를 가지고 있기 때문이다. 그렇다고 속도가 더 느리진 않지만 만약 장바구니 많은 내용이 담기면 담길수록 반응 속도는 점점 느려지게 될 것이라는 생각이 든다
• 모든 테스트 케이스를 사진을 통해 저장하지는 못했지만 확실히 DB까지 진행하는 것과 Redis만을 이용해서 진행하는 것에서 응답 시간의 차이를 확실히 보여주었다.

 

느낀점

사용자가 자주 접근하는 장바구니이기 때문에 수정, 삭제, 추가가 많아지면 많아질수록 점점 성능이 안좋아지는 DB에 비해 Redis를 사용하는 것이 좋다고 생각한다

 

하지만 조회의 경우 테이블에 많다면 아무리 Redis라도 O(N)의 상황이 되고 또한 싱글스레드를 사용하기 때문에 유저가 많아져 요청이 쌓이면 막 그렇게 훨씬 월등히 좋다! 이런 느낌은 딱히 없을것 같다. 하지만 그외에 내용에서는 확실히 좋다고 느낄수 있다.

 

사용자가 정말 자주 찾게되는 데이터를 Redis로 사용한다면 다른 곳에서도 효과적으로 사용할 수 있는게 뭐가 있을까 고민을 해보았다. 같이 스터디를 하는 친구가 메인 화면에서 접근하는 상품을 나타내는 화면또한 많은 데이터를 빨리 내보내 주어야 하기 때문에 이것도 Redis의 caching 기능을 사용해서 진행해보는 것도 굉장히 좋을것 같다