Il existe désormais une structure de table de flux dans le projet, qui est à peu près la suivante
id sdkVersion jarVersion countryCode imei createTime
L'exigence précédente était de trouver le nombre total en regroupant sdkVersion, jarVersion, countryCode et le nombre total après le tri imei. Le SQL approximatif est le suivant :
select sdkVersion,jarVersion,countryCode,count(*),count(distinct imei) from xxx
where createTime = 'xxxx-xx-xx'
group by sdkVersion,jarVersion,countryCode
Découvrez toutes les données de la veille et résumez-les dans un tableau. La structure est à peu près la suivante
.id sdkVersion jarVersion countryCode count(*) count(imei distinct) createTime
Ensuite, la demande actuelle est d'interroger la combinaison de n'importe quelle latitude, c'est-à-dire
group by sdkVersion
group by jarVersion
group by countryCode
group by sdkVersion, countryCode
et d'autres combinaisons, si selon le plan récapitulatif quotidien précédent, nous avons besoin créer de nombreux tableaux pour différentes combinaisons de latitude. Existe-t-il une bonne solution à ce problème ? Ou peut-il être résolu à l’aide d’un cadre statistique spécialisé ?
Vous pouvez consulter la base de données de streaming PipelineDB
apache kylin, olap en sous-seconde
Pour un résumé quotidien, les exigences en temps réel ne sont pas élevées et les enregistrements de 500 W sont toujours dans la plage de traitement. View + le plan planifié peut répondre aux exigences, et il n'est pas nécessaire de créer plusieurs tables.
Il est préférable que la personne qui pose la question explique quels sont les goulots d'étranglement ou les problèmes. Après tout, MySQL est un produit mature et le passage à une technologie de pointe comporte certains risques.
Écrivez une procédure stockée et exécutez-la régulièrement tous les jours