현재 프로젝트에는 대략 다음과 같은 흐름 테이블 구조가 있습니다.
id sdkVersion jarVersion countryCode imei createTime
이전 요구사항은 sdkVersion, jarVersion, countryCode를 그룹화하여 총 개수를 구하고 imei 정렬 후 총 개수를 구하는 것이었습니다.
으아아아전날의 데이터를 모두 찾아 표로 정리하면 대략 다음과 같습니다
id sdkVersion jarVersion countryCode 개수(*) 개수(고유한 imei) createTime
그러면 현재 수요는 이전 일일 요약 계획에 따른 경우 모든 위도의 조합, 즉
group by sdkVersion
group by jarVersion
group by countryCode
group by sdkVersion, countryCode
및 기타 조합을 쿼리하는 것입니다. 다양한 위도 조합에 대해 많은 테이블을 생성해야 합니다. 이 문제에 대한 좋은 해결책이 있습니까? 아니면 전문적인 통계 프레임워크를 사용하여 해결할 수 있습니까?
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
PipelineDB 스트리밍 데이터베이스를 확인하실 수 있습니다
apache kylin, 1초 미만의 olap
일일 요약의 경우 실시간 요구 사항이 높지 않으며 500W 기록이 여전히 처리 범위 내에 있습니다. 보기 + 타이밍 계획이 요구 사항을 충족할 수 있으며 여러 테이블을 구축할 필요가 없습니다.
질문자가 어떤 병목 현상이나 문제점이 있는지 설명하는 것이 가장 좋습니다. 결국 mysql은 성숙한 제품이므로 최첨단 기술로 전환하는 데에는 특정한 위험이 있습니다.
저장 프로시저를 작성하고 매일 정기적으로 실행