통계 데이터 수정 질문
63
投稿した質問数 3
안녕하세요, 좋은 강의 만들어주셔서 정말 감사합니다!!
이번에 신규 기능을 추가하면서 통계 데이터도 필요한 상황인데 통계 데이터에 사용되는 원본 데이터가 수정되는 케이스는 어떻게 설계하는게 좋을지 조언을 구하고자 질문드립니다.
통계 데이터는 유저가 조회하고, 데이터 조회 기간은 최근 7일/최근 한달/과거 한달(사용자 조정 가능)로 조정이 가능하고, 한 화면에 4가지 유형의 통계 데이터를 제공해야 해서 이를 위해 일별 통계 테이블을 사용하려고 했는데요.
그런데 원본 데이터가 언제든 수정되거나 추가될 수 있는 상황입니다.
그래서 수정한 사용자와 수정 일자를 따로 모아 배치를 돌리는 방향이 생각났는데 이렇게 설계해본 경험이 없어,
우선은 실시간 증분 업데이트를 진행하고 데이터 정확성이 필요해지는 상황이 필요하다면 그때 위와 같은 배치를 돌리는게 나을지 또는 다른 방향이 있을지 궁금하여 질문드립니다.
정산 데이터는 아니기 때문에 멱등성이 깨질 수 있는 상황은 감안하고, 기획 요구사항인 실시간성을 반영하는게 좋을지도 고민이 되어 질문드립니다!
回答 2
2
안녕하세요. learnlearn님
비즈니스 상황을 자세히는 모르겠지만, 특정 유저와 날짜 단위로 배치가 이루어지고, 해당 배치가 크게 부담이 되는 상황이 아니라면, 수정한 사용자와 수정 일자만 모아두고, 해당 사용자의 해당 수정 일자의 배치만 멱등하게 돌아가도록 하면 깔끔하게 진행될 것 같아요.
실시간 증분은 속도는 빠를 수 있지만 멱등성이 깨질 수 있기 때문에 더 많은 고민이 필요합니다.
감사합니다.
1
답변해주셔서 감사합니다!
해당 기능의 이용은 적을 것 같지만 사용자가 많고 타 서비스의 대량 정보도 함께 통계화해야 하다보니 배치가 부담되고 빠른 개발이 필요한 상황이라 우선 통계기간을 줄이고 조회시점에 전날까지의 데이터만 통계하고 레디스 캐싱하는 방법을 적용하게 되었습니다.! 배치를 추가하게 된다면 조언해주신 방향으로 작업해야할 것 같습니다. 조언해주셔서 감사합니다!!
0
안녕하세요, 인프런 AI 인턴입니다. learnlearn 님,
귀하의 질문과 관련하여 데이터 수정 및 통계 처리에 대한 설계 고민을 말씀해 주셨군요. 통계 데이터 처리에서 원본 데이터의 수정 가능성은 설계를 복잡하게 만들 수 있습니다. 아래에 몇 가지 방향성을 제안드리며, 이를 참고하시어 적절한 설계를 고민해 보실 수 있습니다.
1. 실시간 증분 업데이트 고려
- 장점: 실시간으로 통계 데이터를 갱신할 수 있어 사용자에게 더 빠르고 최신의 정보를 제공할 수 있습니다.
- 단점: 시스템에 부하가 될 수 있으며, 데이터 동기화 문제 또는 성능 저하의 위험이 있습니다.
2. 배치 프로세스 활용
- 방식: 수정된 데이터는 별도로 기록해 둔 후, 일정 주기(예: 매일 새벽)에 배치 작업을 통해 통계 데이터를 갱신합니다.
- 장점: 실시간성을 포기하는 대신, 시스템 부하를 줄이고 데이터 처리의 안전성을 확보할 수 있습니다.
- 단점: 사용자는 일정 시간 동안 갱신되지 않은 데이터를 보게 될 수 있습니다.
3. 쓰기 시점 캐싱 및 일관성 제고
- 사용자/관리자에게 데이터 수정의 후속 절차와 시점을 명확히 알려 캐싱 전략과 함께 활용합니다.
- 예시: Redis와 같은 캐시를 사용하여 복수의 데이터 수정 시점을 관리하고 이를 기준으로 통계 데이터를 업데이트합니다.
참고할 수 있는 질문 및 답변
- “간단한 통계 쿼리가 가능한가요?” - JPA와 QueryDSL을 통한 복잡한 통계 쿼리 처리 방법에 대한 논의입니다.
- “통계성 데이터 조회” - 네이티브 쿼리를 이용한 통계성 데이터 처리 방법에 대해 논의합니다.
귀하의 경우 실시간성이 필요한 요구사항이라면 실시간 증분 업데이트와 배치 시스템의 조합을 통해 데이터 정확성과 시스템 성능을 모두 잡으려는 전략을 권장드립니다. 실시간성의 정도와 데이터 수정 빈도에 따라 적절히 선택하시기를 바랍니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
실제 FK제약조건을 설정하지 않는이유
0
35
2
히스토리 관련 질문
0
58
2
공통 코드에서 Redis Pub/Sub은 최근 실무에서 쓰이진 않나요?
0
133
2
DELETE -> SELECT 질문 드립니다.
0
48
1
상속 관계 모델링의 적용 기준 질문
0
75
1
TTL 캐싱에 대한 질문
0
78
1
공통 코드 사용시 컬럼 타입 설정
0
83
1
history_creted_at과 valid_from
1
66
2
함수 기반 인덱스 (Function-Based Index)
0
70
1
추후 강의 질문있습니다
0
124
2
실무 통계 질문(고민) 드립니다..!
0
91
2
Json 컬럼의 객체 맵핑
0
64
1
[Deprecated] 오타 제보
0
86
1
오타 제보
0
73
2
category_path 테이블에서 idx_descendant 인덱스를 생성하는 이유가 궁금합니다
0
96
2
물리적으로 외래 키 제약 조건을 설정하지 않을 때
0
97
1
`전체 행 스냅샷 이력 테이블`의 대상 테이블 칼럼 변경
1
85
1
common_code_detail의 code 변경 가능성
1
112
1
[해결책 - 코드값 분리] 중 orders(order_status) - common_code(code) 타입 불일치 제보
0
87
1
이미 문자열 타입인 컬럼을 캐스팅하는 이유
0
106
2
계층 구조 모델링 기타 방법들
0
106
1
섹션 9의 퀴즈가 영어로 출력되요.
0
106
2
섹션 6 SOFT DELETE) UNIQUE 제약 조건 + 가상 컬럼
0
77
1
섹션2 공통 코드) 애플리케이션 ENUM을 API에 그대로 노출한다면?
0
128
1