작성한 질문수 37

1

soap님, 안녕하세요!

말씀하신 방법으로도 구현은 가능하지만,

조회수처럼 실시간으로 변하는 데이터에 대해서는 페이지 넘어갈때 정렬이 깨지는 현상은 당연하고 어쩔 수 없습니다.

이러한 방식은 기술로 풀어내기 보단, 서비스 정책으로 풀어내는게 유리할 것 같습니다.

실제로도 기술적으로 해결하기 어려울 때에는 정책으로 풀어내는 상황이 아주 많습니다.

만약 기술로 풀어낼 수 있다고 하더라도, 그 복잡성과 서버 비용 및 부하 대비하여 사용자에게 큰 이점이 없을 때에도 정책으로 풀어낼 수 있는 것이고요.

몇 가지 예시를 드려보겠습니다.

• 항상 실시간으로 완벽하게 정렬된 상태를 만들 필요가 없도록 한다면?

그러면 "페이징 쿼리에서 RDB 백업 테이블의 조회수 기준으로 정렬"만 하면 충분할 수도 있습니다.

코드 레벨에서 redis 데이터 기준으로 실시간 정렬할 필요가 없어지게 되는 것이고요.

그러면 두 번 정렬해야 하는 부담이 줄어들게 됩니다.

정렬이 깨지는 현상을 완벽히 막아낼 순 없지만, 적어도 완전한 실시간 보다는 줄어들게 될 것이고요.

• 항상 실시간으로 완벽하게 정렬된 상태를 만들 필요가 없도록 하고, 정렬 키(조회수)의 갱신 단위를 더욱 늦춘다면?

갱신 단위는 현 기준처럼 개수가 될 수도 있고, 시간이 될 수도 있습니다.

만약 10개 -> 100개로 늘린다면, 정렬 순서가 갱신되는 주기는 더욱 늘어나게 됩니다.

이 경우에도 정렬이 깨지는 현상을 완벽히 막아낼 순 없지만, 적어도 완전한 실시간 보다는 줄어들게 됩니다.

• 조회수 상위 N건만 조회할 수 있도록 한다면?

여기서 말하는 N은 메모리로 한번에 불러와도 충분한 크기를 말합니다.

다음 페이지를 요청할 때, 현재 사용자가 가지고 있는 모든 데이터의 식별자를 전달합니다.

식별자는 압축 등으로 최대한 작게 유지할 수도 있는 것이고요.

애플리케이션 서버는 DB(또는 레디스)에서 N건을 모두 조회하고, 사용자에게 이미 응답된 데이터들은 필터링한 상위 pageSize 개수만큼 데이터를 반환해줍니다.

사용자에게 이미 응답된 데이터들의 정렬은 어쩔 수 없겠지만(물론 정책에 따라 클라이언트 재정렬을 할 수도 있음),

적어도 새롭게 페이지를 요청하는 시점에는 현재 정렬된 기준의 데이터들을 중복없이 노출 시켜줄 수 있습니다.

기술적으로 풀어내기 어렵다면, 정말로 필요한 기능인지 또는 비슷하면서도 다른(간소화된) 방법으로 풀어낼 수는 없는지도 고민해보시는 것도 좋습니다!