현재 프로젝트에는 대략 다음과 같은 흐름 테이블 구조가 있습니다.
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
및 기타 조합을 쿼리하는 것입니다. 다양한 위도 조합에 대해 많은 테이블을 생성해야 합니다. 이 문제에 대한 좋은 해결책이 있습니까? 아니면 전문적인 통계 프레임워크를 사용하여 해결할 수 있습니까?
曾经蜡笔没有小新2017-05-19 10:09:03
일일 요약의 경우 실시간 요구 사항이 높지 않으며 500W 기록이 여전히 처리 범위 내에 있습니다. 보기 + 타이밍 계획이 요구 사항을 충족할 수 있으며 여러 테이블을 구축할 필요가 없습니다.
질문자가 어떤 병목 현상이나 문제점이 있는지 설명하는 것이 가장 좋습니다. 결국 mysql은 성숙한 제품이므로 최첨단 기술로 전환하는 데에는 특정한 위험이 있습니다.