mysql 千万级别的数据统计

[caqiko]

我们的一个小程序在使用 MySQL 做数据存储，最大的单表 1-2 千万行，每天的增量不到 100W 行。
现在要做统计，可能会关联很多其他的表（活动，产品页面，用户等）。

直接在 navicat 中查，关联几个表，在 distinct 一下，就要一分钟了。
统计结果要做成 API，提供给网页端报表和 APP 端报表使用。

有什么更好的方案吗？

目前想到的临时方案是存储过程写结果表，定时更新。
比如一张表记录每天的新用户数和活跃用户数，一张表记录每天的订单情况。

这样做可以减轻数据库压力，但是不够灵活，运营方有一个需求要统计就需要写一个结果表。
也考虑过数据分层，构建多维数据仓库，然后使用微软的 SSAS 构建 CUBE，不知道这样做还能否通过 API 取 SSAS 中的数？
另外这种方案的成本怎么样？

再另外，现在这种数据量，有上 Hadoop 的必要吗？（目前开发团队主要技术栈是 Node,Python,.Net ）

[snappyone]

你这个需求暂时没必要 hadoop，mysql 从库做统计能满足暂时需求应该

[caqiko]

@snappyone 做从库也还是要写结果表吧？直接统计原始表，同时访问的人多了，压力还是有点大

[aru]

@caqiko 你说的对。用从库做统计，然后定时写结果表

[misaka19000]

你这个需要的是 OLAP 吧？

[roscoecheung1993]

@caqiko 从库就很自由了...愿意写结果表就写结果表，不愿意写就随时跑 sql 呗～跑几个小时即使高负载也不影响主业务的

[caqiko]

@roscoecheung1993 但是前端报表要能及时看到啊。。不能前端请求等几个小时才出来个图片。。

[caqiko]

@misaka19000
我们现在也考虑使用 olap 不知道您对产品选型有没有什么好的建议？

[endershadow]

clickhouse 完事

[mind3x]

Druid 了解一下

[npe]

数据太大没办法做到实时，建议用定时任务，将数据提前准备好。代价是：数据延迟一天。

[myyou]

Hadoop+kylin 可以做实时查询。数据量早晚都变大，不如尽快上 Hadoop，也方便前期积累经验。

[akira]

目前想到的临时方案是存储过程写结果表，定时更新。
比如一张表记录每天的新用户数和活跃用户数，一张表记录每天的订单情况。
------------------
就是这个方案 起码足够你们再抗一年半年了

[KasonPasser]

我之前做了一个，就是每半小时就统计一次当天的数据。不过我这对数据的实时要求是没有那么高的，同时这样统计会是有一些数据有差异性，要能接受这差异才可以这样使用。

[snappyone]

@caqiko 还有个方案，用 canal 拉 mysql 增量数据处理之后再合并，但是有一定限制，你可以看看适合你们不

[beidounanxizi]

elk 轻松搞定 MySQL 单表查询千万级还是能 hold 住的 好好利用索引也没问题 join 查询的话 还是预处理数据走 elk 吧

[xiaochun41]

这个量级索引使用合理的话，直接使用 sql 查没什么问题。
如果担心影响数据库上的实时业务，像上面的同学说的，可以使用从库做统计，
也可以考虑通过采集日志的方式来做。

[DiverRD]

从库，索引利用好，把复杂的语句联表这些拆成简单的语句，多查几次。 千万级别还是可以应付的，没必要实时，允许数据一定承受范围内的延迟。

[fun]

druid 很适合

[Vamposine]

apache kylin 项目了解一下，数据源可以对接 mysql，支持 sql 查询，秒级响应

[Vamposine]

当然如果公司有预算，可以上 Kyligence Enterprise 企业版（ apache kylin 的商业版），有兴趣可以联系我