炼数成金 门户 大数据 数据库 查看内容

对于大表的写入和统计查询该如何权衡,我有四个解决思路

2019-10-10 15:03| 发布者: 炼数成金_小数| 查看: 26455| 评论: 0|原作者: 杨建荣|来自: 杨建荣的学习笔记

摘要: 首先根据描述业务情况,业务部门的需求其实更偏向于AP方向的业务,执行频率不高,但对数据准确性要求高。 当然至于具体的解决方案,上层需求不应该关注底层的技术细节,而是做到技术有效支撑即可。所以从我的理解中 ...

数据库 存储 Hadoop 集群 培训

今天在微信群里大家在讨论一个数据处理的解决方案,各路高手齐上阵,大家从不同的角度都提了一些建议和解决方案,这种讨论蛮有意思。 
我简单总结下这个问题,也把我的思考梳理一下。 

问题的背景:
有一个朋友的Mycat中指向了很多历史库,而又无法弄一个准确的规则分片,这样会导致虽然调用的是maycat,但是mycat其实到了order_2014,order_2015,order_2016,order_2017,order_2018,order_2019这个6个数据库中分别查了1次,这样虽然拿到了数据,但是效率很低的,要是能根据平台订单号直接找到数据库就好了,但是因为没有规则的,或者业务层面的一些原因,难以统计,所以难以规范出来,但是可以确认的是,如果功能要用的地方如果要查历史订单库 90%的数据是在2019年的,7%是在2018年,2%是在2017年,1%在其他里面,所以我想根据数据库的名字取给它默认查询优先级,比如一个订单过来,默认先查order_2019,里面没有再查order_2018,以此类似,这样虽然做不到极致,但是可以尽量坚持底层的查询次数。

经过进一步沟通,每月生成的数据在一千万左右,每个月会由业务部门发起一次业务需求,做一些数据统计和验证,对于处理时间,目前没有很明确的要求,当然是越快越好,其实在可行范围内就行。

从这个描述来看,这算是一个开放性的问题,而且是真实的一个场景,我们可以通过这个问题来得出很多的解决思路。 
首先根据描述业务情况,业务部门的需求其实更偏向于AP方向的业务,执行频率不高,但对数据准确性要求高。 当然至于具体的解决方案,上层需求不应该关注底层的技术细节,而是做到技术有效支撑即可。
所以从我的理解中,月数据量在一千万,其实量级不大,按照几年的饿一个维度来存储,这个量级其实也可以接受。

我有几种迭代方案:
1.单独建一个归档库,把这些年的订单放在一起,即可以统一访问入口,比如order表,数据按照业务ID分片(如果没有,自增ID也行,不做业务逻辑接入),底层可以使用mycat分片,性索引需要在订单号上面,分片得略微多些,按照一个周期(3年,5年,10年这样)来设计 

2.使用mySQL列式存储引擎infobright,社区版足够,60亿的统计大概10秒左右出数据,需要离线文件load,不支持DML ,其中的方案特点就是针对列式存储的方式来大大提高效率,当然是用HBase也是可以的。

3.考虑TiDB的方案,大数据量效果也不错,建议直接写入TiDB,次之业务双写,如果TiDB做sync源,复杂度高,而且难以追溯,性能可以做下权衡 。其中如下图,可以在TiKV层面做横向扩展。


4.可以考虑规划OLAP集群,比如greenplum这种,GP底层可以做分片,可以指定分片策略和分表策略,通过mycat集群的分片做数据流转到GP,GP只做T+1的离线统计查询 


前3种都是基于MySQL协议,相对来说接入成本会低一些,第4个方案是一个长期规划的方案,需要的是整体的规划和推动力,当然也有需求优先级密切相关。

当然所说的大表,前提数据量一定得大,否则引入的技术复杂度还不如单表简单。

今天读到的一段文字,让我有一种莫名的感同身受,尽管经历不同:我希望你们不要和我一样,耽误了十二年,快被业内淘汰的时候才把早该弄明白的问题搞清楚。

个人公众号:jianrong-notes

声明:本文版权归原作者所有,文章收集于网络,为传播信息而发,如有侵权,请联系小编及时处理,谢谢!

欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括:Java,C/C++,Python,PHP,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流
QQ群:26931708

Hadoop源代码研究群
兴趣范围包括:Hadoop源代码解读,改进,优化,分布式系统场景定制,与Hadoop有关的各种开源项目,总之就是玩转Hadoop
QQ群:288410967 

鲜花

握手

雷人

路过

鸡蛋

相关阅读

最新评论

热门频道

  • 大数据
  • 商业智能
  • 量化投资
  • 科学探索
  • 创业

即将开课

 

GMT+8, 2019-11-20 14:39 , Processed in 0.140588 second(s), 25 queries .