出口电商网站建设程序,网站建设与管理需要什么软件有哪些,工业软件开发前景,chatgpt在线背景
随着平台的不断壮大#xff0c;业务的不断发展#xff0c;后端系统的数据量、存储所使用的硬件成本也逐年递增。从发展的眼光看#xff0c;业务与系统要想健康的发展#xff0c;成本增加的问题必须重视起来。目前业界普遍认同开源节流大方向#xff0c;很多企业部门…背景
随着平台的不断壮大业务的不断发展后端系统的数据量、存储所使用的硬件成本也逐年递增。从发展的眼光看业务与系统要想健康的发展成本增加的问题必须重视起来。目前业界普遍认同开源节流大方向很多企业部门也针对数据库存储降低成本进行了尝试有的删数据、有的删索引、有的做压缩、有的做冷热分离方式方法层出不穷不一而足然而不是因为收效甚微而导致没有达到预期就是由于改造成本过大投入周期过长导致投产比不高虚耗人力。笔者目前所在部门也正好面临同一问题一个账单系统存储数据超过100T占用40台物理机40库一个分表就有20480张这样的分表有4个这种存储架构相对臃肿要想实践降低成本的诉求难度很高。
本文主要介绍方法方案也会涉及但不会特别细致的展开。
挑战
核心挑战有以下几个
数据安全问题无论是删数据做压缩冷热分离对于已经占据100T磁盘空间的存储系统都是困难的操作一个不小心数据丢失了或者无法正常获取数据了这些问题对部门、对公司都会造成巨大损失。
系统稳定性问题一些有效的降低存储空间的方案如数据序列化、压缩等无外乎是用时间换空间牺牲性能换取磁盘空间的降低那么从实际业务影响来看用户看到页面的耗时增高了读延时或用户看到自己的数据迟迟未更新写延时用户的使用体验会降低。从系统影响的角度来看读写耗时的增高对于系统本身饱和度会产生影响写方面吞吐量下降了读方面耗时增加了这些变化会导致系统线程数增高甚至导致线程堆积cpu占用也会相应增高最终可能会产生系统拒绝请求系统夯住等问题。
收益问题中文互联网上数据库存储成本降低方案永远能看到一些词汇如“删索引”“元数据清理”“冷热分离”等这些眼熟的词汇看似收益不错大家也常提起。然而删索引的收益受到实际使用索引的情况收益浮动非常之大。我们都知道索引有单字段索引有多字段的联合索引联合索引会产生笛卡尔积的复杂度如5岁的张三6岁的张三5岁的李四10岁的李四等等这样则不好测算删除某个索引所带来的正向收益。因此删除索引这个方案通常是在索引滥用的情况下使用在清理滥用索引的过程中附带降低了一些磁盘占用。而“冷热分离”是另一种极端它改变了原有系统的存储架构架构合理性也许会提升但这个系统改造成本是巨大的如冷热数据的同步机制冷数据的迁移方案原数据库冷数据清理方案冷数据压缩方案、生产灰度方案等。改造成本非常高周期长耗费人力大风险还非常高唯一值得欣慰的是效果通常能够达到预期。
体系化方法
字段表库删删除无效表减减少无效数据 减少无效索引缩大字段压缩大表压缩冷热分离
中文互联网上的缩减数据库磁盘空间的方案很多但大多是方案的陈述对于如何针对目标系统制定适合的缩减方案的内容很少其实按照麦肯锡切分法的逻辑切分法就可进行一个方法总结。上图的九宫格就是按照笔者的实践经验总结出一个体系化成本降低的方法。
九宫格
按逻辑梳理的办法方案可针对字段、表和库3个维度结合删、减、缩3种策略进行梳理如删除表、清理部分表数据、压缩部分表的存储空间等。结合系统的实际情况按照表格进行梳理就能得到适合目标系统的成本降低方案了。
笔者通过表格结合账单系统实际情况梳理出的执行的方案1、大表压缩2、大JSON字段序列化3、删除无效数据4、无效表删除5、无效索引删除6、冷热分离。
这么多的方案总不能囫囵吞枣的瞎干吧优先干哪个呢他们的收益又是怎么样的呢
收益测算
在实际的方案阶段都需要对方案产生的收益进行度量再按照投产比决定方案执行的优先级。
测算方法
无论何种方案测算起来无外乎抽样、估算减少量、计算占比几个过程。
举个例子
以大JSON字段序列化为例某个字段存储的是大json串占用的字符比较多因此对该字段做压缩能够有效的降低磁盘占用空间。这个方案如何测算呢思路是这样的首先计算出目标大json字段占一条数据字符长度的比例然后根据压缩比得出压缩后该字段减少的字符数占比之后抽样此表的data文件占的磁盘空间如3g得出单表通过压缩后下降的磁盘空间如1.2g最终再乘以该表的数量如20480就能估算出最终减少的磁盘空间。最终计算公式 [压缩后减少的字符数/总字符数]_单表空间_表数量[大json字符数*1-压缩比/总字符数]_单表空间_表数量12t 磁盘减少占比12t/95.9t12%
如何得到字段的字符数
可运用select LENGTH语法得出。具体计算可参照下表 最终账单系统各方案的测算结果大表压缩32%大JSON字段序列化12%删除无效数据10%无效表删除与无效索引删除都在1%左右。通过测算情况我们就可以建立方案执行的优先级了step1大表压缩step2大JSON字段序列化step3删除无效数据等。冷热分离有收益但是成本太高可在日后架构升级中再去考虑。
数据安全与系统稳定性
前文提到过无论采用何种方案数据安全与系统稳定性都需要验证的数据丢失、或系统不可用、或降低用户体验下降过多都是不可接受的。因此需要保障这些情况尽量不要发生或即使发生了问题也在可控、可接受范围内。
方法
黄金指标
任何稳定性或安全性问题都可通过google SRE的4个黄金指标去归纳即异常exception、耗时tp99等、流量tps、饱和度cpu、内存、磁盘、网络等。
可以结合目标系统的关键时段来看这4个黄金指标例如大表压缩方案那就可以关注压缩时的异常、耗时等压缩后的异常耗时等等。
结合实际验证项
压缩时1、读写耗时是否增加2、吞吐量是否受到影响3、压缩是否会产生异常4、异常后压缩过程能否正常回滚5、压缩是否会导致数据丢失
压缩后大促高峰期1、读写耗时是否增加2、吞吐量是否受到影响3、压缩后大促流量是否能够应对
这些问题如果有一项未验证或验证未通过都不能执行压缩方案因为方案执行后可能会对数据安全与系统稳定造成影响。
如何验证呢
最严重的问题压缩是否会导致数据丢失想通过一些方法验证这个问题非常困难的只能通过mysql的压缩过程原理去分析。 从官方文档中提炼出了Online DDL的4个步骤从图中可看出在任何阶段原表数据都不会丢失直到完成切换后原表才会被定期清理因此压缩过程中数据是安全的。
第二个需要验证的是压缩时、压缩后与大促高峰期整个系统的读写耗时与吞吐量。
第一步搭建等比验证环境
以文中账单系统实践为例将生产的一个分库完全复制到一个新的物理机上这样就以20:1的比例搭建了验证库。 第二步模拟流量
这一步需要结合目标系统的实际情况完全模拟系统高峰期的流量文中的账单系统是通过改造代码来达到流量预期的如果所在部门原本就具备压测条件可直接调整压测robot的流量开启压测程序来达到流量预期。 流量达标后通过观察压缩时或压缩后系统的吞吐量、写入的耗时以及慢sql等情况来判断压缩对系统及数据库的影响。如果此步发现了明显的慢sql或吞吐量异常就需要考量这些情况是否会影响系统的SLA指标同时还要考量系统及业务能否容忍压缩所带来的负面影响。
压缩回滚问题
账单系统在做模拟流量压测时意外的发生了异常导致了压缩过程回滚。这也变相验证了压缩过程是可回滚的。异常比较常见duplicate key这个异常是唯一索引重复导致。这个问题需要重视因为账单系统会接收各种业务方的mq消息难免会有这种重复下发过来的mq如果经常出现这种异常最坏的情况是某些相关表永远无法压缩成功。如下图 解决这个问题的方法很多这里不赘述但异常情况是做压缩过程中必须避免的。
方案落地
灰度
在方案的落地过程中需要有灰度过程来观察方案在生产环境中的执行是否会产生意料之外的问题。灰度的方法应视具体情况而定但任何的灰度方案都应该至少考虑故障、业务与性能3个方面。
故障影响范围控制以小见大第一阶段的灰度一定是以最细颗粒度方案进行落地的以便观察系统是否稳定、业务是否正常这样即使出现意料之外的问题影响的用户也是非常少的不至于引起舆情。以表压缩为例刚开始只压缩一张表观察情况随时准备回滚。
业务全场景安全遵循灰度周期递减的方式第一阶段灰度开始时经历的时间要足够长确保新的内容已经经历过所有生产场景all story的考验这样能够保障新的内容在业务上是正确的之后可以逐步的缩短验证周期加快灰度进程。
性能高流量验证高峰期考验每个灰度阶段都至少经历一个流量高峰期来验证新内容的性能是否能够承受高峰流量。为什么每个灰度阶段都要经历高峰期流量第一阶段灰度的时候已经经历过一次高峰期流量验证了吗这样做验证逻辑是有漏洞的系统作为一个整体当其中大部分内容替换成新内容后整个系统饱和度会随之产生变化如表压缩场景是用时间换空间因此可能影响系统的吞吐量起初压缩一张表时高峰期系统吞吐量可能并没有什么影响之后压缩100张表后高峰期系统开始有些流量积压到最后10000张表压缩后高峰期系统可能产生大量积压。像吞吐量这种宏观指标在每个灰度阶段都必须关注。因此每个灰度阶段都必须经历至少一个流量高峰期才能证明系统的性能是没问题的。
回滚
在方案的灰度过程中必须有相应的回滚手段以便灰度产生问题后能够及时的回滚止损。回滚方案中需要注意的有两点1是及时2是有效如压缩方案中的回滚方案是解压缩命令通过alter及时提工单即可执行。
总结
本文主要以介绍方法为主落地过程可以归纳为方案-收益测算-数据安全验证-系统稳定性验证-灰度与回滚。文中的账单系统通过step1大表压缩32%step2大JSON字段序列化12%step3删除无效数据10%3个方案的顺利落地有效的减少了50.7%的磁盘空间成本下降也非常显著。最后希望此文能够给还在迷茫不知从何处下手落地数据库存储成本降低的同学一些启发和灵感以上。 作者京东科技 李阳 来源京东云开发者社区 转载请注明来源
