지난 글에 집고팀에서 사용하는 쿼리를 살펴보고 개선 방안들을 도출해봤습니다. 이번 글에서는 실제로 코드와 쿼리를 고쳐보고 클라이언트에서 받는 데이터까지 가공하면 어디까지 개선이 가능한지 더 자세히 살펴보겠습니다. Entity보다 DTO를 서비스 코드와 Response 프로퍼티들을 분석해본 결과, 아래와 같은 총 4개의 프로퍼티만 필요로 했습니다. pet_food_id pet_food_name brand_name pet_food_image_url public List findPagingPetFoods( List brandsName, List standards, List primaryIngredientList, List functionalityList, Long lastPetFoodId, int size )..

우아한테크코스 팀 프로젝트를 진행 중입니다. 5차 스프린트 요구사항들 중 아래와 같은 요구사항도 존재했는데요. 서비스에서 사용하는 쿼리를 정리하고, 각 쿼리에서 사용하는 인덱스 설정 서비스에서 사용하는 모든 조회 쿼리와 테이블에 설정한 인덱스 공유 인덱스를 설정할 수 없는 쿼리가 있는 경우, 인덱스를 설정할 수 없는 이유 공유 기존 쿼리를 만들 때 어느 정도 개선을 해오면서 만들었었기 때문에 평소 쿼리에 대한 고민을 많이 해보지도 않았었습니다. 실제로 쿼리 개선이 필요할 만큼 TPS가 높지도 않았고요. 또한 어떤 쿼리가 문제인지 찾아내는 과정을 위한 학습도 되어있지 않았습니다. 그래서 이번 글에서는 아무것도 모르는 상태에서 기존 쿼리를 어떻게 개선해 나갔는지 천천히 정리해나가 보도록 하겠습니다. 이번에 ..

서론 개발을 하면서 Application Code와 Database Query 둘 중 어느 것을 사용하여 비즈니스 로직을 처리해야 할지 고민했던 적이 있었는가. 그런 상황이 적지 않았을 것이라고 생각한다. 필자는 꽤나 궁금해서 과연 Application Code와 Database Query 사이의 패러다임을 어느정도 감안하고 Trade Off 해야 할지, 더 나아가선 성능은 얼마나 차이가 나는지 측정해보려고 한다. 구현 내용 우선 요구 사항은 필터링 기능이 주를 이룬다. 애플리케이션 코드로 처리하든, 쿼리로 처리하든 개발자에게는 꽤나 많은 리소스가 들 것이라고 예상되기 때문이다. 필터링 요구사항은 다음과 같다. 카테고리별 복수 선택이 가능하며, 같은 카테고리에서 복수 선택 시 or 조건 발생, 다른 카테..