인프런 커뮤니티 질문&답변
ProductOption을 통한 FindProductOption에 관한 질문
해결된 질문
작성
·
16
1
ProductOption을 fetch해 올때 DB레벨에서 where이랑 orderby를 하지 않고 애플리케이션 레벨에서 코틀린 filter와 sort를 하신 이유가 따로 있을까요? 성능상 DB에서 전체적으로 데이터를 가져오고 인메모리 작업으로 filter와 sort를 하는게 불리하지 않나 싶어서 질문을 남깁니다.
답변 2
1
안녕하세요 질문 감사드립니다!
이 부분은 전략에 대한 것을 수강생 분들이 느끼셨으면해서 그렇게 구성해두었는데요! 아주 좋은 질문입니다!
해당 코드에 대한 배경은 일반적으로 상품의 옵션은 많지 않다 를 전제로 하고 있습니다
그 전제에서는 굳이 디비를 통해서 정렬이나 필터링을 하지 않아도 크게 부하의 차이가 없고(관련 인덱스가 없다는 전제) 오히려 DB의 쿼리 수행 속도가 더 올라가게 되는 이점이 있습니다.
결국 디비에서 관련 인덱스가 없다면 DB의 컴퓨팅 리소스를 쓰게 되는 것 이니까요
굳이 이 배경을 더 넓게 생각해보면 일반적으로 디비는 한정 자원입니다 (스케일 업과, 아웃이 다 가능하지만 읽기 지연, 멀티 마스터 등으로 가려고하면 할 수록 복잡해지죠)
반대로 어플리케이션을 확장하기가 쉽습니다, 그래서 우리 서비스의 상황을 적절히 판단해서 적절한 엔지니어링을 해야한다고 생각합니다!
+ 그치만 사실 일반적으로 상품의 옵션은 많지 않다 전제라면 DB로 인덱스 없이 조회 해도 상관 없습니다ㅎㅎㅎㅎ;;; 수강생 분들이 고민 한번 해보셨으면해서 구현을 적용 해두었습니다
다만 상황이 달라져서 이미 인덱스가 있고 옵션을 날마다 생성하고 삭제하는 서비스라면 DB에게 부하를 더 주는게 맞는 전략이 될 것 입니다!
모쪼록 답이 되었길 바랍니다! 감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다. hahahl님.
질문해주신 부분은 데이터베이스 레벨에서의 연산과 애플리케이션 레벨에서의 연산 중 어느 것을 선택할지에 대한 고민으로 보입니다. 일반적으로, 데이터베이스 레벨에서 필터링과 정렬을 수행하면 데이터 전송량을 줄일 수 있고, 이는 성능적으로 유리할 수 있습니다. 그러나, 애플리케이션 레벨에서 코틀린의 filter와 sort를 사용하는 것도 특정 상황에서 적합할 수 있습니다.
몇 가지 이유를 고려해볼 수 있습니다:
비즈니스 로직의 복잡성: 데이터베이스 쿼리로 처리하기에는 비즈니스 로직이 복잡할 경우, 애플리케이션 레벨에서 관리하는 것이 더 쉽고 직관적일 수 있습니다.
데이터 처리량이 많지 않을 때: 가져오는 데이터의 양이 적고, 메모리에 로드한 후 처리해도 성능에 큰 영향을 주지 않는 경우에 애플리케이션 레벨에서의 처리가 효율적일 수 있습니다.
유지보수 및 가독성: 코드를 읽고 유지보수하기 편리하게 하려는 경우, 또한 코드의 일관성을 유지하려는 목적에서 애플리케이션 레벨에서 처리하는 경우도 있습니다.
최신성: 데이터베이스 쿼리를 자주 변경하지 않고, 애플리케이션 로직에서 데이터 처리를 하고 변화가 필요할 때 신속히 대응할 수 있도록 설계된 경우입니다.
만약 데이터의 양이 매우 큰 경우에는 DB 레벨의 쿼리를 통해 성능 최적화를 추구하는 것이 일반적인 방법입니다. 하지만 데이터의 특성, 트래픽 유형, 성능 요구 사항에 따라서 최적의 방법이 달라질 수 있습니다. 때로는 임시적인 선택일 수도 있으며, 향후 확장성을 고려한 유연한 구조로 시작했을 수 있습니다.
관련하여 아래 자료도 참고하시면 좋을 것 같습니다:
- 사용자가 상품을 선택하고 쿠폰을 고를 때 가장 혜택이 큰 쿠폰을 고르는 상황: 필터링과 최적화 로직에 대한 고찰.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.




