背景介绍
在业务逐渐增长的4年多里,我公司的的数据库经历了从单表数十GB到上百GB的过程。基于数据量的升级变迁,我们的数据库也经历了2次架构迭代,并在探索三代数据库架构:第一代数据库架构一主一从集中式部署的时代。第二代数据库架构垂直分库,一主多从的时代。第三代数据库架构云上一主一从一日志节点,基于域名vip实现高可用的时代。
第三代数据库架构短板OLTP场景需求痛点
截止目前账务系统的核心表累计数据量已达到单表8000万行以上,还在高速增长中。监管要求金融行业历史数据至少保留5年以上。这给数据库系统带来了不小的挑战:海量的历史交易与账务数据堆积在MySQL数据库中,使数据库越发臃肿,维护困难(在线DDL变更、数据迁移、磁盘容量瓶颈、磁盘IO瓶颈等)。ccsorderhst表现有8800万,56G数据,日均增长18万,ibd文件日均增长120MB,预计到年末将趋近80G。用户对历史交易订单的查询(OLTP场景)是必备功能,这些海量的历史数据会根据用户需求通过微信公众号、APP终端等渠道进行实时查询(内部、外部用户)。此场景决定了不能通过传统的离线大数据方案来满足需求。需要一种偏向于前台、中台的数据治理方案。海量数据也会导致核心跑批时间延长,同时导致数据库单点性能瓶颈,应用可以加分片,但是数据库无法水平扩展。传统分库分表解决方案痛点分表跨实例后,产生分布式事务管理难题,一旦数据库服务器宕机,有事务不一致风险。分表后,对SQL语句有一定限制,对业务方功能需求大打折扣。尤其对于实时报表统计类需求,限制非常之大。对join语句不友善。分表后,需要维护的对象呈指数增长(MySQL实例数、需要执行的SQL变更数量等)。
分布式数据库技术选型
基于第三代数据库架构的核心痛点,我们需要探索新的数据库技术方案来应对业务爆发式增长所带来的挑战,为业务...
(全文)