正在做一些运营支撑,统计一些数据。
这些统计如果用 sql 写的话,会很复杂,并且有可能会影响到 sql 的性能。
现在有些统计就不直接用 sql 统计了,而是把数据统一查询出来,然后再使用代码来分析统计
哪种方式会比较好?
1 p2pCoder 2018-08-21 11:56:06 +08:00 这种需求 应该交给 数仓 |
![]() | 2 yidinghe 2018-08-21 13:42:01 +08:00 看对统计效率是否有要求。如果要求很高,那么还是要花大量精力做针对性的设计调优。 1、自己在代码里面分析,效率反而低,因为 SQL 的复杂度实际上就是业务的复杂度,后者代替前者得不偿失。 2、用大数据框架统计也可以,但花费的时间可能要多上十倍几十倍。 |
![]() | 3 F281M6Dh8DXpD1g2 2018-08-21 13:48:16 +08:00 你觉得你能比 mysql code 写的好你就自己写呗 大概率不能,mysql 再烂,毕竟优化快二十年了 |
4 zr8657 2018-08-21 13:50:29 +08:00 有种方法是把要查的多表数据存成一张表,然后直接查 |
5 humansjl 2018-08-21 15:46:25 +08:00 这没有一定说哪个好哪个不好的,看 sql 影响到的性能 vs 额外建数据仓库 两者取舍了,或者一步一步来,每条 sql 先试着调优看看,毕竟调优有时候也挺花时间的 |
![]() | 6 awah 2018-08-21 16:14:04 +08:00 可以用存储过程试试. 在存储过程里面将任务分割, 最后汇总到一张表里面. |
![]() | 7 Immortal 2018-08-21 16:19:53 +08:00 视图 或者 从库 目前我是用的后者 |
8 wqzjk393 2018-08-21 16:22:08 +08:00 你的意思是表内容太大,直接用聚合分析函数写复杂的查询逻辑会很慢,所以就直接 select*然后导出来,用别的方法处理?首先那么大的数据量不是应该用 hive 平台么?另外如果真的想导来处理,可以用 pandas,基本的 groupby 透视什么的都有 |
9 wqzjk393 2018-08-21 16:24:11 +08:00 我很多时候都是用的视图,分开一层层的写逻辑。要不然一堆子查询和关联套来套去很容易晕而且后期不好修改时候不容易理解当时的逻辑。 |
![]() | 10 szq8014 2018-08-21 16:28:19 +08:00 觉得驴累了就把驴抗起来走么? |
![]() | 11 he583899772 2018-08-21 19:00:08 +08:00 卧槽,平时我都是为了减少复杂用 sql 去避免复杂的业务逻辑代码。。。 |
![]() | 12 alcarl 2018-08-21 20:32:03 +08:00 via Android 不说具体泛泛而谈等于没说,SQL 这种东西就是为了统计数据而生的语言,能站巨人肩膀上谁还站地上。 |
![]() | 13 realpg PRO 做个 slave 然后随便在 slave 上统计 |
![]() | 14 xmh51 2018-08-21 21:13:01 +08:00 ![]() 做个从库啊 在从库查询 |
15 hayman 2018-08-22 00:23:06 +08:00 via Android 你也可以把数据库流入到 kafka,起一个 ksql server 进行实时的统计, 需要的时候直接从 topic 取结果。 |
![]() | 16 szq8014 2018-09-11 15:36:18 +08:00 挖个坟,这不是 SQL 的锅,是思路的事,看你的更新后思路应该是没问题了。其实新思路也可以用 SQL 完全写出来。 关键字搜 行转列 |