Redis의 데이터 타입
String 타입
모두가 대부분 알고 있듯이 자연스럽게 사용하는 String 타입으로 알고 있으면 된다.
Counting 할 때도 사용할 수 있는데 INCR / INCRBY 등
ex) Set num : a 80
INCR num: a 를 통해 증감 연산을 하면 11이 반환된다.
또 INCRBY score:a 5를 이용하여 직접적으로 원하는 값만큼 올려주면 86이 반환된다.
Bitmaps
스트링의 변형이라고 생각하면 되는데 비트구조로 이루어진 자료구조이다.
Bits를 이용하여 counting 할 데이터를 넣을 수 있다.
ex) SETBIT visitors:20210817 3 1 입력하면 0이 반환되고 해당 비트가 채워진다.
그냥 간단하게 엄청 큰 배열을 나열하고 체킹하는 용도로 사용한다고 생각하면 된다.
위와 같은 방법은 저장공간의 절약을 가져올 수 있지만 정수만 카운팅 가능하다.
Lists
기본적인 데이터가 이어져 있는 구조로 큐로 사용하기 편하다.
큐로 사용하기 편하기 때문에 Messaging 상황에서 메시지 큐로 사용하기 적절하다.
자체적 블록킹 기능을 제공하므로 적절하게 사용하면 홀딩 프로세스 기법을 적용할 수 있다.
List에서는 키가 있을 때만 데이터 저장이 가능하기 때문에 이미 캐싱되어 있는 데이터에 추가하는 방법으로도 사용이 가능하다.
Hashes
하나의 key 와 value 구조로 데이터를 넣을 수 있는 구조이다.
전에 간단하게 포스팅한 부분이 있으니 참고해도 좋을 것 같다.
Sets
중복되지 않는 문자열의 집합이다.
Sorted Sets
데이터를 저장할때부터 socore 기준으로 정렬되는 구조
HyperLogLogs
중복되지 않는 값의 갯수를 셀 때 사용한다.
HyperLogLogs도 Counting되는 방법으로 사용할 수 있는데, 대용량 데이터를 카운팅 할 때나 set과 비슷하지만 저장되느 용량은 매우 작은 특성을 가지고 있다.(모두 12KB) 또한 저장된 데이터는 다시 확인할 수 없다.
Streams
로그를 저장하기 가장 좋은 자료구조이다.
append-only 구조이며, 시간 범위로 검색 / 신규 추가 데이터 수신이 가능하다.
Redis로 캐시로 사용했을 때
기본적으로 redis는 같은 데이터를 반복적으로 사용할 때 는 속도 향상을 위해서 캐시로 사용되는 경우가 많다.
평균 작업속도가 1ms 미만으로 가능하게 함으로써 초당 수백만의 작업이 가능하다고 한다.
어플리케이션에 redis를 캐시로 붙인 look-aside 전략(구조)
look-aside 구조에서는 해당 캐시가 존재하면 사용하고 존재하지 않으면 즉 cash-miss가 발생하면 redis에 바인딩한다.
이때 찾는 데이터가 없을 때만 입력되기 때문에 lazy-loading이라고도 한다.
이러한 구조를 이용하면 장애가 생겨도 서버가 다운되지 않고 데이터베이스에서 데이터를 가져올 수 있다.
대신 캐시로 붙어있던 커넥션이 많았다면 DB로 커넥션이 붙기 때문에 DB에 많은 부하가 많아질 수도 있다.
이럴땐 캐시를 새로 투입하거나 디비에만 데이터를 저장했다면 처음엔 cache-miss가 많이 발생하여 캐시 데이터를 올려주는 행동(cache-warming)이 필요하다.
이 같은 경우들은 데이터를 읽을 때 필요한 내용이었다면 데이터를 넣을때의 전략도 필요하다.
위에서 간단하게 말했던 어플리케이션에서 요청한 데이터가 redis 없을때 데이터베이스에서 끌어오는 전략을 사용할 수 있고,
어플리케이션에서 redis에도 저장하고 Database에도 저장하는 방식을 사용할 수 있다.
물론 두번 저장하기 때문에 자원이 낭비가 될 수 있고 속도적인 부분에서 아쉽게 느껴질 수 도 있다.
그래서 리소스 낭비 부분에 대해서는 유효시간을 설정해줘 저장되는데 이것을 설정을 잘못하여 오류가 나는 횟수가 빈번하다.