본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
강의 요약
오늘은 Redis의 특수 목적 데이터 타입인 Sorted Set, Geospatial, Bitmap에 대해 학습했다. 어제 학습한 List, Set, Hash가 범용적인 컬렉션 타입이었다면, 오늘 다룬 타입들은 순위 계산, 위치 기반 검색, 대규모 플래그 관리 등 특정 도메인에 최적화된 자료구조다. 마찬가지로 강의에서는 주로 기본 명령어와 실습 위주로 진행되었고, 내부 구조와 시간 복잡도, 실무 적용 시 주의점은 Redis 공식 문서를 참고하여 추가 정리했다.
Sorted Set (ZSet)
Sorted Set은 중복 없는 요소들에 대해 정렬 기준(score)을 함께 부여하는 자료구조다. 값은 고유하고, 정렬은 float64 타입의 점수에 따라 자동 유지된다. Set과 Hash의 특성을 결합한 형태로, 내부적으로 순서를 갖는 우선순위 큐와 유사하다.
내부 구조: skiplist + hashtable
- 내부적으로는 두 구조를 별도로 유지하며, 서로를 보완하는 방식으로 동시에 사용
- skiplit는 평균적으로 O(log n) 범위 탐색/삽입 성능을 제공하고, Hash는 O(1)로 값 존재 여부 및 점수 조회를 처리한다.
Redis 버전 인코딩 설명
| <= 6.2 | ziplist | 작은 Sorted Set에 대한 공간 효율적 인코딩 |
| >= 7.0 | listpack | ziplist 개선 버전, 더 컴팩트한 구조 |
| 모든 버전 | skiplist | 일반적인 경우 |
주요 연산 및 시간 복잡도
| 연산 | 시간 복잡도 | 설명 |
| ZADD | O(log N) | 요소 추가 |
| ZREM | O(M*log N) | 요소 제거 (M: 제거할 요소 수) |
| ZSCORE | O(1) | 점수 조회 |
| ZRANK / ZREVRANK | O(log N) | 순위 조회 |
| ZRANGE | O(log N + M) | 범위 조회 (M: 반환 요소 수) |
| ZRANGEBYSCORE | O(log N + M) | 점수 기반 범위 조회 |
| ZCARD | O(1) | 요소 개수 |
| ZCOUNT | O(log N) | 점수 범위 내 요소 수 |
| ZINCRBY | O(log N) | 점수 증가 |
- 대부분의 정렬된 집합 연산은 O(log(n)) 시간 복잡도를 가진다.
- ZRANGE 명령어를 대규모(수만 개 이상) 반환 값과 함께 실행할 때는 주의가 필요하다.
- 시간 복잡도는 O(log(n) + m)이며, 여기서 m은 반환되는 결과의 개수
활용 정리
점수 기반 정렬된 집합으로 순위, 통계, 타임라인 등에 적합하다.
- 랭킹 시스템: 점수를 기준으로 정렬 (ZADD, ZRANGE)
- 최근순 정렬: timestamp를 score로 사용
- 데이터 제한: ZREMRANGEBYRANK, ZREMRANGEBYSCORE로 오래된 항목 정리
- 통계 집계: ZUNIONSTORE(합집합), ZINTERSTORE(교집합)로 집계 처리 가능
Geospatial
Redis Geospatial은 좌표를 저장하고 반경 또는 경계 상자 내에서 검색할 수 있게 해주는 인덱스다. 내부적으로 Sorted Set을 기반으로 구현되어 있으며, 좌표를 Geohash로 인코딩하여 score로 저장한다.
내부 구조
- Geospatial 타입은 독립적인 자료구조가 아니라 Sorted Set 위에 구축된 추상화 계층이다.
- 따라서 OBJECT ENCODING으로 확인하면 skiplist 또는 listpack으로 표시된다.
주요 연산 및 시간 복잡도
| 연산 | 시간 복잡도 | 설명 |
| GEOADD | O(log N) per item | 위치 추가 |
| GEOPOS | O(1) | 좌표 조회 |
| GEODIST | O(1) | 두 멤버 간 거리 |
| GEOSEARCH | O(N+log M) | 반경/박스 내 검색 (N: 결과 수, M: 전체 요소) |
| GEOHASH | O(1) | Geohash 문자열 반환 |
활용 정리
위치 기반 서비스에서 주변 검색이 필요한 경우 유용하다. 단, Redis Query Engine의 Geospatial 기능과는 별개이며, 더 복잡한 쿼리나 다양한 포맷이 필요하다면 Redis Query Engine 사용을 고려해야 한다.
- 주변 매장/시설 검색: GEOSEARCH로 반경 내 위치 조회
- 거리 계산: GEODIST로 두 지점 간 거리 측정
- 단순 위치 저장: 복잡한 GIS 기능이 필요 없는 경우 적합
Bitmap
Bitmap은 독립적인 데이터 타입이 아니라 String 타입 위에 정의된 비트 지향 연산 집합이다. String이 최대 512MB까지 지원하므로, 최대 2^32개의 비트를 설정할 수 있다. 각 비트가 특정 상태를 나타내는 경우 메모리를 극도로 절약할 수 있다.
내부 구조
- Bitmap은 String의 인코딩을 그대로 따른다.
인코딩 설명
| raw | 일반 문자열 인코딩 |
| embstr | 44바이트 이하의 작은 문자열에 대한 최적화 인코딩 |
주요 연산 및 시간 복잡도
| 연산 | 시간 복잡도 | 설명 |
| SETBIT | O(1) | 특정 오프셋의 비트 설정 |
| GETBIT | O(1) | 특정 오프셋의 비트 조회 |
| BITCOUNT | O(N) | 1로 설정된 비트 수 |
| BITPOS | O(N) | 첫 번째 0 또는 1 비트 위치 |
| BITOP | O(N) | 비트 연산 (AND, OR, XOR, NOT 등) |
- 단일 비트 연산(SETBIT, GETBIT)은 O(1)이지만, BITCOUNT, BITPOS, BITOP 등 그룹 연산은 O(N)이므로 대용량 비트맵에서 주의가 필요하다.
활용 정리
대규모 불리언 상태 추적에 매우 효율적이다. 4억 명의 사용자 정보를 단 512MB로 저장할 수 있어 메모리 효율이 극대화된다.
- 일일 활성 사용자(DAU): 날짜별 키에 사용자 ID를 오프셋으로 사용
- 기능 플래그: 각 비트가 특정 권한/기능 활성화 여부 표현
- 출석 체크: 날짜를 오프셋으로 사용하여 연속 출석 계산
참고 출처
- https://redis.io/docs/latest/develop/data-types/sorted-sets/
- https://redis.io/docs/latest/develop/data-types/geospatial/
- https://redis.io/docs/latest/develop/data-types/bitmaps/
- https://redis.io/docs/latest/commands/object-encoding/
