🧠 핵심 주제
Redis의 자료형 선택은 데이터의 형태와 워크로드에 따라 달라지며, 성능과 메모리 효율에 직접적인 영향을 미친다.
1️⃣ 적절한 자료형을 선택하는 이유
Redis는 다양한 자료형(String, List, Set, Hash 등)을 제공하지만,
“무엇을 쓰느냐”에 따라 성능·메모리 사용량·확장성이 크게 달라짐.
실제 대규모 데이터를 다루는 애플리케이션에서는 자료형 선택이 매우 중요함.
String만으로도 충분한 경우가 많지만,
데이터가 커지거나 복잡한 구조를 다루면 다른 자료형이 더 효율적임.
2️⃣ 자료형별 특성과 선택 기준
🔹 String
가장 단순하고 빠름.
단일 값(예: user:1:name = "Taro") 저장에 적합.
단, 대량의 개별 String key를 저장하면 메모리 낭비가 심해질 수 있음.
user:1, user:2처럼 여러 유저를 String으로 따로 관리하면, 해시 크기가 커지고 효율이 떨어질 수 있음.
🔹 List / Set
여러 항목을 순서대로 저장하거나 집합 연산할 때 사용.
하지만 List/Set의 요소가 많아질수록 복잡도(O(N))와 메모리 사용량이 커짐.
List는 읽기/쓰기 순서 유지가 필요할 때만 사용.
🔹 Hash
여러 필드를 가진 객체(예: 사용자 프로필)를 한 키 아래 묶을 때 유용.
예: user:1 -> {id:1, name:"Taro", age:25}
단, 필드가 너무 많거나 해시 크기가 커지면 해시 테이블 관리 비용이 급증.
Hash를 쓸 때는 데이터 크기와 접근 패턴을 잘 고려해야 함.
Redis 7.0 이후에는 메모리 효율을 위해 Listpack(리스트팩) 구조를 내부적으로 사용함.
3️⃣ 성능 최적화를 위한 고려사항
작은 단위로 데이터를 쪼개어 저장하면 메모리 효율이 높아짐.
(예: user 데이터를 여러 key로 분리)
큰 단위로 한 번에 저장하면 관리가 편하지만,
해시 크기가 커지면 성능에 부정적 영향을 줌.
Redis는 CPU보다 메모리 속도가 병목이 되기 쉬우므로,
구조 선택 시 메모리 관리 효율을 우선 고려해야 함.
String으로 충분히 처리 가능한 경우엔 그대로 사용하는 게 낫다.
4️⃣ 자주 발생하는 실수 예시
users 키 하나에 모든 사용자를 Hash로 저장 (users:{id1, id2, id3…})
→ GB 단위의 해시가 되어 관리 불가능 수준이 될 수 있음.
이렇게 거대한 해시를 피하려면
user:{id}처럼 작은 단위로 쪼개는 방식이 낫다.
5️⃣ 성능 측정과 최적화 방법
“이 자료형이 항상 더 빠르다”는 정답은 없음.
실제 워크로드(workload)에 따라 다름.
따라서 실제 환경에서 벤치마크(benchmark)로 성능을 측정해야 함.
Redis는 워크로드에 따라 속도, 메모리 소비, 병목 지점이 다르므로
테스트를 통해 애플리케이션 방향성을 잡는 게 좋다.
🧩 결론 요약
포인트 설명
자료형 선택 중요 데이터 크기, 구조, 접근 패턴에 따라 달라짐
String 우선 고려 단순한 경우엔 가장 빠르고 효율적
Hash 사용 주의 해시 크기 커지면 성능 저하 가능
List/Set 순서·집합 필요할 때만
큰 해시 한 개보다 작은 해시 여러 개 확장성과 관리 효율 ↑
워크로드 기반 결정 실제 운영 환경에서 벤치마크 필수
