실무에서의 복잡한 쿼리 결과 캐싱 전략(크기, TTL 등) 관련 질문
84
3 asked
강사님, 캐싱 관련해서 실무적인 관점의 질문이 있습니다.
강의에서 String 타입의 value에 JSON 형식으로 데이터를 저장해서 캐싱 처리를 한다고 배웠는데, 실무에서 어느 범위까지 캐싱하는 게 적절한지 감을 잡고 싶습니다.
과거에 MyBatis의 동적 쿼리처럼 조건부 로직이 포함된 200줄짜리 복잡한 쿼리가 DB에서 파싱되는 시간 자체만으로도 성능 부하를 유발했던 경험이 있습니다.
쿼리 자체를 수정하는 것이 베스트겠지만, 현실적으로 어려울 때가 있었습니다.
이런 '고치기 힘든 악성 쿼리'의 실행 자체를 회피하는 목적으로 Redis 캐싱을 적극적으로 사용하는 전략에 대해 궁금합니다.
실무에서는 이런 경우:
1. 쿼리 결과 데이터가 어느 정도 크기(예: 수십 MB)까지 Redis에 캐싱을 허용하시나요?
데이터가 너무 크면 오히려 Redis에 부담이 될 것 같아서요.
2. 만약 결과가 너무 크다면, 페이징 처리된 일부만 캐싱하시나요?
아니면 보고서처럼 핵심 요약 데이터만 따로 캐싱하는 전략을 사용하시나요?
3. 특히 이런 복잡한 집계/통계 쿼리는 데이터 변경이 잦지 않은데,
이런 경우 TTL은 보통 어느 정도로 설정하시는지 강사님의 경험이 궁금합니다.
Answer 2
1
안녕하세요 지니님. 일단 좋은 질문 주셔서 감사합니다.
말씀해주신 사례를 들어보니, 아마도 조회 데이터의 결과값이 단건이 아니라 목록(list)였을것으로 생각됩니다.
단건 데이터가 아닌경우엔 일반적으로 캐싱처리하기에는 부적절하다고 생각합니다. 통상적으로 목록상의 데이터는 빈번히 변경될 여지가 있으므로, 보통은 단건의 데이터에 한해 캐싱처리를 한다고 보시면 됩니다.
다만, 말씀해주신 사례처럼 변경이 빈번하지 않을것으로 생각된다고 말씀하셨으니, 그 경우에는 전체 데이터가 아닌 핵심 데이터 요약결과 정도만 캐싱처리하는게 적절하다고 생각합니다. 이 경우에도 데이터의 변경가능성을 충분히 고려하여 캐싱처리를 해주셔야 할것 같습니다.
0
안녕하세요, 인프런 AI 인턴입니다. 지니님.
Redis 캐싱을 활용한 효율적인 성능 최적화 방법에 대한 질문 주셨네요. 실무에서 복잡한 쿼리를 처리하는 데에는 다양한 전략이 있을 수 있습니다. 다음은 관련 질문에 대한 답변입니다:
캐싱할 데이터 크기:
- Redis는 인메모리 데이터 저장소로 설계되어 데이터 접근 속도가 매우 빠르지만, 메모리 한계가 있기 때문에 대규모 데이터를 캐싱하는 것은 신중해야 합니다. 보통 수십 MB의 데이터를 Redis에 저장하는 것을 피하고, 데이터가 커질 경우에는 페이징이나 요약된 데이터만 캐싱하는 것이 일반적입니다.
- Redis는 인메모리 데이터 저장소로 설계되어 데이터 접근 속도가 매우 빠르지만, 메모리 한계가 있기 때문에 대규모 데이터를 캐싱하는 것은 신중해야 합니다. 보통 수십 MB의 데이터를 Redis에 저장하는 것을 피하고, 데이터가 커질 경우에는 페이징이나 요약된 데이터만 캐싱하는 것이 일반적입니다.
데이터가 큰 경우의 전략:
- 데이터의 전체를 캐싱하기에 적합하지 않다면, 페이징을 통해 필요한 부분만 캐싱하는 것이 좋습니다. 또는 결과의 핵심 요약 데이터만 저장하여 조회 성능을 개선할 수 있습니다. 중요한 것은 메모리 사용량을 줄이면서 필요한 정보만 제공하는 방법을 찾는 것입니다.
- 데이터의 전체를 캐싱하기에 적합하지 않다면, 페이징을 통해 필요한 부분만 캐싱하는 것이 좋습니다. 또는 결과의 핵심 요약 데이터만 저장하여 조회 성능을 개선할 수 있습니다. 중요한 것은 메모리 사용량을 줄이면서 필요한 정보만 제공하는 방법을 찾는 것입니다.
TTL 설정:
- 변화가 적은 집계/통계 데이터의 경우, 보다 긴 TTL(Time-To-Live)을 설정하여 캐싱의 이점을 극대화할 수 있습니다. 상황에 따라 시간, 일단위로 TTL을 설정할 수 있으며, 특정 구간 또는 데이터의 업데이트 주기에 따라 조정합니다. 무작정 긴 TTL보다는, 데이터 일관성 및 최신성을 고려한 설정이 중요합니다.
- 변화가 적은 집계/통계 데이터의 경우, 보다 긴 TTL(Time-To-Live)을 설정하여 캐싱의 이점을 극대화할 수 있습니다. 상황에 따라 시간, 일단위로 TTL을 설정할 수 있으며, 특정 구간 또는 데이터의 업데이트 주기에 따라 조정합니다. 무작정 긴 TTL보다는, 데이터 일관성 및 최신성을 고려한 설정이 중요합니다.
추가적으로, 관련 정보를 점검하고 싶으시면 아래 링크들을 참고해 보세요:
Redis와 무거운 쿼리를 다루는 방법: 복잡한 쿼리 최적화와 Redis 활용법에 대해 논의한 자료입니다.
Redis 캐싱 전략 및 실무 적용사례: 다양한 상황에서의 Redis 활용 케이스를 확인할 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
순위가 동률일 때의 처리에 대해 질문드립니다.
0
10
2
Ingress 생성하기 ingressclass 질문
1
21
2
deployment 업데이트 및 롤백 실행하기 -2
1
23
2
강의 듣는 중인데,
0
23
1
36강 오탈자가 있는 거 같습니다.
0
20
2
Service Create/Update Record 운용과 Delete Record 미운용의 차이 질문
0
18
1
조회속도 개선에서 더 개선하는 방법이 궁금합니다.
0
28
2
라우팅 테이블 설정 중 궁금한게 있습니다.
0
34
1
user-service jwt
0
32
2
젠킨스버전과 플러그인설치
1
35
2
cpu&memory 재설정하기에 질문이 있습니다.
1
50
2
Redlock 알고리즘 관해 궁금한게 있습니다!
0
47
2
실무에서 Redis에서 0번 이외의 DB를 사용하나요?
0
149
2
레디스 서버 구성
0
70
2
Redis Pub/Sub, Stream과 Kafka 비교 질문입니다.
0
309
2
채팅 서비스 관련하여 질문드립니다.
0
95
3
레디스에 저장하는 토큰 질문입니다.
0
74
2
redis 개발 환경 수정 시 질문 입니다.
0
90
2
key값에 대한 작성 컨벤션
0
135
2
수업 자료는 어디 있을까요?
0
149
2
상품의 재고 변경을 비동기로 처리하는것에 대해 질문합니다.
0
194
2
혹시 kafka나 rabbitMQ 강좌 예정 없으신가요?
0
194
1
MacOS에서 brew를 사용한 설치를 권장하지 않는 이유가 무엇인가요?
0
232
2
레디스 pub/sub 질문
0
280
1