Redis에 사용자별 속성 목록을 저장하려 합니다. 문자열·해시·집합 중 필요한 연산에 맞는 자료형을 고르고 실제 메모리와 갱신 비용은 어떻게 확인하나요?

Redis 자료형은 명령 목록만 보고 고르는 것이 아니라 필요한 연산, 원소 수·값 길이, 갱신 단위, 응답 바이트, 메모리 인코딩과 복제·백업 비용으로 선택합니다. 전체 프로필을 JSON 문자열로 저장하면 한 번 읽고 쓰기 쉽지만 필드 하나를 바꿀 때 큰 값을 다시 전송·저장할 수 있습니다. 해시는 필드 단위 갱신에 맞고, set은 존재·집합 연산, sorted set은 점수순 조회에 자연스럽습니다. 목록의 순서나 중복 허용까지 요구에 포함해 결정하겠습니다.

논리 자료형과 물리 인코딩을 분리합니다

작은 해시나 집합은 Redis 버전·설정의 임계값 안에서 조밀한 내부 표현을 사용할 수 있고, 원소 수·값 길이가 커지면 일반적인 표현으로 전환돼 메모리와 지연 특성이 달라질 수 있습니다. 이 임계값을 고정 상수로 외우지 않고 운영 버전에서 확인합니다. 한 사용자 속성을 수백 개의 작은 키로 쪼개면 부분 TTL·독립 갱신은 쉬워질 수 있지만 키 메타데이터·네트워크 왕복·SCAN 비용이 늘고 여러 키의 원자성도 어려워집니다.

큰 JSON 문자열을 압축하면 네트워크와 Redis 메모리를 줄일 수 있지만 압축·해제 CPU는 클라이언트에 들고 부분 갱신이 어려워집니다. 모듈이나 서버 측 처리로 압축·변환하면 Redis 주 실행 경로 CPU와 다른 명령 지연까지 측정해야 합니다. sorted set을 랭킹에 쓰면 점수·동점 정렬·부동소수점 정밀도와 갱신 중복을 별도로 설계해야 하고, 단순 해시로 점수순 조회를 만들려 하면 애플리케이션 정렬 비용이 커집니다.

운영 크기에서 실제 비용을 측정합니다

Redis MEMORY USAGE와 자료구조별 명령 지연, INFO 지표, slow log를 이용해 예상 원소 수·최대 값 길이·인코딩 전환 직전과 직후를 비교하겠습니다. p99 갱신 지연, 응답 크기, 복제 backlog, RDB/AOF fork·rewrite 중 메모리 피크까지 봅니다. 샘플 몇 건에서 작게 보이는 표현이 운영 성장 후에도 예측 가능하다고 단정하지 않겠습니다.

DBMS의 JSON 타입과 Redis 자료형을 동일하게 볼 수도 없습니다. PostgreSQL JSONB·MySQL JSON·SQL Server JSON 기능은 인덱스·트랜잭션·내구성 계약이 관계형 저장소에 있고, Redis는 메모리 중심 자료구조·복제·지속성·eviction 정책을 가집니다. 원본 데이터인지 재생성 가능한 캐시인지 먼저 정하고, 손실 허용 여부와 TTL·eviction을 자료형 선택과 함께 결정하겠습니다. 검증은 실제 접근 패턴과 동시 갱신에서 메모리·CPU·p99·복구 비용을 비교하는 방식입니다.

자료형을 결정한 뒤 키 생성 규칙과 TTL 단위를 일관되게 유지해야 합니다. 해시의 필드별 TTL이 필요하면 사용하는 Redis 버전과 클라이언트의 필드 만료 지원을 확인해야 하고, 여러 키로 쪼개면 부분 만료와 원자 갱신이 어려워집니다. 문자열 JSON은 스키마 버전과 부분 업데이트 전략을 별도 설계해야 합니다. Redis가 원본이 아니라 캐시라면 인코딩 최적화보다 재생성·무효화·eviction 뒤의 사용자 동작을 먼저 검증하겠습니다.