Redis 8.10 Compact Hash: 같은 필드를 반복 저장하지 않으면?

Redis 8.10의 Compact Hash는 비슷한 구조의 hash들이 반복하는 필드 이름을 공유해 메모리 사용을 줄이는 접근입니다. 사용자나 상품 레코드마다 같은 필드 이름을 저장하는 데이터에서 검토할 만합니다. 다만 메모리가 줄어드는 비율과 요청 지연 개선은 내 데이터에서 별도로 측정해야 합니다.

Redis는 2026년 9월 14일 8.10 공개를 발표했고 Compact Hash, bulk import, 새 운영 기능 등을 소개했습니다. 이 글은 그중 hash 저장 구조와 관측 방법에 초점을 맞춥니다. Redis 8.10 발표

같은 필드가 반복된다는 의미

다음 두 레코드의 값은 다르지만 필드 이름은 같습니다.

product:1 → name, category, price, stock
product:2 → name, category, price, stock

hash가 많아지면 값뿐 아니라 구조를 표현하는 비용도 반복됩니다. Compact Hash는 같은 schema를 가진 키의 필드 이름을 공유하도록 설계됐습니다. Redis 8.10 기능·지표 문서

이 설명을 ‘모든 hash를 같은 형태로 바꿔야 한다’는 권장으로 받아들이면 안 됩니다. 비슷한 레코드가 충분히 많을 때와 키마다 필드 구성이 자주 달라질 때의 효과는 다를 수 있습니다. 저장 구조를 맞추려고 불필요한 빈 필드를 대량으로 넣는다면 오히려 데이터·처리 비용이 늘 수 있습니다.

HIMPORT는 같은 연결에서 쓰는 명령입니다

새 HIMPORT는 연결에 fieldset을 준비한 뒤 필드 이름을 매번 보내지 않고 값으로 hash를 생성하는 bulk import 명령입니다. fieldset은 클라이언트 연결에 속하며 다른 연결에서 보이지 않습니다. 연결이 닫히면 해당 준비 상태도 사라집니다. HIMPORT 공식 문서

Redis 8.10을 지원하는 별도 테스트 환경에서 아래처럼 같은 redis-cli 세션으로 확인할 수 있습니다. 운영 키와 구분한 이름을 사용하세요.

redis-cli

다음은 위에서 열린 동일한 대화형 연결에 순서대로 입력하는 Redis 명령입니다.

HIMPORT PREPARE demo_product name category price
HIMPORT SET demo:compact:product:1 demo_product pencil stationery 1000
HIMPORT SET demo:compact:product:2 demo_product notebook stationery 3000
HGETALL demo:compact:product:1
MEMORY USAGE demo:compact:product:1
INFO STATS
INFO MEMORY
HIMPORT DISCARD demo_product

HIMPORT DISCARD는 준비한 fieldset을 해제하는 동작이며 만든 상품 키를 삭제하는 동작이 아닙니다. 테스트 데이터의 정리는 별도로 계획하세요. 세션 종료와 데이터 삭제를 혼동하면 예제가 남긴 키를 놓칠 수 있습니다.

커넥션 풀을 쓰는 앱의 함정

PREPARE를 수행한 연결과 SET을 수행한 연결이 다르면 준비 상태를 찾을 수 없는 상황이 생깁니다. 클라이언트가 pool에서 매번 다른 연결을 고르는지 확인해야 합니다.

batch import 작업에서는 연결을 확보한 범위 안에서 준비·입력·해제를 수행하고, 중간 연결 실패 후 어떻게 재개할지 정하세요. 단순 pipeline 사용만으로 특정 연결 상태의 수명이 원하는 대로 관리되는지는 클라이언트 구현에 따라 확인해야 합니다. 연결 풀 점검 가이드처럼 연결 자체를 관측하는 습관이 도움이 됩니다.

업그레이드 후 볼 메모리 지표

공식 8.10 문서는 다음 지표를 소개합니다.

모든 키의 메모리 값을 한꺼번에 무제한 수집하기보다 대표 데이터와 전체 서버 지표를 함께 확인하세요. 객체별 메모리와 프로세스 RSS가 항상 같은 변화폭을 보이는 것은 아닙니다. allocator·복제·영속화 중 작업·다른 자료구조도 영향을 줍니다.

같은 데이터로 비교하는 순서

1. 대표 hash의 필드·값 크기, 개수, 갱신 빈도를 기록합니다.
2. 동일한 데이터·TTL·동시성으로 기준 버전의 지표를 기록합니다.
3. 테스트 8.10 환경에서 입력·갱신·조회·삭제를 재현합니다.
4. 메모리와 함께 p95·p99 지연, 오류, import 시간을 비교합니다.
5. 저장·재시작·복원 뒤 결과가 같은지 확인합니다.

대상 레코드가 적은 시험에서 전체 서버 메모리만 비교하면 차이가 묻힐 수 있습니다. 반대로 실제보다 훨씬 단순한 값으로 성공한 수치를 운영의 기대 절감률로 쓰면 안 됩니다. 공식 발표의 최대 절감 수치도 모든 schema의 보장값이 아닙니다.

메모리 최적화와 Hot Key는 다른 문제

Compact Hash가 메모리를 줄여도 한 키에 요청이 몰리는 현상이 자동으로 분산되지는 않습니다. 값의 구조와 호출 빈도는 별도 축입니다. Redis Hot Key 측정과 로컬 캐시를 함께 참고하세요.

기존 데이터를 어떻게 읽고 새 형식으로 저장하는지, 이전 버전으로 돌아갈 때 어떤 데이터·영속화 파일을 복구할지도 확인해야 합니다. ‘컨테이너 태그만 되돌리기’가 복구 계획을 대신하지는 않습니다. 롤백 테스트는 복사한 데이터로 먼저 수행하세요.

자주 묻는 질문

HIMPORT PREPARE를 한 번 해두면 모든 연결이 공유하나요?

아닙니다. 공식 문서는 fieldset이 클라이언트 연결 범위라고 설명합니다. 연결 풀과 재연결 동작을 검증해야 합니다.

8.10으로 올리면 모든 hash 메모리가 같은 비율로 줄어드나요?

데이터 구조와 변환 조건, template 재사용 정도에 따라 다릅니다. template 지표와 대표 작업을 실측하세요.

메모리가 줄면 Redis 지연도 반드시 줄어드나요?

메모리 사용과 요청 병목은 다를 수 있습니다. CPU, 네트워크, 명령 비용, 호출 빈도를 포함해 비교해야 합니다.

참고 자료

• Redis 8.10 발표 — 2026-09-14.
• 8.10 기능·설정·지표.
• HIMPORT 명령.

2026년 10월 8일 확인. 명령은 별도 테스트 환경용이며 실제 데이터의 메모리·성능·복원 호환성을 검증한 뒤 운영에 적용하세요.