网站维护是做什么的,手机端网站整站下载,莱芜网页定制,专做火影黄图的网站实时历史库需求背景
在当今的数字化时代#xff0c;随着业务的迅速发展#xff0c;每天产生的数据量会是一个惊人的数量#xff0c;数据库存储的成本将会越来越大#xff0c;通常的做法是对历史数据做归档#xff0c;即将长期不使用的数据迁移至以文件形式存储的廉价存储…
实时历史库需求背景
在当今的数字化时代随着业务的迅速发展每天产生的数据量会是一个惊人的数量数据库存储的成本将会越来越大通常的做法是对历史数据做归档即将长期不使用的数据迁移至以文件形式存储的廉价存储设备上比如阿里云OSS或者阿里云数据库DBS服务。
然而在部分核心业务的应用场景下针对几个月甚至几年前的“旧”数据依旧存在实时的低频的查询甚至更新需求比如淘宝/天猫的历史订单查询企业级办公软件钉钉几年前的聊天信息查询菜鸟海量物流的历史物流订单详情等。
• 如果这时从历史备份中还原后查询那么查询时间将会是以天为单位可接受度为0
• 如果将这些低频但实时的查询需求的历史数据与近期活跃存储在同一套分布式数据库集群下那么又会带来以下两大挑战
存储成本巨大进而导致成本远大于收益比如钉钉聊天信息数据量在高度压缩后接近50PB很难想象这些数据不做压缩会带来多大的资金开销性能挑战巨大随着数据量越来越大即使针对数据做了分布式存储单实例容量超过大概5T以后性能也会急剧下滑进而影响到近期活跃数据的查询性能拖垮整个集群运维难度巨大比如针对海量数据下发一个表数据结构变更操作很难想象全部完成需要多长时间
实时历史库场景需求分析
通过上面的分析不管是冷备份还是在线历史数据混合存储在同一张物理表上的方法都是不可取的一般实时查询历史数据库的场景一般需要有以下几个关键特性
成本可控历史数据的存储成本无法接受和在线库一样线性增长实时查询历史数据的查询RT要做到与在线活跃库几乎一致查询频次较低一般来说越“旧”的数据查询频率越低统一查询入口不管是活跃数据还是历史数据查询入口保持一致改造成本需要尽可能低最好能做到不做任何应用代码修改可以认为历史库对程序开发人员来说是完全透明的可能存在历史数据更新需求数据规模较大一般在100TB以上
X-Engine引擎介绍
X-Engine简介
X-Engine是阿里云数据库产品事业部自研的联机事务处理OLTPOn-Line Transaction Processing数据库存储引擎。作为自研数据库POLARDB的存储引擎之一已经广泛应用在阿里集团内部诸多业务系统中包括交易历史库、钉钉历史库等核心应用大幅缩减了业务成本同时也作为双十一大促的关键数据库技术挺过了数百倍平时流量的冲击。 与传统的InnoDB引擎不同X-Engine使用分层存储架构LSM-Tree。分层存储有两个比较显著的优点
需要索引的热点数据集更小写入性能更高。底层持久化的数据页是只读的数据页采用紧凑存储格式同时默认进行压缩存储成本更低。
相比InnoDB引擎依据数据特征使用X-Engine存储空间可降低至10%~50%我们在著名的Link-Bench和阿里巴巴内部交易业务两个数据集上测试了X-Engine的存储空间效率。在测试中对比开压缩的InnoDB引擎X-Engine有着2倍空间优势而对比未开压缩的InnoDBX-Engine则有着3~5倍的优势。
实时历史库方案为何不是其他高压缩引擎
• 通常我们默认MySQL是当今最流行的开源数据库大概率是在线核心数据库集群的首选。相比其他高压缩的存储引擎引入X-Engine完全无需做任何SQL代码改造并且支持事务接入成本最低学习成本几乎为0
• 写入性能更强X-Engine相比同为LSM-tree架构的Rocksdb有超过10倍的性能提升。
• 在存储层引入数据复用技术等优化Compaction的性能降低传统LSM-tree架构中Compaction动作对系统资源的冲击保持系统性能平稳
• 引入多个层级Cache同时结合Cach回填和预取机制利用精细化访问机制和缓存技术弥补传统LSM-tree引擎的读性能短板X-Engine的点查询能力几乎与Innodb持平
下图是X-Engine与主流历史数据存储方案对比
历史数据存储选型备份至OSS开源HBaseX-Engine压缩率高高高是否支持查询支持解析历史备份文件查询高高实时性N/A较高非常高应用代码改造代价N/A很高几乎不用修改事务支持N/A仅支持单行事务强主要场景冷备份大数据生态OLTP
实时历史数据库架构设计和实现
总体架构思路
基于上文对实时历史库和X-Engine的介绍阿里云数据库团队推出以X-Engine引擎为历史数据存储核心同时生态工具DTS作为在线/历史数据流转通道DMS作为历史数据无风险删除的完整“实时在线-历史库”方案针对不同的业务场景和客户需求在具体实现上可能会有所不同我们提供了多种实时历史库方案的具体实现。主体架构图如下核心思路为
久经考验的Innodb引擎作为OLTP在线库核心引擎主要处理高频查询/更新请求满足在线活跃数据高并发高性能强范围查询的业务需求阿里巴巴数据库团队自研的高压测存储引擎X-Engine作为历史库核心引擎主要响应历史数据入库/查询/更新请求满足历史数据冷热数据频次不一低存储成本高性能的业务需求(范围查询可能性能受限)统一DB接入层根据设置的业务时间属性将请求分别转发至不同的存储引擎。针对特殊场景下的跨引擎访问在应用层做聚合展示在线-历史数据通过阿里云提供的生态体系工具做历史数据迁移和过期数据删除确保链路更为稳定可靠在线库/历史库拆分方案
一般来说需要使用到实时历史库的场景数据量都足够大到单台宿主机存放不了。在线数据库可能是根据业务水平或垂直拆分的多个RDS也可能是一个规模较大的DRDS集群。为了尽可能地保证在线库的性能推荐将在线库/历史库完全拆分解耦 • 历史库集群存储全量数据 • 通过DTS链路打通在线库和历史库实时同步 • DTS链路过滤Delete操作 • 可直接使用新版DMS配置历史数据定期删除
源端为DRDS集群
数据同步链路走RDS
• 多条DTS链路打通底层RDS节点同步性能强 • RDS数量较多可支持API批量创建和配置 • 链路稳定性更好 • 需要保证源端目标端库表数量一致数据路由规则一致
数据同步链路走DRDS
• 只需要配置一条DTS链路方便省钱 • 数据同步性能较差 • 源端DRDS扩容会影响到DTS同步链路 • 源端目标端的实例数量和数据路由规则可自由配置
源端为多个RDS
目标端为多个RDS
• 业务代码无需任何改造 • 运行后期历史库节点磁盘容量存在风险
目标端为DRDS集群
可能涉及到业务代码轻量改造目标端不走分库分表键性能无法保证可将多个在线库业务合并至一套历史库集群架构更加简洁DTS链路也分为走RDS和DRDS两种
数据同步链路走RDS
同实例混用存储引擎方案
在线库/历史库拆分方案相对较为复杂RDS支持同一实例混用存储引擎。针对总数据量不是特别大的场景可以考虑同一实例下InnodbX-Engine引擎混合使用
使用DMS--数据工厂--数据编排功能可以轻松地实现同一实例内的数据流动和过期数据删除架构示意图如下。
实现简单灵活混用存储引擎在数据库内核参数优化上难以兼顾两者性能历史数据compact阶段可能对整个实例产生性能抖动同一实例下的库或者表无法重名涉及到轻量业务改造DTS赋能在线/历史数据流转
DTS不仅支持全量增量同步支持不同数据库产品之间的数据同步在在线/历史库解决方案中DTS强大的条件过滤功能是非常重要的一环通过配置DTS任务可以非常便捷地实现过滤Delete操作动动鼠标点两下即可实现自定义的数据同步策略。
DMS赋能在线库过期数据删除
在线库的过期数据删除既要保障删除效率也要保证删除过程中对在线库不会造成性能上的抖动新版DMS支持创建“历史数据清理”的数据变更任务通过该任务可以非常方便地完成以下工作
• 历史数据定期删除指定调度时间和一次调度时长 • 大事务拆分减少事务执行过程中锁表时间过长避免主备延迟 • 清理遭遇异常中断可重试 • 支持查看任务运行状态和失败原因分析 • 配置方面简洁
过期数据清理思路
如果没有使用DMS生态工具也自行实现过期数据删除但实现较为复杂。一般较为通用的设计思路为将表的主键按照大小做拆分保证一次删除恰当数量的数据既保证删除效率又不影响线上服务
• 在线库的历史数据删除策略(假设主键为id数据保存180天时间属性列为date_col)
初始化数值Yselect min(id) from $table_name到了业务低峰期以后DELETE FROM $table_name WHERE date_col SUBDATE(CURDATE(),INTERVAL 180 DAY) and id Y and id Y100000 ,执行成功后代码层重新赋值 YY100000程序sleep 3s,重复步骤b时间到了业务高峰期以后停止执行记录下当前的数值Y第二天执行时直接从Y开始注意
• 在线库历史数据清理注意点
• 代码上注意不要出现高并发删除的情况即步骤b还没跑完新的步骤b又进来了
• 程序sleep的具体秒数要通过测试取一个最合适的数值主要看主备是否存在较大延迟3只是估值
• 100000也是一个估值实际取值最好也通过测试取一个效率最高对业务影响最小的数值。因为drds的序列不是单点递增1的所以这里的10w不代表10w条记录。
• 假设删除程序中途崩溃了或者执行很多天后发现部分数据没有删除。那么可以手工先删除一小部分残留的数据比如预估下id100w的记录还有多少条不多的话直接执行DELETE FROMlogs_trans WHERE reqdate SUBDATE(CURDATE(),INTERVAL 30 DAY) and id100w 然后初始化整个程序,这样保证重新初始化以后不会做很多无用功即反复执行删除条目很少的sql
极端场景分析 在临界时间处理上实时历史库方案可能遭遇极端场景导致业务可能存在历史库的脏读问题假设在线库数据保存180天
更新179天前23时59分59秒的数据请求路由至在线库数据同步链路异常中断或链路存在延迟该更新请求未能及时到达历史库这时业务查询该数据时由于已经数据已经旧到超过180天请求路由至历史库由于链路异常历史库查到了脏数据
解决方法
• 配置链路异常告警及时发现及时处理
• 预计影响的数据范围为DTS链路恢复前的临界时间点附近数据建议从业务逻辑上订正数据
• 建议过期数据删除设置保守一点比如临界时间为180天过期数据只删除190天以后的数据方便在极端场景下对比源端目标端的数据情况进行数据订正
最佳实践参考
将DRDS中的InnoDB引擎转换为X-Engine引擎链接 X-Engine如何支撑钉钉跃居AppStore第一链接 淘宝万亿级交易订单背后的存储引擎链接
原文链接 本文为云栖社区原创内容未经允许不得转载。
