[Redis] KEYS는 Key의 위험성과 SCAN의 안전한 대응을 획득합니다.

4315 단어 scanRedisKeysRails
가능한 한 레드스 중KEYS의 위험성과 SCAN의 대응 방법을 간결하게 소개한다.

이른바 Redis, KEYS


※ 아는 사람은 건너뛰셔도 됩니다
Redis는 KVS형(Key Value Store) 데이터베이스 중 하나로, 오픈 소스(BSD 라이센스)의 메모리 데이터 구조 저장소(저장소가 아닌 메인 메모리로 처리)다.내가 아는 바에 의하면, 주로 인터넷에서 흔히 볼 수 있는 캐시를 저장하는 데 쓰인다.
구조가 매우 간단하여 한 쌍Key에 한 쌍Value이 있다.

캐시를 사용할 때 키는 '페이지 위젯의 URL' 을 저장하고, 밸류는 'CSS 및 자바스크립트 등' 을 저장합니다.KEYS는 특정 패턴에 맞는 키를 검색하는 방법Redis(KEYS)이다.모든 키와 모델을 비교하기 위해 시간 계산량은 O(N)(N은 데이터베이스에 있는 키의 수량)이다.즉 계산량이 저장된 키의 수량에 직접적인 영향을 미친다는 것이다.
다음은 KEYS 명령의 예입니다.
redis> KEYS *name*
1) "lastname"
2) "firstname"

redis> KEYS a??
1) "age"

redis> KEYS *
1) "age"
2) "lastname"
3) "firstname"

KEYS 전체 검색의 위험


While the time complexity for this operation is O(N), the constant times are fairly low. For example, Redis running on an entry level laptop can scan a 1 million key database in 40 milliseconds.
공식 참조Redis(KEYS)에서 보듯이 단순 참조의 처리 속도는 매우 빠르다.
문제는 저장된 키 수가 방대한'수백만, 수천만'상황에서 발생했다.그 비극의 순서는 다음과 같다.

1. KEYS의 반응이 너무 길어서 어떤 내용도 회답할 수 없다


Redis 서버는 기본적으로 단일 처리만 가능한 단일 열 빨간색입니다.따라서'수백만, 수천만'이라는 방대한 건수를 참조하면 처리가 끝날 때까지 회답을 할 수 없다.

2. 다른 Redis에 대한 GET 요청 등으로 막힘


레디스가'수백만, 수천만'건수를 거듭 참조할 때도 레디스 서버에 대한 요구는 꾸준히 늘고 있다.그나저나 레디스가 멀티스레드(단식홍의 반대는 병행처리 가능)라면 한 가지 무거운 요구가 있어도 가벼운 처리가 하나둘씩 호응하기 때문에 최소한의 동작은 가능하다(이후 상세히 소개).

3. 리디스의 회신을 기대하는 앱 사이드(Rails 등) 막힘


Redis가 응답에 장시간 응답할 수 없기 때문에 응용 프로그램에서 아무것도 할 수 없는 시간이 늘어나 막힐 수밖에 없다.

4. 요청에 응답할 수 없습니다. 최악의 경우 서버가 다운됩니다.


응답 시간이 증가하면 서버에 대한 부하도 증가합니다.결과적으로 사용자의 요구에 많은 시간이 걸렸고 최악의 경우 서버가 고부하로 떨어질 위험성이 높아졌다.
그나저나 이런 위험성을 고려해 공식 참고로도 추천하지 않는다.
Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code. If you're looking for a way to find keys in a subset of your keyspace, consider using SCAN or sets.

SCAN에서 커서를 기준으로 참조

KEYS에서 키의 위험성을 얻는다는 것을 알면서도 해결책을 생각해야 한다.
방금 가볍게 건드린 것처럼 다선정이면 무거운 부탁 하나만 있어도 막히지 않는다.그러나 그것은 사실상 불가능하기 때문에 다른 방법을 고려할 것이다.이것은 정부에서도 추천한 SCAN 방법이다.SCANKEYS와 마찬가지로 검색 모드가 일치하는 키의 방법이다.SCAN의 피쳐는 커서를 기준으로 참조됩니다.이렇게 되면 통일적으로 인용하지 않고 분할적으로 인용할 수 있다.여기서 설명한 커서는 다음 참조 위치를 나타내는 커서이며 다음 커서(참조 끝)가 없으면 0으로 돌아갑니다.상세 정보Redis(SCAN).SCAN 명령의 예.
redis> scan 0
1) "17"
2)  1) "key:12"
    2) "key:8"
    3) "key:4"
    4) "key:14"
    5) "key:16"
    6) "key:17"
    7) "key:15"
    8) "key:10"
    9) "key:3"
   10) "key:7"
   11) "key:1"

redis> scan 17
1) "0"
2) 1) "key:5"
   2) "key:18"
   3) "key:0"
   4) "key:2"
   5) "key:19"
   6) "key:13"
   7) "key:6"
   8) "key:9"
   9) "key:11"
프로그램이 실행될 때 커서가 '0' 으로 바뀌기 전 (참조가 끝나기 전) SCAN 반복 요청합니다.

끝맺다


리디스 자체의 데이터 구조는 간단하지만, 조사를 통한 내부 처리도 위험성이 많아 흥미롭다.
질문과 편집 요구가 있으면 메시지를 남겨주세요.

Greeting late


이것은 내가 장기 실습을 시작한 두 번째 달@TsuboyaTaiki이다.
현재 Rails 응용 프로그램에서 Redis 서버의 캐시 주위의 수정 isse를 사용합니다.이 과정에서 SCANKEYS 등 가치 검색에 대해 많이 알고 적어 봤습니다.

좋은 웹페이지 즐겨찾기