|
| 1 | +# Redis Data Type 이해 |
| 2 | + |
| 3 | +## Strings |
| 4 | + |
| 5 | +- 가장 기본적인 데이터 타입으로 제일 많이 사용됨 |
| 6 | +- 바이트 배열을 저장(binary-safe) |
| 7 | +- **바이너리로 변환할 수 있는 모든 데이터를 저장 가능**(JPG와 같은 파일 등) |
| 8 | +- **최대 크기는 512MB** |
| 9 | +- 주요 명령어 |
| 10 | + - SET |
| 11 | + - 특정 키에 문자열 값을 저장 |
| 12 | + - `SET key1 value1` |
| 13 | + - GET |
| 14 | + - 특정 키의 문자열 값을 조회 |
| 15 | + - `GET key1` |
| 16 | + - INCR |
| 17 | + - 특정 키의 값을 Integer로 취급하여 1증가 |
| 18 | + - **atomic 지원 = race condition에 걸리지 않음 동시성 문제가 없다** |
| 19 | + - `INCR mycount` |
| 20 | + - DECR |
| 21 | + - 특정 키의 값을 Integer로 취급하여 1증가 |
| 22 | + - **atomic 지원 = race condition에 걸리지 않음 동시성 문제가 없다** |
| 23 | + - `DECR mycount` |
| 24 | + - MSET |
| 25 | + - 여러 키에 대한 값을 한번에 저장 (bulk) |
| 26 | + - `MSET key3 value3 key4 value4` |
| 27 | + - MGET |
| 28 | + - 여러 키에 대한 값을 한번에 조회 |
| 29 | + - `MGET key3 key4` |
| 30 | + |
| 31 | +## Lists |
| 32 | + |
| 33 | +- Linked-list 형태의 자료구조(인덱스 접근은 느리지만 데이터 add/delete 가 빠름) |
| 34 | +- Queue, Stack으로 활용 가능 |
| 35 | +- 양쪽 끝을 기준으로 데이터를 수정할 수 있음 |
| 36 | +- 명령어 |
| 37 | + - LPUSH, RPUSH |
| 38 | + - 리스트의 left, right에 새로운 값을 추가 |
| 39 | + - `LPUSH mylist value1` |
| 40 | + - `RPUSH mylist value2` |
| 41 | + - LLEN |
| 42 | + - 리스트에 저장된 아이템 개수를 반환 |
| 43 | + - `LLEN mylist` |
| 44 | + - LRANGE |
| 45 | + - 리스트의 특정 범위를 반환 |
| 46 | + - `LRANGE mylist 0 -1` |
| 47 | + - -1은 마지막부터 첫번쨰 |
| 48 | + - LPOP, RPOP |
| 49 | + - 리스트의 left, right에서 값을 삭제하고 반환(pop) |
| 50 | + - `LPOP mylist` |
| 51 | + - `RPOP mylist` |
| 52 | + |
| 53 | +## Sets |
| 54 | + |
| 55 | +- 순서가 없는 유니크한 값의 집합 |
| 56 | +- 검색이 빠름 |
| 57 | +- 개별 접근을 위한 인덱스가 존재하지 않음 |
| 58 | +- 집한 연산이 가능(교집합, 합집합 등) |
| 59 | + - **단순히 데이터 존재 여부를 확인하는 용도로 쿠폰 발급 여부 등에 활용할 수 있음** |
| 60 | +- 명령어 |
| 61 | + - SADD |
| 62 | + - SET에 데이터 추가 |
| 63 | + - `SADD myset v1` |
| 64 | + - SREM |
| 65 | + - SET에서 데이터를 삭제 |
| 66 | + - `SREM myset v1` |
| 67 | + - SCARD |
| 68 | + - SET에 저장된 아이템 개수를 반환 |
| 69 | + - `SCARD myset` |
| 70 | + - SMEMBERS |
| 71 | + - Set에 저장된 아이템들을 반환 |
| 72 | + - `SMEMBERS myset` |
| 73 | + - SISMEMBER |
| 74 | + - SET에 특정 값이 포함되어 있는지 여부를 반환 |
| 75 | + - `SISMEMBER myset v1` |
| 76 | + |
| 77 | +## Hashes |
| 78 | + |
| 79 | +- 하나의 key 하위에 여러개의 field-value 쌍을 저장 |
| 80 | +- 여러 필드를 가진 객체를 저장하는 것으로 볼 수 있음 |
| 81 | +- HINCRBY 명령어를 사용해 카운터로 활용 가능 |
| 82 | +- 명령어 |
| 83 | + - HSET |
| 84 | + - 한개 또는 다수의 필드에 값을 저장 |
| 85 | + - `HSET user1 name mokhs age 10` |
| 86 | + - HGET |
| 87 | + - 특정 필드의 값을 반환 |
| 88 | + - `HGET user1 name` |
| 89 | + - HMGET |
| 90 | + - 한개 이상의 필드 값을 반환 |
| 91 | + - `HMGET user1` |
| 92 | + - HINCRBY |
| 93 | + - 특정 필드의 값을 integer로 취급하여 숫자 증가 INCR 명령어와 같음 |
| 94 | + - `HINCRBY user1 viewcount 1` |
| 95 | + - HDEL |
| 96 | + - 한개 이상의 필드를 삭제 |
| 97 | + - `HDEL user1 name age` |
| 98 | + - HKEYS |
| 99 | + - 특정 키 값의 모든 필드 조회 |
| 100 | + - `HKEYS user1` |
| 101 | + |
| 102 | +## Sorted Sets |
| 103 | + |
| 104 | +- Set과 유사하게 유니크한 값의 집합 |
| 105 | +- score를 가지고 정렬되어 있음 |
| 106 | +- 정렬된 상태이기에 빠르게 최소/최대값을 구할 수 있음 |
| 107 | +- 순위 계산, 리더보드 구현 등에 활용 |
| 108 | + - user1 (score: 10) |
| 109 | + - user2 (score: 20) |
| 110 | +- 명령어 |
| 111 | + - ZADD |
| 112 | + - 한 개 또는 다수의 값을 추가 또는 업데이트 |
| 113 | + - `ZADD myrank 10 user1 20 user2` |
| 114 | + - ZRANGE |
| 115 | + - 특정 범위의 값을 반환(오름차순으로 정렬된 기준) |
| 116 | + - `ZRANGE myrank 0 1` |
| 117 | + - ZRANK |
| 118 | + - 특정 값의 위치(순위)를 반환(오름차순 정렬 기준) |
| 119 | + - `ZRANK myrank user1` |
| 120 | + - ZREVRANK |
| 121 | + - 특정 값의 위치(순위)를 반환 (내림차순 기준) |
| 122 | + - `ZREVRANK myrank user1` |
| 123 | + - ZREM |
| 124 | + - 한 개 이상의 값을 삭제 |
| 125 | + - `ZREM myrank user1` |
| 126 | + |
| 127 | +## Bitmaps |
| 128 | + |
| 129 | +- 비트 벡터를 사용해 N개의 Set을 공간 효율적으로 저장 |
| 130 | +- 하나의 비트맵이 가지는 공간은 약 42억(2^32-1) |
| 131 | +- 비트 연산 가능 |
| 132 | +- 유저의 방문 현황 같은 경우 integer와 같은 4바이트 크기로 42억 명의 방문 여부를 저장할 수 있음 |
| 133 | +- 명령어 |
| 134 | + - SETBIT |
| 135 | + - 비트맵의 특정 오프셋에 값을 변경 |
| 136 | + - `SETBIT visit 10 1` |
| 137 | + - GETBIT |
| 138 | + - 비트맵의 특정 오프셋의 값을 반환 |
| 139 | + - `GETBIT visit 10` |
| 140 | + - BITCOUNT |
| 141 | + - 비트맵에서 set(1) 상태인 비트의 개수를 반환 |
| 142 | + - `BITCOUNT visit` |
| 143 | + - BITOP |
| 144 | + - 비트맵들간의 비트 연산을 수행하고 결과를 비트맵에 저장 |
| 145 | + - BITOP (비트연산) (결과) (연산 대상…) |
| 146 | + - `BITOP AND result today yesterday` |
| 147 | + |
| 148 | +## HyperLogLog |
| 149 | + |
| 150 | +- 대용량 데이터에 대해서 유니크한 값의 개수를 효율적으로 얻을 수 있음 |
| 151 | + - 단순 카운팅을 위한 자료구조 |
| 152 | + - 2^64개의 유니크 값을 계산 가능 |
| 153 | +- Bitmaps는 userID 등 측정 offset을 활용해야 하지만 HyperLogLog는 문자열을 활용할 수 있음 |
| 154 | +- 확률적 자료구조로서 오차가 있으며, 매우 큰 데이터를 다룰 때 사용 |
| 155 | + - 값을 추가한다고 그 값이 그대로 실제로 저장되는 건 아니고 확률적 자료구조의 데이터 일부가 됨 |
| 156 | +- 12KB까지 메모리를 사용하며 0.81%의 오차율을 허용 |
| 157 | +- 명령어 |
| 158 | + - PFADD |
| 159 | + - HyperLogLog에 값들을 추가 |
| 160 | + - `PFADD visit Jay Peter Jane` |
| 161 | + - PFCOUNT |
| 162 | + - HyperLogLog에 입력된 값들의 cardinality(유일값의 수)를 반환 |
| 163 | + - `PFCOUNT visit` |
| 164 | + - PFMERGE |
| 165 | + - 다수의 HyperLogLog를 병합 |
| 166 | + - `PFMERGE result visit1 visit2` |
0 commit comments