확장 가능한 히트/분석 시스템을 설계하는 가장 좋은 방법은 무엇입니까?

Question

내가 일하는 회사는 Blackberry 플랫폼 용 응용 프로그램을 만듭니다.

우리는 우리의 응용 프로그램 내에 코드를 내장하고 실행될 때마다 응용 프로그램이 일부 통계를 중앙 서버에보고하도록하는 독점적 인 "분석 시스템"을 개발했습니다. 현재 시스템은 정상적으로 작동합니다. 그러나 그것은 시간당 100-200 히트를 가진 베타 버전에서만 있습니다. "히트"는 문제없이 서버로 전송됩니다. 히트 수락 및 저장을 처리 할 수있는 매우 견고한 API를 구축했습니다 (MySQL DB). 우리는 부하를 테스트했으며 문제없이 시간당 수십만 히트를 수용 할 수 있어야합니다. 그것은 정말로 문제가되지 않습니다.

문제는 통계를 표시하고 있습니다. 우리는 민트 (haveamint.com)와 비슷한 디스플레이 패널을 만들었으며, 매 시간, 과거 일, 달, 주, 년 등의 히트 수를 보여줍니다. 주먹 버전은 히트 테이블에서 데이터를 가져 와서 즉시 해석하는 직선 쿼리를 실행했습니다. 그것은 오랫동안 작동하지 않았습니다. 우리의 현재 솔루션은 히트가 프로세싱을 위해 "큐에 대기"되어 있고 매 5 분마다 히트를 취하여 매 시간, 일, 주, 월, 년 등의 "캐시"로 분류하는 cron이 있습니다. 이것은 훌륭하게 작동하며 엄청나게 확장 가능합니다. 그러나 1 시간대에만 작동합니다. 회사 전체가 이에 대한 액세스 권한을 갖고 있기 때문에 다양한 시간대에 수백 명의 사용자를 다루고 있습니다. 내가 산호세에서 "오늘"이라고 정의한 것은 런던의 제 동료가 오늘로 정의한 것보다 훨씬 다릅니다. 현재 솔루션은 오직 하나의 시간대로 캐시되기 때문에 시간대 밖의 데이터를 점검하는 모든 사람들에게는 악몽입니다.

이 문제를 해결하기위한 현재 계획은 모든 시간대 (총 40 개)에 대해 캐시를 만드는 것입니다. 그러나 그것은 우리가 데이터의 양에 40을 곱하는 것을 의미 할 것입니다 ... 그것은 나에게 끔찍한 것이며, 캐시가 매우 커질 수 있다는 점을 감안할 때, 그것은 단지 나쁜 생각처럼 들리지만, 또한 대기열을 처리하기 위해 이동하면 40 개의 다른 캐시에 넣기 위해 더 많은 CPU 시간이 필요합니다.

다른 사람이이 문제를 해결하는 방법에 대해 더 잘 알고 있습니까?

(예 : 긴 question..it 죄송 설명 정확히 쉬운 일이 아니다. 모두 감사합니다!) 여러 시간대에 닿을 소프트웨어를 설계 할 때

Answer 1

제안하는 솔루션에 중복성이 너무 많습니다. 매 시간마다 최소 30 분 버킷에 데이터를 저장하고 표준 시간대는 UTC로 표준화하는 것이 좋습니다.

30 분 버킷으로 사용자가 -4.5 UTC에서 1 - 2PM에 대한 시간별 데이터를 요청하면 시스템에서 5:30 - 6:30 PM 동안 데이터를 가져 와서 표시 할 수 있습니다. 1 시간 단위로 데이터를 저장하면 N + 0.5 시간 차이가있는 시간대의 사용자에게 요청을 처리 할 수 ​​없습니다.

일일 번호의 경우 48 시간 30 분대를 집계해야합니다. 선택할 슬롯은 사용자의 시간대에 의해 결정됩니다.

