둘 다 NoSQL 로 묶이지만 해결하는 문제가 다르다. Redis 는 메모리에 데이터를 두고 마이크로초~밀리초 단위 응답을 내는 자료구조 서버이고, HBase 는 HDFS 위에서 수십억 행 규모를 다루는 분산 컬럼 지향 저장소다.
| 항목 | Redis | HBase |
|---|---|---|
| 저장 위치 | 메모리 (RDB · AOF 로 디스크 영속화) | HDFS |
| 데이터 모델 | 키-값 + 자료구조(String · Hash · List · Set · Sorted Set · Stream) | 행 키 + 컬럼 패밀리 |
| 용량 한계 | 클러스터 전체 메모리 | 디스크 용량. 사실상 수평 확장 |
| 대표 지연 | 1ms 미만 | 수 ms ~ 수십 ms |
| 조회 방식 | 키 직접 조회, 자료구조별 연산 | 행 키 조회, 행 키 범위 스캔, 필터 |
| 고가용성 | Sentinel 또는 Cluster 구성 필요 | HDFS 복제와 리전 재배치로 기본 제공 |
| SQL | 없음 | 없음. Phoenix 나 Hive·Impala 외부 테이블로 우회 |
두 시스템 모두 보조 인덱스가 없다. Redis 는 키를 모르면 찾을 수 없고(KEYS 는 운영에서 쓰면 안 된다), HBase 는 행 키 기준 정렬 저장이라 행 키 이외의 조건은 전체 스캔이 된다. 그래서 설계의 대부분이 키를 어떻게 잡을 것인가 에 달려 있다.
HBase 에서 순차 증가하는 값을 행 키 앞자리에 두면 쓰기가 한 리전에 몰린다(핫스팟). 해시 접두사를 붙이거나 자리를 뒤집는 식으로 흩는다. Redis Cluster 도 키의 해시 슬롯으로 노드를 정하므로, 한 키에 대용량 자료구조를 몰아 두면 그 노드만 커진다.
Redis 가 맞는 경우는 접근이 잦고 크기가 제한적인 상태 데이터다. 세션 저장, 캐시, 실시간 순위(Sorted Set), 속도 제한 카운터, 짧은 대기열(Stream)이 전형적이다. 데이터가 사라져도 원본에서 다시 만들 수 있어야 한다.
HBase 가 맞는 경우는 오래 보관하면서 키로 빠르게 찾아야 하는 대량 이력이다. 기기·센서 시계열, 사용자별 이벤트 이력, 로그 원본 보관이 여기에 든다. 배치 분석은 Hive·Impala·Spark 를 얹어 처리한다.
둘을 함께 쓰는 구성도 흔하다. HBase 에 원본을 쌓고 최근·인기 데이터만 Redis 에 올려 조회를 받는 형태다. 이때 캐시 무효화 정책을 정해 두지 않으면 두 저장소의 값이 갈린다.
Redis 의 영속화는 성능과 맞바꾼다. RDB 는 주기적 스냅샷이라 마지막 스냅샷 이후 데이터가 사라질 수 있고, AOF 는 기록 시점에 따라 손실 범위가 달라진다. appendfsync everysec 이 기본 절충안이며 최대 1초분을 잃을 수 있다. 원본이 따로 있는 데이터에만 쓰는 것이 안전하다.
HBase 는 WAL 에 먼저 쓰고 HDFS 복제로 보관하므로 노드 장애에 강하다. 다만 리전 이동이나 분할 중에는 그 리전에 대한 요청이 잠시 실패한다. 클라이언트에 재시도가 필요하다.
트랜잭션은 둘 다 제한적이다. Redis 의 MULTI/EXEC 는 명령을 묶어 순서를 보장하지만 롤백이 없다. HBase 는 행 단위 원자성만 제공하며, 여러 행에 걸친 원자성은 없다.
Redis 는 단독 기동이 간단하지만, 고가용성을 갖추려면 Sentinel 이나 Cluster 를 구성하고 장애 조치 동작을 검증해야 한다. 메모리가 상한이므로 만료 정책(maxmemory-policy)을 정하지 않으면 쓰기가 막힌다.
HBase 는 HDFS 와 ZooKeeper 를 전제로 하므로 단독으로 도입하기 어렵다. 이미 Hadoop 클러스터가 있으면 추가 비용이 작지만, 그렇지 않다면 도입 자체가 큰 결정이다. 대안으로 Kudu 나 오브젝트 스토리지 + Iceberg 조합을 함께 검토할 만하다.