[셀럽잇] 쿼리는 못말려 - (2) 서브쿼리 분리하기

 

 

 

 

 

🤔 서론

서브쿼리는 대체로 성능이 느리므로 사용에 주의해야 합니다.

성능뿐만 아니라 가독성을 해쳐 유지보수의 측면에서도 부정적인 영향을 끼칠 가능성이 있습니다.

이번에는 저희 셀럽잇 팀에서 서브쿼리를 사용하고 있는 코드를 살펴보며, 어떠한 문제점이 있는지 파악하고 이를 개선해 보도록 하겠습니다.

 

 

 

 

 

 

🤔 현재 상황

저희는 음식점들의 목록을 보여줄 때, 해당 음식점에 달린 좋아요의 개수와, 만약 사용자가 로그인 한 상태라면 해당 사용자가 특정 음식점을 좋아요 했는지에 대한 여부를 함께 보여줍니다.

좋아요 수는 반영이 안되었지만, 사진으로 보면 다음과 같습니다.

 

이를 위한 코드는 다음과 같이 작성되어 있습니다.

 

 

이를 통해 발생하는 쿼리는 다음과 같습니다.

위 쿼리의 문제점을 살펴보도록 하겠습니다.

 

가독성의 측면에서는 서브쿼리로 인해 쿼리의 길이가 많이 길어지고, 각각의 서브쿼리가 무엇을 의미하는 것인지 한눈에 들어오지 않기 때문에 가독성이 많이 저하됩니다.

 

또한 서브쿼리를 사용했기에 이를 위한 쿼리가 추가로 발생하게 되므로 좋은 성능을 기대하기 어렵습니다.

 

우선 데이터 10만개 기준으로 현재 쿼리의 성능을 측정해 보도록 하겠습니다.

ec2 프리티어 기준입니다.

 

API 를 통해 호출한 경우, 다음과 같습니다.

local(Mac m1 pro) 기준입니다.

 

이제 해당 쿼리를 서브쿼리를 제거함으로써 성능 향상을 시켜보도록 할텐데, 한가지 문제점이 있습니다.

정렬 조건의 경우, 거리순으로 정렬할 수도 잇지만, 좋아요 수를 기준으로 정렬하는 경우도 있기 때문에, 서브쿼리를 사용하지 않고 쿼리를 작성하게 되면 정렬을 수행할 수 없게 됩니다.

 

이를 위해 테이블의 역정규화도 함께 진행하여, 서브쿼리를 분리하고 좋아요의 수를 관리하도록 하겠습니다.

 

 

 

 

 

 

 

🤔 1.  쉽게 분리 가능한 서브쿼리 분리하기

먼저 역정규화를 수행하기에는 마음이 끌리지 않았습니다.

(바꿀 부분이 많아져서 두려웠던....)

아무튼 역정규화는 이후에 수행하기로 하고, 우선 큰 비용을 들이지 않고 제거할 수 있는 서브쿼리를 제거하도록 하겠습니다.

위의 박스 친 부분이 테이블의 구조를 변경하지 않고, 큰 파급효과 없이 제거할 수 있는 서브쿼리입니다.

 

이를 제거하고, 애플리케이션 단에서 좋아요를 눌렀는지 여부를 확인해주는 코드를 추가해주었습니다.

(이곳에서는 따로 언급하지 않겠습니다만, 회원 아이디와 음식점 ID들을 In 절로 조회한 뒤 음식점 ID로 그룹화해주어 좋아요 여부를 확인했습니다.)

 

결과는 다음과 같이, 두 개의 쿼리로 분리되었습니다.

(쿼리의 성능은 별 차이나지 않습니다)

 

 

이어서 역정규화를 통해 좋아요 수를 가져오는 서브쿼리도 분리하도록 하겠습니다.

 

 

 

 

 

 

 

🤔 2. 좋아요 수 역정규화를 통한 서브쿼리 분리

여러 방법이 있을 수 있지만, 다음 쿼리를 통해 수행하도록 하겠습니다.

