perfect dish | 이거 만들어볼까? (5) - 이미지 처리와 컬렉션 속도 비교

갑자기 만들어보고 싶은 거 생겨서 갔다 오느라 잠시 중단했다.

[Java] 구현 연습기 02 - 라이브 챗

 

다시 본론으로 돌아와서 

 

 

🍽 Perfect dish 개발 일지

이 글은 개발 여정을 기록한 것으로 틀린 내용이 나올 수 있습니다. 점점 고쳐나가기 때문이죠 

 

 

💡여러 요구 사항도 충족시키면서 방향 정하기

 

메뉴를 메뉴판에 담는데 어차피 메뉴는 중복될 이유가 없으니까 Set에 담았지만
(메뉴판에서 Map<Menu, CourseType> 할까도 했지만 어차피 메뉴에서 이미 courseType을 필드로 가지고 있기 때문에 메뉴판에서까지 courseType을 관리할 필요가 없다. )

주문을 할 때는 오 이거 맛있네 하나 더 주문할게요! 할 수 있으니까 중복될 수 있단 말이지. 그러니 주문은 List에 담는 게 낫겠다.

우리의 최종 목적은 주문서니까. 

 

그리고 두번째 고민. 그냥 메뉴에서 바로 오더로 갈 수도 있겠는데? (메뉴 -> 메뉴 보드 -> 오더) / (메뉴 -> 오더) ...?

하다가 만 것은 메뉴 A, B, C, D 중에서도 어 오늘 메뉴판에는 메뉴 B, C만 올려야겠다 할 수도 있으니까요. 

 

이어서 생각해 보면 request / response도 메뉴 파트에서는 필요하겠고 메뉴판에서는.. 선택적 메뉴를 올리려면 필요하겠고 

 

 

 

 

💡이미지, url만 저장 vs 멀티파트 파일로 파일을 저장

 

메뉴를 저장할 때 유저의 프로필 사진을 저장하는 거처럼 이미지를 함께 저장한다.

그런데 저장소에 url만 저장하느냐 vs 멀티파트 파일로 파일을 저장하느냐 

 

일단 url만 저장 시 

파일 자체가 외부에 저장되므로 서버의 저장 공간, 리소스 절약 가능, 이미지를 서버로 전송 안 해도 되니까 속도가 빠를 거고 

근데 이미지를 클라이언트에게 의존하는 방식이니까 만약에 그 외부 저장소가 유실 될 위험이 있다.

 

멀티파트 파일로 저장 시? 

위의 유실 위험을 피할 수 있고 이미지 관련 데이터가 하나의 트랜잭션으로 처리되니까 데이터 일관성 유지 가능 

근데 ~ db 용량이 증가할 수 있고 성능 이슈 ~ 그리고 db를 백업 및 복구 시? 고려해야 함 

 

그럼 이미지를 서버에 저장하는 방식으로 하는데 대신 그 크기를 제한해서 저장하는 건 어떨까? 아예 클라이언트 쪽에서 저장할 때 제한을 둔다던가 서버 쪽에서 저장할 때 파일 크기 컨버터 만들어서 변환해서 저장할 수도 있지 않을까...? 라며 검색을 했다. 

근데 서버에서 체크를 하려면 한번 저장 후 -> 변환 -> 재저장..? 뭔가 낭비 ?

그래서 찾아봤다. 이 작업을 최소화하는 방법. 비동기적 리사이징.
업로드된 이미지를 우선 저장 -> 메시지 큐에게 작업 요청 -> 리사이징 작업 수행 -> 적절한 위치에 저장 

오 오 이게 바로 말로만 듣던 메시지 큐...?

 

또 또 일이 커지네 
정신 차려서 기본 기능 돌아가게 해 놓고 빌드업하자 

 

일단은 파일이 지정된 위치에 저장되도록 로직을 짠 후 mockMultipartFile로 테스트를 거쳤다. 

 

TODO 

• 임시 경로에 저장
• 파일 리사이징 후 서버에 저장 

  

 

 

 

💡  set과 map의 저장 및 검색 속도 비교 

 

map과 set에 request를 통해 이미지 파일도 저장한다는 시나리오 대로 fixture를 만들었다.

 

각각 1000개의 가상 데이터를 넣는다고 가정해 저장 속도를 비교해 봤다. 

 

 

또한 조회 속도도 map이 현저하게 빨랐다. 

 

전체 test 코드는 github에서 확인 할 수 있다. 

 

그리하여... menu 클래스는 map에 Long타입이 아닌 String으로 담는다. Set에 담으려 했던 이유인 메뉴명의 중복이 없기 때문 + 굳이 메뉴가 중복이 없는데 id가 필요할까?라는 이유에서 결정하게 되었다.
근데 조회시에는 id를 Long타입으로 하는 게 성능상 빠르긴 하다 🥲 

 

진행 시켜.