랭킹이라가는건 뭘까 단순한 줄 세우기인가
어떤 기술을 사용하면 효율적일까?
사실 랭킹은 생각보다 쉽다.
정확히 말하면 쉽게 생각할 수록 쉽게 만들 수 있는거라 생각한다.
랭킹은 RDB로 하는것이 좋을까? 아니면 nosql로 하는것이 좋을까?
정답은 없다고 생각한다.
어떤 기술을 사용해야 한다는것은 없다고 생각한다.
nosql중에는 레디스를 활용해서 데이터를 저장한다.
결국 RDB랑 레디스와 비교를 하는것이 중요하다고 생각이 든다.
어떤것이 더 랭킹 시스템에 어울릴수 있는지 생각할 수 있을거 같다.
나는 랭킹 시스템을 레디스로 만들었는데 그 이유는 낮은 오버헤드와 읽기 성능이 좋다는 것을 높게 평가하였다.
레디스는 다양한 자료구조를 지원하는데 그 중에서도 Zset을 이용하게 되었다. Zset은 레디스가 가지고 있는 낮은 오버헤드와 더불어
정렬기능을 제공하고 있는점을 높게 평가할 수 있었다.
랭킹에 정렬기능은 RDB에서 order by가 자동으로 되는꼴인데
이렇게 되면 효율적으로 데이터를 저장할 수 있다고 한다.
또한 현재는 레디스 파이프라인을 통해 데이터를 저장하고 있다.
하지만 이렇게 되면 추후에 busy-waiting이라 불리는 문제를 야기시킬 수 있다고 한다.
이 문제는 추후에 해결을 하는것이 좋을지도 모르겠다.
일반적으로 파이프라인은 성능 최적화에서는 유리할 수 있지만, busy-waiting 이라고 불리는 문제를 발생시킬 수 있어요. pipeline 으로 보낸 모든 명령 은 큐에 한번에 쌓이게 되기 때문에 이 커맨드가 너무 많을 경우, 다른 커맨드는 블로킹되는 현상이 발생합니다. 그래서, 저는 파이프라인을 쓸 때에는 100~300건 정도로 명령의 갯수를 제한하는 식으로 보통 많이 써요. (chunk 해서 처리) 혹은 tuple 을 복수개로 꽂아서 넣을 수 있다면 zadd 로 접근하는 게 합리적일 것 같아요. (현재 회사에서 5분 배치, 상품 14000개 정도씩 zadd 하는 로직 실제로 돌리는 중)
이제 다음은 배치다. 배치를 통해 데이터 정리를 어떻게 할지 고민하고.. 적용해봐야겠다.
'루퍼스 > 9주차' 카테고리의 다른 글
현재 랭킹 산정 방식이 실제 사용자 요구와 부합 하는지 의문이 제기됩니다 (2) | 2025.09.12 |
---|