2013-05-27 9 views
1

내 GAE 앱 중 하나에서 스폰서 이미지를 구현하는 솔루션을 찾고 있습니다.비용 효율적인 방식으로 이미지 뷰 추적

약 5000 명의 사용자가 앱을 사용하고 있으며 이러한 스폰서 이미지는 사용자가 볼 때마다 그리고 누군가가 클릭 할 때마다 추적해야합니다.

누군가가 카운터에 대해 여러 항목을 제안한 다음 데이터 저장소 쓰기 제한을 통과하기 위해 이러한 카운터를 무작위로 증가 시키겠다는 제안을 받았지만 정확히 동시에 두 개의보기가 있고 둘 다 데이터 저장소에 쓰려고하면 같은 시간에 두 번째 쓰기는 첫 번째 쓰기를 덮어 쓰며 한 개의보기를 잃게됩니다.

현재 모든보기와 모든 클릭에 대해 새로운 데이터 저장소 항목을 만들고 모든보기를 추가하고 통계 엔티티에서 통계를 저장하는 큐로 스케줄러를 전달하는 것은 그리 효율적이지 않습니다.

+0

제안하신 분산 카운터를 사용하지 않는 이유는 무엇입니까? 20 열 카운터에 배포 할 수 있습니다. 즉, 매우 신뢰할 수 없도록하기 위해 초당 20 히트 (많이)에 도달해야합니다. – MeLight

+0

우리는 20 초당 20 히트 이하로 논의. 하나의 인스턴스 만 실행 중이면 작동해야하지만 두 인스턴스가 실행되는 즉시 두 인스턴스가 같은 항목에 쓰려고 시도하는 1/20의 기회가 생깁니다 (따라서 동일한 항목을 증가시키기 때문에 해당 트랙이 누락됩니다) 동시에 많은 항목들). 정확성을 희생해야하는 패스를 얻는 데 사용할 수있는 일종의 "행 수준 잠금"이 있습니까? distrubuted-counter + entity-locking은 완벽한 해결책이 될 것입니다. –

+0

저는 확률 전문가는 아니지만, 20에서 같은 카운터 행을 치려고하는 두 개의 인스턴스가 합쳐져서 1/400의 확률로 합쳐질 것이라고 생각합니다. 잠금에 대한 질문에 관해서는, 나는 그런 메커니즘을 알지 못합니다 (정말 좋을 것입니다). – MeLight

답변

0

답변 :

당신은 하나의 작업 시간의 처리 속도로 큐를 사용하고, 그 큐에 카운트 작업을 보낼 수있는이 게시. 그렇게하면 카운터에 매번 한 번만 계산 작업이 수행된다는 것을 알 수 있습니다.