통계를 처리하기 위한 Table을 만드는 설계는 바람직할까?

통계용 Table을 만든 이유

제가 만들고 있는 사이트 책잇아웃에는 1년간의 독서내역 통계를 보여주는 기능이 있습니다.

통계는 사이트를 들어갈 때 마다 보이는데, 들어갈 때 마다 1년간의 모든 독서 활동을 SELECT 해서 계산해서 보여주면 너무 비효율적이라 생각해 보여주는 통계를 독서활동을 INSERT 할 때 마다 갱신해서 그 통계만 보여주면 좋을거라 생각해 통계용 Table을 만들었습니다.

---

통계용 Talbe이 재앙이 된 이유

우선, SELECT가 INSERT/UPDATE 보다 많은것 자체는 사실입니다. 하지만 INSERT/UPDATE가 일어 날 때 마다 코드 레벨에서 Transaction으로 통계 Table을 갱신해 줘야 하는건 상당한 부담입니다.

1. 코드가 쓸데없이 복잡해집니다. 통계용 Table의 역할은 Cache인데, 관심사의 분리가 되지 않고 여러곳에서 Cache 처리를 길게 해야 합니다.

2. 통계 Table에 변경이 있을 경우엔, Batch를 돌려 여태까지의 값을 모두 갱신해야 합니다.

3. 버그가 발생하면 정합성을 보장하기 힘듭니다.

---

더 좋은 설계?

SW 설계에 정답은 없지만, 이 경험을 통해 Cache를 두는게 더 좋은 설계라고 느꼈습니다.

우선, Cache는 Spring Data Redis 같은 이미 있는 Library를 통해 AOP로 관심사 분리가 쉽게 가능합니다.

또, 정합성의 문제도 Cache는 쉽게 버리고 쌓을 수 있기에 어느정도 극복 가능합니다.

---