인기글 좋아요순 정렬 설계 면접: 100만 글을 매번 세면 생기는 일

이런 화면입니다

커뮤니티 인기 탭을 엽니다. 좋아요를 많이 받은 글이 위에서부터 줄을 서 있습니다.

글은 100만 건이고, 좋아요는 누가 어느 글에 눌렀는지가 한 줄씩 쌓여 있습니다. 인기 탭은 그 줄들을 세어야 나오는 순서입니다.

면접관이 이렇게 묻습니다

범위부터 좁힙니다

한 줄로 좁힙니다. 좋아요 수가 많은 순으로 글 목록을 내려 주고, 각 글의 좋아요 수도 같이 보여 준다. 실시간 급상승은 접고 많은 순 하나에 집중합니다.

가장 많이 나오는 답

정렬할 때마다 글별로 좋아요를 셉니다.

SELECT p.id, p.title, COUNT(l.user_id) AS likes
FROM   posts p
LEFT   JOIN likes l ON l.post_id = p.id
GROUP  BY p.id
ORDER  BY likes DESC
LIMIT  20;

글 몇백 개로 시험하면 금방 나옵니다.

그런데 여기서 깨집니다

인기 탭을 한 번 열 때마다 100만 글의 좋아요를 전부 셉니다. 보여 주는 건 20개인데 세는 건 전체입니다. 사용자가 늘수록 같은 셈을 끝없이 반복합니다.

인기 탭은 첫 화면에 걸려 있습니다. 가장 많이 열리는 화면이 가장 비싼 쿼리를 부르는 셈입니다.

떨어지는 답은 이런 모양입니다

• GROUP BY로 세는 쿼리로 끝냅니다.
• 느려지면 서버를 늘리겠다고 답합니다.
• 인기 탭이 열릴 때마다 무엇을 세는지 설명하지 못합니다.

면접관은 여기서 멈추지 않습니다

1. 목록에 댓글 수도 보여 줘야 하면요?

   같은 문제가 하나 더 붙을 때 설계가 늘어나는 방식을 봅니다.

2. 「오늘의 인기글」이라면요?

   기간이 붙으면 세는 범위가 바뀐다는 것을 아는지 봅니다.

3. 분 단위로 갱신되는 실시간 급상승 랭킹이라면요?

   정확도와 신선도 사이에서 무엇을 내줄지 말하는지 봅니다.