21.01.04 22:24 작성
·
734
1
안녕하세요, 강의 잘 보고있습니다.
평소에 가지고 있던 궁금증인데 age를 업데이트하는 부분을 보고 문득 떠올라 질문남깁니다.
기존 레거시 테이블들을 보면 이미 레코드에 포함하고 있는 계산성 데이터들을 많이 저장하고 있는 테이블들을 많이 보았습니다.
해당 강의 차수에서 말하는 age나 또는 팀-멤버간(fk) 조인되어 있는 테이블에서 팀 테이블의 전체 회원 수 같은 칼럼들이요.
저는 기본적으로 이런 데이터들을 테이블에 넣는것을 반대하고있습니다. 나이를 넣는 것 보다 생년월일을 넣어야되고 팀의 전체 회원수가 필요하면 필요 시 쿼리에서 count를 하거나 애플리케이션에서 항상 동적으로 구하는 방식을요.
제 경험상으로 이러한 계산성 데이터를 넣어버리면 변경점이 계속 생기는 것 같습니다. 예를들어 1년이 지날 경우 벌크로 나이를 +1씩 더해야 되는 상황들이요. 또한 팀 멤버가 추가될경우 실수로 팀 테이블의 총원 테이블을 업데이트 하지 않는 경우도 생길수도 있을 것 같습니다. 하지만 단점으로는 데이터 용량을 많이 조회할 경우에 계산을 해야하는 시간등도 있을 것 같습니다.
대용량 서비스 관점에서 위 의견에 대해 어떻게 생각하시는지, 어떤 방법을 선호하시는지, 제가 놓친 부분은 없는지 궁금합니다. 감사합니다.
답변 3
4
2021. 01. 04. 22:53
안녕하세요. study02님
강의에서는 간단한 예제를 선택하기 위해서 age를 선택한 것이고, 실제로는 생년월일을 넣어두는 것이 맞습니다.
추가로 팀의 전체 회원수가 필요하면 쿼리에서 count하는 방식을 사용해야 합니다. 이런 부분은 결국 정규화와 관련이 있는 부분이지요.
일반적으로 트래픽이 어느정도 있어도 이런 부분은 study02님이 생각하신 것 처럼 동적으로 구하는게 좋습니다.
그런데 여기서 정말 트래픽이 많으면 어떻게 하는가? 라는 질문에는 고민을 해보아야 합니다.
예를 들어서 가게에 리뷰 데이터가 있는데 가게가 10만건이고, 리뷰가 가게당 평균 1000개씩 쌓여있다고 가정하면, 리뷰 데이터가 약 10만 * 1000 = 1억건 정도 쌓여있게 됩니다.
고객 트래픽이 많은 상황에서 실시간으로 리뷰 수를 보여주기 위해서 데이터를 계속 count 쿼리를 하게 되면, 데이터베이스 성능에 매우 안좋은 영향을 주게 됩니다.
그래서 이런 부분은 필요에 따라서 별도의 조회성 테이블로 백그라운드에서 말아두거나 또는 캐시하는 일이 필요합니다.
어설프게 최적화를 하는 것 보다는 항상 단순함과 정규화 관점에서 먼저 생각하고, 정말 트래픽이 많거나 데이터가 많으면 점진적으로 개선해 나가는 방법을 선택하는 것이 좋다 생각합니다.
감사합니다.
1
1
2021. 05. 04. 22:02
안녕하세요. 정환님
계산이 복잡한 경우에 미리 계산을 해두고 계산된 값을 사용하는 것으로 이해하시면 됩니다.
예를 들어서 리뷰 수가 1000건이라면 1000이라는 데이터를 그때그때 수를 세는 것이 아니라 미리 1000이라는 값을 계산을 해두고 계산 된 겂을 꺼내서 사용하는 것이지요.
감사합니다.