s00ng
쏭's blog
s00ng
전체 방문자
오늘
어제
  • 분류 전체보기 (69)
    • TIL (20)
      • 실습 (3)
    • Web (6)
      • React (6)
      • Basic (0)
    • JPA (5)
    • CS (3)
      • 컴퓨터 네트워크 (3)
    • Design pattern (10)
    • AWS (5)
    • ETC (0)
    • Algorithm (0)
    • Project (3)

블로그 메뉴

  • 홈
  • 태그
  • 방명록
  • 글쓰기

공지사항

인기 글

태그

  • centOS 8
  • VMware
  • solid
  • 가용영역
  • design pattern
  • EC2 인스턴스
  • mariaDB
  • AWS
  • 리전
  • EC2

최근 댓글

최근 글

티스토리

hELLO · Designed By 정상우.
s00ng

쏭's blog

TIL

[TIL] Redis에서 키를 관리하는 법

2024. 9. 23. 00:58

✅ 키의 자동 생성과 삭제

  • 하나의 키가 여러 개의 아이템을 가지고 있는 자료구조 (set, sorted set, hash … )
    • 명시적으로 키를 생성하거나 삭제하지 않아도 키는 알아서 생성되고 삭제됨

 

[공통규칙 1]

💡 키가 존재하지 않을 때, 아이템을 넣으면 아이템을 삽입하기 전에 빈 자료구조를 생성한다.

 

💡 저장하고자 하는 키에 다른 자료구조가 이미 생성돼 있을 때, 아이템을 추가하는 작업은 에러를 반환한다.

 

 

[예외]

⚠️ 추가하고자 하는 데이터가 String일 경우, 이전의 자료구조가 무엇이든 아이템 추가하는 것 가능

 

 

 

[공통규칙 2]

💡 모든 아이템을 삭제하면, 키도 자동으로 삭제된다. (Stream 제외)

 

[공통규칙 3]

💡 키가 없는 상태에서 키 삭제, 아이템 삭제, 읽기 전용 커맨드**(ex.자료구조 크기 조회)**를 수행하면 에러를 반환하는 대신, 키가 있으나 아이템이 없는 것처럼 동작

 

 

✅ 키와 관련된 커맨드

  • 자료 구조에 상관없이 모든 키에 공통적으로 사용할 수 있는 커맨드

 

1️⃣ 키의 조회

🍪 EXISTS

키가 존재하는지 확인하는 커맨드

👉 EXISTS key [key …]
  • 키가 존재하면 → 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를 대체해 키를 조회할 때 사용할 수 있는 커맨드

👉 SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]
  • KEYS 는 한번에 모든 키를 반환하는 커맨드로 문제 발생가능성이 있지만, SCAN 커맨드는 커서를 기반으로 특정 범위의 키만 조회할 수 있기 때문에 비교적 안전하게 사용 가능.
  • SCAN 했을 때 첫번째로 반환되는 값 → 다음 SCAN 커맨드를 사용할 때 인수로 사용해야하는 커서 위치
    • 0이 되면 → 더이상 검색할 키값이 없음 의미
  • 기본적으로 한번에 반환되는 키의 개수 : 10개 → COUNT 옵션 쓰면 개수 조정 가능
    • BUT, 데이터가 정확하게 count 만큼 출력되지는 않음
    • 레디스는 메모리 스캔하면서 → 몇 개 키를 더 읽는 것이 효율적이라 판단하면, 1-2개를 더 읽어 반환함
⚠️ SCAN에서 COUNT 옵션을 너무 크게 설정하면, 한번에 반환되는 값이 많아져서 출력에 오랜 시간이 걸리게 되어 서비스에 영향 줄 수 있음
  • MATCH 옵션 : 입력한 패턴에 맞는 키 값을 조회
    • BUT 전체에서 조회하는 것이 아니라, 우선 일정 수량만큼 데이터를 가져오고 → 이후에 필터링
    • 결과가 원하는 것과 다를 수 있음 (일반적으로 생각하는 검색이 아님)
  • TYPE 옵션 : 지정한 타입의 키만 조회할 수 있음.
    • MATCH 옵션과 마찬가지로, 사용자에게 반환되기 전에 필터링 되기 때문에 원하던 결과와 다를 수 있음.
      • 결과를 찾기 까지 오래 걸릴 수 있음. (커서 단위로 가져오니까)

 

🍪 SORT

키 내부의 아이템을 정렬해 반환하는 커맨드

  • list, set, sorted set에서만 사용할 수 있음
👉 SORT key [By pattern] [LIMIT offset count] [GET pattern [GET pattern …]] [ ASC | DESC ] [ALPHA] [STORE desination]
  • LIMIT 옵션 : 일부 데이터만 조회
  • ASC/DESC 옵션 : 정렬 순서 변경
  • ALPHA 옵션 : 정렬 대상이 문자열인 경우, 사전 순 정렬
  • BY & GET 옵션: 정렬한 결과를 이용해 다른 키에 접근해서 데이터를 조회할 수 있음

 

🍪 RENAME / RENAMENX

키의 이름을 변경하는 커맨드

  • RENAMENX 커맨드의 경우, 오직 변경할 키가 존재하지 않을 때에만 동작.
👉 RENAME key RENAMENX key

 

🍪 COPY

Source에 지정된 키를 destination 키에 복사한다.

👉 COPY source destination [DB destination-db] [REPLACE]
  • destination에 지정한 키가 이미 있는 경우 에러 반환. 
  • replace 옵션 사용하면, destination 키를 삭제한 뒤 값을 복사하기 때문에 에러 나지 않음.

 

🍪 TYPE

