这是学习笔记的第2127篇文章
今天在微信群里大家在讨论一个数据处理的解决方案，各路高手齐上阵，大家从不同的角度都提了一些建议和解决方案，这种讨论蛮有意思。
我简单总结下这个问题，也把我的思考梳理一下。
问题的背景：
有一个朋友的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，以此类似，这样虽然做不到极致，但是可以尽量坚持底层的查询次数。
经过进一步沟通，每月生成的数据在一千万左右，每个月会由业务部门发起一次业务需求，做一些数据统计和验证，对于处理时间，目前没有很明确的要求，当然是越快越好，其实在可行范围内就行。
从这个描述来看，这算是一个开放性的问题，而且是真实的一个场景，我们可以通过这个问题来得出很多的解决思路。
所以从我的理解中，月数据量在一千万，其实量级不大，按照几年的饿一个维度来存储，这个量级其实也可以接受。
我有几种迭代方案：
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个方案是一个长期规划的方案，需要的是整体的规划和推动力，当然也有需求优先级密切相关。
当然所说的大表，前提数据量一定得大，否则引入的技术复杂度还不如单表简单。
今天读到的一段文字，让我有一种莫名的感同身受，尽管经历不同：我希望你们不要和我一样，耽误了十二年，快被业内淘汰的时候才把早该弄明白的问题搞清楚。
个人新书《MySQLDBA工作笔记》
个人公众号：jianrong-notes