ALTER TABLE restaurant ADD like_count INT;

UPDATE restaurant SET like_count = (
    SELECT COUNT(*)
    FROM restaurant_like
    WHERE restaurant_id = restaurant.id
);

 

 

다음과 같이 데이터가 잘 들어간 것을 확인할 수 있습니다.

 

 

이제 변경된 데이터를 기반으로 기존 코드를 수정하도록 할텐데, 그전에 위를 보면 다음과 같은 의문이 하나 생길 수 있습니다.

(반영하는 중간에 좋아요가 추가되거나 제거되면 어떻게 하지..?)

 

이에 대해서는 여러 해답이 있을 수 있습니다.

무중단 배포를 진행중인 상황이면서, 데이터의 정합성이 굉장히 중요한 경우에는 많은 복잡한 과정(자세히는 누누 블로그 참고)을 거쳐야 하겠지만, 저희 서비스의 경우에는 아직 그정도를 고려할 필요가 없는 상황입니다.

 

우선 무중단 배포를 진행하고 있지도 않을 뿐더러, 무중단 배포를 진행하더라도 좋아요의 수는 상대적으로 정합성이 중요하지 않은 데이터입니다.

따라서 배포 이후 좋아요 수를 반영하는 스케쥴러를 통해 최종적으로 정합성을 맞춰주는 방법 등을 사용하여 해결할 수 있습니다.

(그렇지만 저희는 아직 중단 배포를 사용하므로, 중단된 순간에 파파박 수정하면 될 것 같습니다 🙂)

 

일단은 이를 고려하지 않고 코드 수정을 진행하도록 하겠습니다.

 

음식점에 좋아요 수를 카운트하는 필드를 추가하고, 이를 증가&감소시키는 로직을 작성해주었습니다.

 

 

이제 쿼리는 다음과 같이 수정됩니다.

 

 

 

코드상으로는 조금 더 수정이 필요하지만, 해당 과정은 건너뛰고, 최종 결과를 살펴보겠습니다.

발생하는 쿼리는 위와 같아집니다.

 

 

실행 시간은 다음과같습니다.

ec2 프리티어 기준입니다

 

(참고 - 기존 실행 시간)

ec2 프리티어 기준입니다.

 

샘플 데이터 기준으로 데이터의 수가 그리 많지 않음에도 불구하고 1/6 정도의 성능 개선을 이루어냈습니다.

 

local(Mac m1 pro) 기준입니다.

로컬에서 API를 호출하여 확인한 결과, 속도는 그렇게까지 향상된 것 같지 않지만, 좋아요 수가 별로 없었음 + 맥북이라 빠름을 고려하면 실제 서비스 환경에서는 많은 개선이 이루어졌음을 예상할 수 있습니다.

(조금 더 자세히 성능을 측정하고 싶다면 성능 테스트를 진행하는 것이 좋겠지만, 해당 글의 주제와는 벗어남으로 따로 기록하지는 않겠습니다.)

 

 

 

 

 

🤔 예고

이번 글에서 좋아요 수에 대한 서브쿼리를 역정규화를 통해 제거하였는데요, 이때 좋아요 수의 증가 & 감소를 다음과 같은 로직을 통해 처리하였습니다.

코드를 조금 더 개선하고 싶지만, 우선 쿼리 개선이 급급하여 대충 동작하게만 작성했습니다.

 

위 코드는 사실 어마어마한 문제가 있는데요, 그 문제가 무엇이고 어떤 방식으로 해결할 수 있는지에 대해 다음 글에서 알아보도록 하겠습니다.

또한 아직 추가적으로 처리해줄 부분이 남아있는데요, 다음과 같습니다.

• 실행계획 확인과 인덱스 설정
• 특정 셀럽으로 필터링하여 음식점을 검색하는 경우를 제외하고는 Video와 Celeb에 대한 Join이 필요없음
  • 즉 불필요한 Join으로 인한 성능 저하 문제 발생

위 사항들도 앞으로 계속해서 개선해 나가도록 하겠습니다.