지정한 키의 자료 구조 타입을 반환

👉 TYPE key

 

 

🍪 OBJECT

키에 대한 상세 정보 반환

👉 OBJECT [ [value] [opt] …]
  • subcommand 옵션 : ENCODING, IDLETIME 등이 있음
  • 키가 내부적으로 어떻게 저장됐는지, 키가 호출되지 않은 시간이 얼마나 됐는지 확인 가능

 

2️⃣ 키의 삭제

🍪 FLUSHALL

레디스에 저장된 모든 키를 삭제

👉 FLUSHALL [ASYNC | SYNC]
  • 기본적으로 FLUSHALL 커맨드는 SYNC한 방식으로 동작
    • 모든 데이터가 삭제된 경우에만 OK를 반환해서 커맨드가 실행되는 도중에는 다른 응답을 처리할 수 없다.
  • ASYNC 옵션을 사용하면 → 백그라운드로 실행
    • 커맨드가 수행됐을 때 존재했던 키만 삭제해서, flush되는 중 새로 생성된 키는 삭제되지 않는다.
  • lazyfree-lazy-user-flush 옵션이 yes인 경우, ASYNC 옵션 없이 사용해도 백그라운드로 키 삭제 작업. (버전 7 기준으로, 해당 옵션의 기본값은 no.)

 

🍪 DEL

키와 키에 저장된 모든 아이템을 삭제하는 커맨드

  • 기본적으로 동기적으로 작동
👉 DEL key [key …]

⚠️ 아이템이 많은 경우, DEL 이 아닌, UNLINK 사용해 데이터 삭제하는 것이 좋음

+) 문제 될 수 있는 부분 → “레디스는 싱글스레드로 동작” 한다.

  • 레디스는 싱글스레드로 동작 
⚠️ 주의사항
레디스는 싱글 스레드로 동작한다. (정확히는, 메인 스레드 1개와 별도의 스레드 3개) 하지만, 클라이언트의 커맨드를 처리하는 부분은 이벤트 루프를 이용한 싱글 스레드로 동작!
+) 최소 하나의 코어만 있어도 레디스 사용할 수 있어 배포가 쉬움. (CPU가 적은 서버에서도 좋은 성능)
+) 멀티 스레드 애플리케이션에서 요구되는 동기화나 잠금 매커니즘 없이도 안정적이고 빠르게 사용자 요청 처리 가능.
⇒ 레디스는 메모리에서 동작하기 때문에 대부분의 커맨드는 빠른 응답시간.
반환 느린 특정 커맨드가 존재하는데, 이런 커맨드만 주의해서 사용하면 장애 가능성 줄일 수 있음
⇒ BUT, 싱글 스레드로 동작한다는 것은 한 사용자가 오래 걸리는 작업을 수행하면, 다른 사용자는 그 쿼리가 완료될 때까지 대기할 수 밖에 없는 것.

 

🍪 UNLINK

데이터를 삭제하는 커맨드.

👉 UNLINK key [key …]
  • 백그라운드에서 다른 스레드에 의해 처리. 우선 키와 연결된 데이터의 연결을 끊는다.
  • set, sorted set 과 같이 하나의 키에 여러개의 아이템이 저장된 자료구조
    • 한 개의 키를 삭제하는 DEL 커맨드 → 레디스 인스턴스에 영향 끼칠 가능성 O
    • ex) 100만개의 아이템이 저장돼있는 sorted set 키를 DEL 커맨드로 삭제한다?
      • 레디스에서 동기적인 방식으로 FLUSH ALL을 수행하는 것과 같음.
      • 수행되는 시간동안 다른 클라이언트는 아무런 커맨드를 사용할 수 없음.
  • lazyfree-lazy-user-del 옵션이 yes일 경우, 모든 DEL 커맨드는 UNLINK 로 동작해 백그라운드로 키를 삭제. (버전 7 기준으로, 해당 옵션의 기본값은 no.)

 

3️⃣ 키의 만료 시간

🍪 EXPIRE

키가 만료될 시간을 초단위로 정의

👉 EXPIRE key seconds [NX | XX | GT | LT]
  • NX 옵션 : 해당 키에 만료시간이 정의돼 있지 않을 경우에만 수행
  • XX 옵션 : 해당 키에 만료시간이 정의돼 있을 때에만 수행
  • GT 옵션 : 현재 키가 가지고 있는 만료시간 보다 새로 입력한 초가 더 클 때에만 수행
  • LT 옵션 : 현재 키가 가지고 있는 만료시간 보다 새로 입력한 초가 더 작을 때에만 수행

🍪 EXPIREAT

키가 특정 유닉스 타임스탬프에 만료될 수 있도록 키의 만료 시간을 직접 지정

  • 사용할 수 있는 옵션은 EXPIRE와 동일
👉 EXPIREAT key unix-time-seconds [NX | XX | GT | LT]

 

🍪 EXPIRETIME

키가 삭제되는 유닉스 타임스탬프를 초 단위로 반환

👉 EXPIRETIME key
  • 키가 존재하지만 만료시간 설정돼 있지 않을 경우 → -1 반환
  • 키가 없을 때 → -2 반환

 

🍪 TTL

키가 몇 초 뒤에 만료되는지 반환

👉 TTL key
  • 키가 존재하지만 만료시간 설정돼 있지 않을 경우 → -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
    'TIL' 카테고리의 다른 글
    • [TIL] 분산락
    • [k8s] Ingress SSL 적용
    • [TIL] 낙관적 락, 비관적 락
    • [TIL] 페이지 교체 알고리즘
    s00ng
    s00ng

    티스토리툴바