100만건 순위 탐색, 과연 누가 빠를까? #mysql #redis

Video: 100만건 순위 탐색, 과연 누가 빠를까? #mysql #redis
Channel: 코딩하는기술사
Duration: 2m 58s
Source: subtitle (auto, ko)
Transcript:
자, 이번에는 RGB인 마이스
SQL과 레디스의 랭킹 조회 성능을
비교해 보겠습니다.이 게임의 실시간
랭킹이나 포털의 실시간 검색 순위
같은 기능인데요. 데이터는 100만
건 초기하겠습니다.
MySQL은 유저 아이디 그리고
유저네임 그리고 스코어 컬럼을 가진
테이블이고 스코어 컬럼에 인덱스가
걸려 있습니다. 그리고 레디스는
솔티드 셋 자료 구조에 멤버는 사용자
정보 스코어는 점수입니다. 마스의
코리는 오더바이와 리밋 오프셋
레디스는 G리버스 레인지 명령어를
사용합니다. 어 테스트 시나리오는
특정 순위 구간에 상위 열명을
조회하는 것입니다. 예를 들어서
500등 구간이면 501등부터
510등까지 열명을 가져옵니다.
이렇게 500등부터 시작해서 90만
등까지 점점 깊은 위치를 조회하게
합니다. 자, 먼저 데이터를 100만
건 준비하겠습니다.
자, 100만 건 데이터를 생성하고
있습니다. 자, 100만 건 생성이
완료되었습니다.
자, 이제 벤치마크 시작 버튼을
누르면 테스트가 시작됩니다. 자,
테스트를 시작하겠습니다.
자, 노란색이 마이스QL, 빨간색이
레디스입니다.
처음엔 비슷하죠? 오프셋이 적을 때는
큰 차이가 없습니다.
그런데이 5천등을 넘어가면서
보이시죠? 마이스이 급격하게
올라갔습니다.
반면에 레디스는 거의 바닥에 붙어
있습니다. 오프셋이 커져도 응답
시간이 거의 일정하죠. 자, 테스트가
완료되고 결과가 나왔습니다. 오프셋
90만에서 마이스QL은 690ms
레디스는 1.9ms가
나왔습니다. 약 35네배
레디스가 빠르게 결과가 나왔네요. 왜
이런 차이가 날까요? 기본적으로
메모리와 디스크의 속도 차이도
있지만이 테스트 시나리오에서 더 큰
이유는 자료 구조의 차이입니다.
마이스QL은 인덱스가 있어도 오프셋이
90만이면 앞에 90만 개을 세고
건너뛰어야 합니다. 그래서 오프셋이
커질수록 점점 느려지는 거죠.
반면에이 레디스의 솔즈 셋은
내부적으로 스킵 리스트라는 자료
구조를 사용해서 90만 번째든
100만 번째든 바로 점프에서
접근합니다. 그래서 오프셋이 작을
때는 두 세 배 정도 차이가 나지만
오프셋이 점점 커질수록 수백 차이가
벌어지는 거죠. 어 실무에서 더 보기
페이지가 깊어지거나 랭킹 하위건을
조회할 때마 SQL이 느려지는 이유가
바로 이것입니다. 어 이처럼 레디스는
입매모리 기반이라 빠른 것은 물론이고
솔티드 셋과 리스트 그리고 해시와
같은 다양한 자료용을 비즈니스 요건에
맞게 잘 사용하면 큰 성능 이점을
얻을 수 습니다.