面对跨月查询需求和数据量增长，原有的MySQL存储方案达到瓶颈。文章探讨了转向分布式大数据存储的可能性，如Hive，并通过压力测试验证其性能。同时，针对财务数据的敏感性，提出了加密存储方案，确保加密前后聚合操作的一致性，以保证数据安全。总结指出，对于超过2000w数据量的报表场景，Hive是良好选择，并提倡勇于尝试新技术并进行充分测试。
工作需求:
存储: mysql
数据量: 每月100w~500w
现状: 当前存储没有问题，单月查询在总表2000w之内，索引优化好，能支撑现有业务
需求:业务比较稳定后业务方有跨月查询的需求，折中估计每月250w数据，查询12月，数据量为3000w，单表数据量突破经验值2000w常规的索引优化左襟见拙
分析: 分表是是不可行，当前跨月的报表分析结果主要为一个复杂的查询，全量聚合操作+子查询。落地一张聚合表，可以探索但，前端报表筛选条件涉及到各个维度，存在储存最粗粒度的数据就要牺牲前端筛选条件，是不能接受，存最细单表已预估一年量为3000w，传统的调优参数，mysql存储已经到了天花板，加内存和机械硬盘换固态硬盘?成本太高，不能接受，缓存层思考，预估一些用户的查询行为，比如只允许按季度查询?这样按照季度分区，可行，但限制了报表分析能力，可接受但总是糜烂着工程师的妥协。思考过后，能不能从传统的数据库转向分布式大数据的存储方案，例如mycat, hive, Hbase, impala。
思考: 传统数据库因为有着数据量小查询快，而且具备强一致性的锁机制和事务机制，分析本需求，报表只是单纯的供查询，０事务，不存在加锁增删改操作，因为之前使用mycat的经验，坑比较多，比如count函数会出现多个分片的结果，所以目标锁定为hive，hive的表结构可以和mysql表结构相似，使用也较SQL比较相似。
待解决的问题
- 压测是否满足查询的性能问题，跨月数据量已３年数据量预估最大值进
最低0.47元/天 解锁文章
扫一扫
862
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
