복잡한 계산 된 임시 데이터를 캐시하는 방법

Question

사람들이 축구 경기 결과에 내기를 할 수있게하는 응용 프로그램이 있습니다. 각 싱글 베팅 (= 엔티티)의 점수는 베팅의 베팅 점수와 게임 (= 엔티티)의 실제 결과를 비교하여 계산됩니다. 베팅은 Betrounds 내에서 베팅됩니다. Betrounds는 그룹이 게임 그룹 (게임 그룹, 예 : 단일 성냥갑)에 내기를 걸고있는 조직입니다. 단일 사용자 그룹은 여러 가지 장점을 가질 수 있습니다. 사용자 그룹 1 : N BetRounds 1 : N 베팅 N : 나는 그 결과 지점과 위치에 모든 사용자를 보여 resulttable을 만드는 각 betround 내 한 게임

는 관계형 모델을 요약합니다. 한 사용자의 위치를 ​​계산하려면 betround 내의 모든 사용자의 포인트를 계산해야합니다. 단일 betrounds에서 이러한 지점은 그룹으로 집계되며 그룹 내에 다시 resulttable입니다.

예

• 사용자 그룹과 : 20 사용자
• 한 시즌이 34 차전
• 한 매치 데이가 9 개 게임이에 대한 점수를 계산하기 위해

usergroup 나는 20 * 34 * 9 = 6120 베팅에서 포인트를 계산해야합니다.

계산할 것이 많기 때문에 결과 테이블을 표시 할 때마다이를 수행하고 싶지 않습니다. 아마 데이터베이스

모두의 혼합에

1. 캐시 (예를 들어 내기 엔티티에)
2. 저장 중간 결과 : 나는 현재 약간의 계산 시간을 절약하기 위해 두 가지 옵션을 참조하십시오.

1. 캐시

캐싱 내가하는 수준과 방법을 무효화하는 방법에 확실하지 않다 올바른 방법 인 경우. 무엇을 캐시에 대한 몇 가지 옵션이 있습니다 : - betround의 전체 결과 테이블 (포인트 & 위치) - - 사용자 그룹 내에서 단일 사용자의 pointresult -의 전체 resulttable betround 내에서 단일 사용자의 pointresults - 단일 내기 의 pointresult 사용자 그룹

내가 그 데이터를 캐시하는 방법을 확실하지 오전 : - 바로 정수 위치 값과 포인트 - 전체 엔티티 (예를 들어 내기를) - 일시 영속 엔티티 (예를 들어이 (가) resulttables를 나타내는)를 - html로 테이블의 출력

그런 다음 형식에 따라 캐시하는 방법 : - 역방향 프록시를 통해 HTML보기를 캐시 할 수 있습니다 - 아마 redis/memcache 등을 통해 값/엔티티를 캐시 할 수 있습니다.

나중에 우리는 데이터가 restapi를 통해서만 제공되는 단일 페이지 응용 프로그램으로 변경할 수 있습니다. 그러면 html 출력 캐싱이 옵션이 아닙니다.

캐싱 전략에 따라 캐시를 무효화하고 선택적으로 따뜻하게하는 방법이 있으므로 응용 프로그램 내에서 결과가 계산되지 않고 캐시가 무효화되고 즉시 새 결과로 대체 될 때만 다시 계산되는 문제가 발생합니다.

나는 종종 캐시 무효화가 악하다고 읽었습니다. 내 인터페이스가 게임의 결과를 업데이트 할 때만 모든 포인트/결과/테이블 등이 변경되기 때문에 이것이 나의 유스 케이스에 적용되는지 확실하지 않습니다. 이것은 포인트가 변경되는 유일한 시간입니다. 데이터베이스

에서 (예를 들어 내기 엔티티에)

2.Save 중간 결과 나는이 시나리오는 모든 레벨에 적용 할 경우 확실하지 않다. 먼저 내기 점수를 실제 점수와 비교하는 대신 실제 결과를 내기에 저장하는 방법에 대해 생각했습니다. 그러면 내 데이터 모델이 약간 중복되고 잘못된 결과가 내 인터페이스에서 가져오고 나중에 올바른 결과가 나타나고 내 포인트가 다시 계산되지 않으면 복잡성이 증가합니다.

다른 모든 수준에서 나는 테이블 결과를 지속적으로 저장하기 위해 새로운 임시 엔티티를 생성해야합니다. 모두

의

3.Mix 나는 모두가 좋아하고 전혀 의미가 있다면 어떻게 보일지 혼합 잘 모르겠지만, 나는 그것이 옵션이 될 수있다 생각했다.

조언, 입력 또는 경험을 높이 평가할 것입니다.

Answer 1

나는 베팅을 약간 만 이해하므로 잘하면 도움이됩니다.

당신이 두 가지 질문에 요구하고있다처럼 소리 : 나는 결과를 계산 할 때

1. 를?
2. 얼마나 많은 캐싱을 사용해야합니까?

내게는 매우 명확한 이벤트가 발생하여 결과를 성공적으로 계산할 수있는 것처럼 들립니다. 귀하의 디자인은이 점을 이용하고 자연에서 발생해야합니다. 게임이 완료되었을 때를 감지 할 수있는 백그라운드 프로세스가 있어야합니다. 게임의 결과를 작성해야하며, 해당 게임에 의존하는 모든 베팅의 결과를 계산하기 위해 추가 배경 작업이 트리거되어야합니다.

해당 게임과 관련된 캐시, 해당 게임의 결과 또는 해당 게임의 모든 베팅 결과가 무효화되거나 새로 고쳐 져야하는 지점이기도합니다.

얼마나 캐시해야하는지는 캐시해야하는 양에 따라 달라집니다. 캐싱은 컴퓨팅 결과와 별도로 고려해야합니다. 그건 캐싱하지 않습니다. 그것은 결과를 계산하고 저장하는 것입니다. 페이지보기 요청 중에는 결과를 계산하지 않아야하며 해당 이벤트 (게임 종료)가 계산을 트리거 한시기보다 먼저 수행해야합니다.

데이터베이스는 항상 최신 정보를 나타냅니다. 가능한 경우 즉석에서 계산을 수행하지 않아야합니다.

나는 모든 이벤트와 배경 자료를 먼저 얻은 다음, 어떤 종류의 성과를 얻었는지 확인합니다. 그 시점에서 앱은 결과를 가져 와서 각 페이지 뷰의보기에 고정시키는 것 이상을 수행하지 않아야합니다. 해당 부분이 너무 느린 경우 뷰/템플릿/html 캐싱을 시작해야합니다. 앞서 언급했듯이 새로운 결과가 발생하면 백그라운드 작업자가 이러한 캐시를 무효화 할 수 있습니다.