나는보기, 좋아하는 것 및 다운로드를 추적하기 위하여 데이타베이스 디자인을 운동하는 것을 시도하고있다. 이제 추적 할 항목의 양은 1m 이상이 될 것으로 예상되므로 일반적으로 매일 각 항목을 추적하지만 1m은 성능에 대한 우려와 하드 디스크의 크기에 관한 문제가 있습니다.보기/좋아요/다운로드 통계를위한 데이터베이스 디자인?
고객은 지난 주와 같은 범위의 상단 통계, 지난 달, 작년를 표시 할 수있는 소원. 따라서 데이터를 몇 주 또는 몇 달에 걸쳐 합산하여 데이터를 분할하여 더 이상 관련이없는 다른 모든 데이터를 삭제하거나 쿼리를 통해 데이터를 모두 추적하여 유연성을 유지해야하는지 잘 모르겠습니다. 자유롭게 필요한 통계.
데이터베이스 :
MySQL은 내가 하루에 한 번 카운터를 저장 걸릴해야합니다.
나는 당신이 매일 통계를 삭제 주 말까지 매일 한 후 추적 할 필요가 있다고 생각 당신은 두 번째 주에 의해 주간 데이터를 그렇게 원하는 경우 월과 올해에 할 마지막 통계를 지키려고. 이 작업을 만들 수있는 작업을 만들 수 있습니다. 이게 당신을 도울 수 있기를 바랍니다. 동작은 단지 데이터를 추가 인해
동의합니다. 개별 기록 항목을 사용하지 않는 경우 보관하지 마십시오 (추후 분석을 위해 일종의 "큰 데이터"저장소에 저장할 수도 있음) –
시계열 포맷에 저장한다.
당신이 클릭/뷰 데이터를 수신 할 때마다 간다, 그것을 계산하고 우리가 할 수있는 가장 작은 크기로 결과를 넣습니다. 매 시간마다 요약 할 수 있다면 성능면에서 가장 좋은 선택입니다. 더 높은 차원의 데이터를 알아야 할 때마다 요약하십시오. 요구에 따라 (통계)를 계산하지 마십시오. 예 : 1 일 데이터를 계산하기 위해 10 백만 행을 검색하면 작업이 많이 소요됩니다. 당신은 두 가지 저장됩니다이 방법으로
:
당신이에 저장되어있는 데이터베이스를 결정 했습니까? 이 수치는 완전히 최신이어야합니다 (즉, 지난 초). 많은 솔루션이 있습니다. 예를 들어, 간단한 테이블로 요약을 생성하는 작업을 매일 실행할 수 있습니다. 1 백만 레코드가 기록하는 데이터 기간은 언제입니까? 마지막으로 ...이 데이터를 가져 오는 곳이면 이미이 작업을 수행하는 도구가있을 수 있습니다. –
@ Nick.McDermaid 데이터는 하루에 한 번 수집해야하며 데이터베이스는 mysql입니다. 나는 1 년에 한 번 카운트를 받으면 365m + 항목을 초래하는 최대 1 년 동안 문제가되지 않는 모든 시간을 추적해야합니다. 그래서 이전 프로젝트의 경우 테이블 당 최대 한 조당 10k를 얻었 기 때문에 성능에 어떤 영향을 미치는지 경험이 부족합니다. – WoVoo