연간 데이터에 도달하면 17,520 개의 30 분 버킷을 수집해야하므로 흥미로워집니다. 계산을 쉽게하기 위해 UTC 시간당 사전 집계 된 연간 데이터를 얻고 4.5 시간 동안 첫 번째 집계 데이터를 빼고 내년의 처음 4.5 시간 동안 집계 데이터를 추가하는 것이 좋습니다. 이는 본질적으로 1 년 내내 4.5 시간 정도 일을 바꿀 것이고 그 일은 그리 많지 않다. 여기에서 작업하면 시스템을 추가로 조정할 수 있습니다.

편집 : 카트만두는 +5.45 GMT이므로 30 분 버킷 대신 15 분 버킷에 데이터를 저장해야합니다.

EDIT 2 : 또 다른 쉬운 개선점은 연간 집계에 관한 것이므로 매번 17,520 버킷을 추가 할 필요가 없으며 국가마다 하나의 집계가 필요하지 않습니다. 1 월 2 일부터 12 월 30 일 사이의 연간 데이터 집계 두 국가의 최대 시간대 차이는 23 시간이므로 연간 데이터 (Jan 02 - Dec 30)를 취하여 전후에 몇 가지 버킷을 추가 할 수 있습니다. 적절한. 예를 들어 -5 UTC 시간대의 경우 모든 버킷을 0500 이후 1 월 01 일, 모든 버킷을 12 월 31 일에, 1 월 1 일을 다음 해로 최대 0500 시간에 추가합니다.

Answer 2

, 나는 항상 함께 UTC에 날짜/시간을 저장합니다라고 말하고 싶지만 원래 시간대에 대한 또 다른 필드이며 시간을 소요하고 UTC/시간대와의 변환을 수행하는 함수가 있습니다. 당신은 하루의 전환, 일광 절약, 땅 반대편에서 온 한 국가의 통계를 보는 사람들 등등을 처리하기 위해 많은 어려움을 겪을 것입니다 ....

귀하의 경우에는, UTC에서 캐시를 사용하고 UTC로 변환 될 요청을 조정하면 도움이됩니다. 스탯을 "오늘"으로 저장하지 말고, 00 : 00 : 00UTC에서 23 : 59 : 59UTC 시간 동안 저장하십시오. 누군가 뉴욕에서 오늘의 스탯을 묻는다면, 변환을하십시오.

Answer 3

여기서 볼 수있는 한, 데이터웨어 하우스 시스템의 저장소 부분을 찾고 있습니다 (보고서가 프런트 엔드 일 것입니다).

실제로 상용 시스템이 수행하는 방식은 설명 된 캐시입니다. 테이블을 미리 집계하고 캐시를 생성하십시오. 질의를 가속화하는 유일한 방법은 데이터베이스 시스템을 적게 만드는 것입니다. 즉, 데이터가 적어 지므로 데이터를 반복하는 데 소요되는 시간이 줄어들거나 인덱스의 데이터가 줄어 듭니다.

그렇다면 "40 캐시 솔루션"(실제로는 24 개 이상의 시간대가 있음)을 제안 할 것입니다. 데이터 사본을 만들어 정렬 대기열을 쉽게 병렬 처리 할 수 ​​있어야합니다.

이렇게하는 또 다른 방법은 시간 단위로 캐시 한 다음 시간을 일 단위로 집계하는 것입니다 (또는 시간대에이 값이 필요한 경우 30 분). 즉, 일일 캐시보다 미세한 세분성으로 캐시하지만 원본 데이터보다 세분화 된 세분화 된 캐시를 의미합니다.

Answer 4

이러한 종류의 데이터는 일반적으로 라운드 로빈 또는 원형 데이터베이스를 사용하여 저장됩니다. 이 http://www.shinguz.ch/MySQL/mysql_20070223.html 및이 http://techblog.tilllate.com/2008/06/22/round-robin-data-storage-in-mysql/을 확인하여 작동 방식 및 MySQL에서 구현하는 방법을 알려주십시오.