Redis O(N) 문제와 대응: SCAN 명령어로 효율적으로 데이터 조회하기

카카오 테크 캠퍼스에서 트래픽이 몰리는 경우를 대비하기 위한 ‘레디스’라는 개념을 봤다. 몰라서 찾아보았는데, 엄청난 것이었다.

해피쿠 블로그 - [Redis] 인-메모리 데이터베이스 Redis

해피쿠 블로그 - [Redis] 인-메모리 데이터베이스 Redis

이 블로그의 내용이 첫 이해에 정~~말 많이 도움이 됐다.

 

Redis는 DBMS(DataBase Management System)인데, 메모리 기반 DBMS이다.

 

보통 Session Management, Look aside Cache, Write Bach 목적으로 사용된다고 하는데, 해당 설명은 블로그에 너무 쉽고 잘 설명되어 있어서 다루지 않는다. 나중에 직접 구현할 때 정리해 두면 좋을 것 같긴 하다.

---

검색하다 보니, O(N) 실행속도의 명령어들을 조심해서 사용하라는 내용을 지속해서 봤다. 따라서 이 부분에 대해 찾아보고 정리할 것이다.

 

알고리즘 문제를 풀어보면서 O(N) 보다 속도가 빠른 것은 O(log n)과 O(1) 밖에 없었다. 전자의 가장 흔한 예시는 이분탐색이 있겠고, 후자의 가장 흔한 예시는 push, pop 정도?

아무튼 내 상식상 O(N)이 걸리는 작업은 결국 O(N)에 걸쳐서 해결해야 하는 것 아닌가 싶었다.

SCAN

O(N)의 속도를 가진 KEYS는 모든 키를 검색하는 명령어이다. 원하는 패턴과 일치하는 모든 키를 찾을 때 사용이 되는데, 결국 하나씩 전부 확인하며 찾아야 해서, O(N)의 속도를 가질 수밖에 없다.

 

Redis는 Single Thread로 동시에 딱!!! 하나의 명령만 처리할 수 있기에, KEYS와 같이 긴 시간이 필요한 명령을 수행하다보면 터진다. 뒤의 명령이 밀리도록 하면 안 된다.

대표적인 O(N) 명령은 KEYS, FLUSHALL, FLUSHDB, Delete Collections, Get All Collections로,

아이템의 N이 적다면, 당연히 문제가 되지 않는다. 근데 아이템이 많다면 위에서 말한 문제가 터지기 시작한다.

 

SCAN 명령은 KEYS와 비슷한데, 짧은 명령을 많이 보내는 것이다.

명령과 명령 사이에 다른 O(1) 짜리 짧은 명령어 수천, 수만개씩을 처리할 수 있기 때문에 터지지 않도록 방지할 수 있다.

 

Collection의 모든 item을 가져와야 하는 상황을 대비하기 위해서는 애초에 Collection을 작은 여러 개의 Collections로 나눠서 저장하면 좋다.

그렇게 하나씩 가져오면 좋다.

 

redis KEYS 공식문서

KEYS

KEYS vs SCAN stackoverflow

SCAN vs KEYS performance in Redis