現在、プロジェクトには次のようなフロー テーブル構造があります
id sdkVersion jarVersion countryCode imei createTime
以前の要件は、sdkVersion、jarVersion、countryCode をグループ化して合計数を検索し、imei でソートした後の合計数を見つけることでした。おおよその SQL は次のとおりです:
リーリー前日のデータをすべて取り出して表にまとめると、おおよそ次のような構造になります
id sdkVersion jarVersion countryCode count(*) count(distinct imei) createTime
その後、現在の要件は、任意の緯度の組み合わせをクエリすることです。つまり、
group by sdkVersion
group by jarVersion
group by countryCode
group by sdkVersion、countryCode
などです。組み合わせについて、以前の毎日の要約計画に従う場合、さまざまな緯度の組み合わせに対して多数のテーブルを作成する必要があります。この問題を解決する良い解決策はありますか?それとも、特殊な統計フレームワークを使用して解決できるのでしょうか?
曾经蜡笔没有小新2017-05-19 10:09:03
日次集計の場合、リアルタイム要件は高くなく、500W レコードはまだ処理範囲内であり、ビュー + スケジュールされたプランで要件を満たすことができ、複数のテーブルを構築する必要はありません。
結局のところ、mysql は成熟した製品であり、最先端のテクノロジーに切り替えるには一定のリスクが伴います。