✅ 키의 자동 생성과 삭제
- 하나의 키가 여러 개의 아이템을 가지고 있는 자료구조 (set, sorted set, hash … )
- 명시적으로 키를 생성하거나 삭제하지 않아도 키는 알아서 생성되고 삭제됨
[공통규칙 1]
[예외]
⚠️ 추가하고자 하는 데이터가 String일 경우, 이전의 자료구조가 무엇이든 아이템 추가하는 것 가능
[공통규칙 2]
💡 모든 아이템을 삭제하면, 키도 자동으로 삭제된다. (Stream 제외)
[공통규칙 3]
💡 키가 없는 상태에서 키 삭제, 아이템 삭제, 읽기 전용 커맨드**(ex.자료구조 크기 조회)**를 수행하면 에러를 반환하는 대신, 키가 있으나 아이템이 없는 것처럼 동작
✅ 키와 관련된 커맨드
- 자료 구조에 상관없이 모든 키에 공통적으로 사용할 수 있는 커맨드
1️⃣ 키의 조회
🍪 EXISTS
키가 존재하는지 확인하는 커맨드
- 키가 존재하면 → 1 반환
- 키가 존재하지 않으면 → 0 반환
🍪 KEYS
레디스에 저장된 모든 키를 조회하는 커맨드
- 매칭되는 패턴에 해당하는 모든 키의 list를 반환
h?llo → hello, hallo 가 매칭 가능 (어떤게와도 상관없지만 한글자임)
h*llo → hllo, heeeello 가 매칭 가능 (어떤게, 몇글자 와도 상관없음)
h[ae]llo → hello, hallo 가 매칭 가능. but, hillo는 매칭 안됨 (해당하는 문자들만)
h[^e]llo 는 hallo, hbllo 매칭가능. but hello는 매칭 안됨. (그 문자 빼고 다)
h[a-b]llo 는 hallo, hbllo 만 매칭 가능. (a에서 b 까지만 가능)
⚠️ 주의사항
🍪 SCAN
KEYS를 대체해 키를 조회할 때 사용할 수 있는 커맨드
- KEYS 는 한번에 모든 키를 반환하는 커맨드로 문제 발생가능성이 있지만, SCAN 커맨드는 커서를 기반으로 특정 범위의 키만 조회할 수 있기 때문에 비교적 안전하게 사용 가능.
- SCAN 했을 때 첫번째로 반환되는 값 → 다음 SCAN 커맨드를 사용할 때 인수로 사용해야하는 커서 위치
- 0이 되면 → 더이상 검색할 키값이 없음 의미
- 기본적으로 한번에 반환되는 키의 개수 : 10개 → COUNT 옵션 쓰면 개수 조정 가능
- BUT, 데이터가 정확하게 count 만큼 출력되지는 않음
- 레디스는 메모리 스캔하면서 → 몇 개 키를 더 읽는 것이 효율적이라 판단하면, 1-2개를 더 읽어 반환함
⚠️ SCAN에서 COUNT 옵션을 너무 크게 설정하면, 한번에 반환되는 값이 많아져서 출력에 오랜 시간이 걸리게 되어 서비스에 영향 줄 수 있음
- MATCH 옵션 : 입력한 패턴에 맞는 키 값을 조회
- BUT 전체에서 조회하는 것이 아니라, 우선 일정 수량만큼 데이터를 가져오고 → 이후에 필터링
- 결과가 원하는 것과 다를 수 있음 (일반적으로 생각하는 검색이 아님)
- TYPE 옵션 : 지정한 타입의 키만 조회할 수 있음.
- MATCH 옵션과 마찬가지로, 사용자에게 반환되기 전에 필터링 되기 때문에 원하던 결과와 다를 수 있음.
- 결과를 찾기 까지 오래 걸릴 수 있음. (커서 단위로 가져오니까)
- MATCH 옵션과 마찬가지로, 사용자에게 반환되기 전에 필터링 되기 때문에 원하던 결과와 다를 수 있음.
🍪 SORT
키 내부의 아이템을 정렬해 반환하는 커맨드
- list, set, sorted set에서만 사용할 수 있음
- LIMIT 옵션 : 일부 데이터만 조회
- ASC/DESC 옵션 : 정렬 순서 변경
- ALPHA 옵션 : 정렬 대상이 문자열인 경우, 사전 순 정렬
- BY & GET 옵션: 정렬한 결과를 이용해 다른 키에 접근해서 데이터를 조회할 수 있음
🍪 RENAME / RENAMENX
키의 이름을 변경하는 커맨드
- RENAMENX 커맨드의 경우, 오직 변경할 키가 존재하지 않을 때에만 동작.
🍪 COPY
Source에 지정된 키를 destination 키에 복사한다.
- destination에 지정한 키가 이미 있는 경우 에러 반환.
- replace 옵션 사용하면, destination 키를 삭제한 뒤 값을 복사하기 때문에 에러 나지 않음.
🍪 TYPE
지정한 키의 자료 구조 타입을 반환
🍪 OBJECT
키에 대한 상세 정보 반환
- subcommand 옵션 : ENCODING, IDLETIME 등이 있음
- 키가 내부적으로 어떻게 저장됐는지, 키가 호출되지 않은 시간이 얼마나 됐는지 확인 가능
2️⃣ 키의 삭제
🍪 FLUSHALL
레디스에 저장된 모든 키를 삭제
- 기본적으로 FLUSHALL 커맨드는 SYNC한 방식으로 동작
- 모든 데이터가 삭제된 경우에만 OK를 반환해서 커맨드가 실행되는 도중에는 다른 응답을 처리할 수 없다.
- ASYNC 옵션을 사용하면 → 백그라운드로 실행
- 커맨드가 수행됐을 때 존재했던 키만 삭제해서, flush되는 중 새로 생성된 키는 삭제되지 않는다.
lazyfree-lazy-user-flush
옵션이 yes인 경우, ASYNC 옵션 없이 사용해도 백그라운드로 키 삭제 작업. (버전 7 기준으로, 해당 옵션의 기본값은 no.)
🍪 DEL
키와 키에 저장된 모든 아이템을 삭제하는 커맨드
- 기본적으로 동기적으로 작동
⚠️ 아이템이 많은 경우, DEL 이 아닌, UNLINK 사용해 데이터 삭제하는 것이 좋음
+) 문제 될 수 있는 부분 → “레디스는 싱글스레드로 동작” 한다.
- 레디스는 싱글스레드로 동작
⚠️ 주의사항
레디스는 싱글 스레드로 동작한다. (정확히는, 메인 스레드 1개와 별도의 스레드 3개) 하지만, 클라이언트의 커맨드를 처리하는 부분은 이벤트 루프를 이용한 싱글 스레드로 동작!
+) 최소 하나의 코어만 있어도 레디스 사용할 수 있어 배포가 쉬움. (CPU가 적은 서버에서도 좋은 성능)
+) 멀티 스레드 애플리케이션에서 요구되는 동기화나 잠금 매커니즘 없이도 안정적이고 빠르게 사용자 요청 처리 가능.
⇒ 레디스는 메모리에서 동작하기 때문에 대부분의 커맨드는 빠른 응답시간.
반환 느린 특정 커맨드가 존재하는데, 이런 커맨드만 주의해서 사용하면 장애 가능성 줄일 수 있음
⇒ BUT, 싱글 스레드로 동작한다는 것은 한 사용자가 오래 걸리는 작업을 수행하면, 다른 사용자는 그 쿼리가 완료될 때까지 대기할 수 밖에 없는 것.
🍪 UNLINK
데이터를 삭제하는 커맨드.
- 백그라운드에서 다른 스레드에 의해 처리. 우선 키와 연결된 데이터의 연결을 끊는다.
- set, sorted set 과 같이 하나의 키에 여러개의 아이템이 저장된 자료구조
- 한 개의 키를 삭제하는 DEL 커맨드 → 레디스 인스턴스에 영향 끼칠 가능성 O
- ex) 100만개의 아이템이 저장돼있는 sorted set 키를 DEL 커맨드로 삭제한다?
- 레디스에서 동기적인 방식으로 FLUSH ALL을 수행하는 것과 같음.
- 수행되는 시간동안 다른 클라이언트는 아무런 커맨드를 사용할 수 없음.
lazyfree-lazy-user-del
옵션이 yes일 경우, 모든 DEL 커맨드는 UNLINK 로 동작해 백그라운드로 키를 삭제. (버전 7 기준으로, 해당 옵션의 기본값은 no.)
3️⃣ 키의 만료 시간
🍪 EXPIRE
키가 만료될 시간을 초단위로 정의
- NX 옵션 : 해당 키에 만료시간이 정의돼 있지 않을 경우에만 수행
- XX 옵션 : 해당 키에 만료시간이 정의돼 있을 때에만 수행
- GT 옵션 : 현재 키가 가지고 있는 만료시간 보다 새로 입력한 초가 더 클 때에만 수행
- LT 옵션 : 현재 키가 가지고 있는 만료시간 보다 새로 입력한 초가 더 작을 때에만 수행
🍪 EXPIREAT
키가 특정 유닉스 타임스탬프에 만료될 수 있도록 키의 만료 시간을 직접 지정
- 사용할 수 있는 옵션은 EXPIRE와 동일
🍪 EXPIRETIME
키가 삭제되는 유닉스 타임스탬프를 초 단위로 반환
- 키가 존재하지만 만료시간 설정돼 있지 않을 경우 → -1 반환
- 키가 없을 때 → -2 반환
🍪 TTL
키가 몇 초 뒤에 만료되는지 반환
- 키가 존재하지만 만료시간 설정돼 있지 않을 경우 → -1 반환
- 키가 없을 때 → -2 반환
🍪 PEXPIRE, PEXPIREAT, PEXPIRETIME, PTTL
⇒ 밀리초 단위로 계산된다는 점만 다르고, EXPIRE, EXPRIEAT, EXPIRETIME과 동일하게 작동
'TIL' 카테고리의 다른 글
[TIL] 분산락 (3) | 2024.10.21 |
---|---|
[k8s] Ingress SSL 적용 (0) | 2024.10.06 |
[TIL] 낙관적 락, 비관적 락 (0) | 2024.09.09 |
[TIL] 페이지 교체 알고리즘 (1) | 2024.09.02 |
[TIL] 네트워크 기본 정리 (0) | 2024.08.26 |