게임 서비스 개발을 하며, 게임과 같은 경우에는 보통 한번 쓰고 버리는 일회성 데이터들이 대부분이었기에, 지속적으로 db에 저장하는게 불필요하다 생각하였다. 때문에 캐싱처리를 위해 인메모리 DB인 Redis를 도입하며, 기존 JPA 방식대로 Repository를 만들어 RedisHash로 저장하고 있었는데, 이를 익숙한 JSON으로 만들어서 보고싶어 RedisTemplate를 활용해보았다. 그렇게 찾아보면서 들게된 생각이, RedisTemplate는 JSON 직렬화 하기 좋아서 쓰는것까지 좋다. 근데 왜 둘을 나눠놓았고 각각의 차이점과 장단점은 뭘까가 궁금해졌다.
얘가 RedisHash. 조회도 hgetall 이라는 명령어로 수행한다.
이건 RedisTemplate으로 Json직렬화 한 것. 익숙하긴 한데, 가독성이 그렇게 좋지는 않은 느낌이다.
@RedisHash (Spring Data Redis Repository)
장점
1.
자동화된 CRUD 기능:
•
Spring Data Redis가 제공하는 Repository 인터페이스를 활용해 CRUD 작업을 간편하게 처리할 수 있다.
•
예: CrudRepository, PagingAndSortingRepository.
2.
직관적이고 간결한 코드:
•
데이터를 저장, 조회, 삭제하는 코드를 작성하지 않아도 된다.
•
Repository 메서드를 호출하기만 하면 된다.
3.
도메인 모델 중심의 개발:
•
@RedisHash를 통해 엔티티를 명시적으로 정의하여 도메인 중심의 코드를 작성할 수 있다.
4.
자동 TTL 지원:
•
@RedisHash(timeToLive = 3600)을 설정하면, TTL을 간단히 적용할 수 있다.
단점
1.
제한된 직렬화 설정:
•
기본적으로 JdkSerializationRedisSerializer를 사용하며, JSON 직렬화를 위해 추가 설정이 필요하다.
2.
데이터 구조 제한:
•
데이터가 Redis의 Hash 구조로 저장된다.
•
특정 필드가 Hash의 개별 키로 저장되므로, 복잡한 데이터 구조(예: List, Map)를 처리하기 어렵다.
3.
유연성 부족:
•
Spring Data Redis의 Repository 기능은 자동화된 CRUD 작업에는 유리하지만, 커스텀 동작(ex. 복잡한 키 관리, 조건별 데이터 저장 등)은 구현하기 어렵다.
RedisTemplate (Manual Management)
장점
1.
높은 유연성:
•
데이터를 Redis에 저장하는 방식을 자유롭게 정의할 수 있다.
•
Key-Value, List, Set, Hash 등 Redis의 다양한 데이터 구조를 활용 가능.
2.
완전한 직렬화 제어:
•
GenericJackson2JsonRedisSerializer 또는 커스텀 직렬화기를 설정하여, 데이터가 JSON 형식으로 저장되도록 쉽게 제어 가능.
3.
복잡한 동작 처리 가능:
•
Redis 키 패턴 관리, 데이터 TTL 설정, 여러 엔티티 간 연관 작업 등을 자유롭게 구현할 수 있다.
4.
Custom TTL 지원:
•
특정 데이터에 개별적인 TTL 설정이 가능하다.
단점
1.
코드 복잡성 증가:
•
저장, 조회, 삭제 같은 기본적인 CRUD 작업을 직접 구현해야 한다.
•
코드 작성량이 증가할 수 있다.
2.
개발 실수 위험:
•
데이터 저장 및 조회에 대한 모든 로직을 직접 관리해야 하므로, 잘못된 구현으로 인해 데이터 손실 가능성이 있다.
언제 @RedisHash를 사용해야 할까?
1.
간단한 CRUD 작업이 대부분이고, Redis를 관계형 데이터베이스처럼 사용하려는 경우.
2.
프로젝트가 도메인 모델 중심 설계를 기반으로 하고, Spring Data JPA와 유사한 Repository 스타일을 선호할 경우.
3.
데이터 구조가 간단하고, Hash 형태의 데이터 저장 방식이 적합한 경우.
4.
자동 TTL 설정 등 Spring Data Redis의 기본 기능을 적극 활용하려는 경우.
언제 RedisTemplate을 사용해야 할까?
1.
Redis의 다양한 데이터 구조(Hash, List, Set, Sorted Set 등)를 적극 활용하려는 경우.
2.
JSON 직렬화나 다른 커스텀 직렬화를 쉽게 적용하려는 경우.
3.
데이터 저장/조회에 대한 유연한 로직(예: 조건부 저장, 복잡한 키 관리 등)이 필요한 경우.
4.
TTL을 개별 데이터마다 동적으로 설정해야 하는 경우.
5.
Repository 스타일이 불필요하고, Redis를 단순한 캐시 또는 Key-Value 저장소로 활용하려는 경우.
