물론 상세한 요구사항에 따라서 구현방법은 달라질 수 있는데 그냥 일반적으로 모든 히스토리에 대한 접근이 예상되는 상황하에서 용량도 적게 쓰고 퍼포먼스도 어느정도 담보하기 위한 방법으로는...

이벤트 소싱 패턴에서 쓰는 방법을 참고하는 것도 도움이 될 수 있음.
이벤트 소싱 패턴은 간단히 말해서 어떤 데이터에 가해지는 변경사항(이벤트)들을 전부 기록해서 데이터 조회 요청시에 그 이벤트들을 전부 리플레이해서 나오는 최종 결과 데이터를 반환하는 방식임.
근데 이러면 당연히 성능이 극악으로 안좋으니까 중간에 스냅샷들을 찍어둠.
예를 들어 데이터에 대한 이벤트(혹은 히스토리 diff)가 100개 있다고 가정할 때 10개마다 스냅샷을 찍어서 저장해줌.
그럼 최악의 경우에도 이벤트를 9번만 리플레이 시키는 정도의 오버헤드로 모든 히스토리에 접근 가능함.
여기서 최신 데이터에 대한 접근이 압도적으로 많다면 최종 데이터를 또 스냅샷을 찍거나 캐시에 올려서 사용하는 케이스도 고려해볼 수 있음.

- dc official App