首页 > 其他分享 >亿级大表垂直拆分:上云业务的工程实践

亿级大表垂直拆分:上云业务的工程实践

时间:2024-08-12 12:50:17浏览次数:14  
标签:DB 业务 上云 拆分 亿级 迁移 数据 大表

亿级大表垂直拆分:上云业务的工程实践

原创 修改于 2023-10-14 10:59:09 6810 举报 文章被收录于专栏:后台技术汇

1、前言

伴随着不断扩张的业务量,在数据库层面一般会经历数据拆分。解决问题的第一步,就是重新评估 DB 表结构设计的合理性。

2、大表问题

我实际遇到的是怎么样的情况呢?下面我简单介绍下(做了脱敏处理):

过去对表结构设计时,研发由于忽略了业务原子性,使用了一个大字段(TEXT/LONGTEXT/JSON 等)存储了耦合业务的大数据字段,如今表行数已经接近 1 亿了,总使用空间超过 100G;虽然碎片率不高,但仍有 1.97GB 的碎片空间。

DB 大表的存在导致了诸多问题:

1、读查询:每次带大字段的 SQL 被执行了,都会引起从 DB-Server 到 应用服务 之间的一次大数据量传输;如果 SQL 执行并发量大,吃机器内存的情况,将发生在 Mysql-Server 和应用容器中,甚至 OOM;

2、业务拓展:业务是不断往前迭代的,意味着针对这个表,将不断有 DDL 和 DML 的 SQL 被执行;这也注定了,如果不对大表进行瘦身,第 1 点提到的问题,将是一颗定时炸弹,埋在不断被堆积的业务里;

3、DB 运维:在追求平滑升级的背景下,我们对表结构变更时,一般选择是在业务低峰期,对临时表进行拷贝,然后执行 DDL 变更(增删字段和索引),最后通过 rename 完成业务切换;大表的临时表将具有跟原表同样大小体积,这对运维来说,每次备份大表都是一个巨大的资源和时间开销。

4、业务隐患:为了完成 DB 高可用部署,我们的业务上云之后,采取了一主多从的部署架构。因此 DDL 变更期间,由于强同步配置,难免造成从库的数据延迟问题。

3、大表的垂直拆分

数据库拆分原则:就是指通过某种特定的条件,按照某个维度,将我们存放在同一个数据库中的数据分散存放到多个数据库(主机)上面以达到分散单库(主机)负载的效果。

数据库拆分,分为水平和垂直拆分两种;

  • 水平拆分的典型场景就是大家熟知的分库分表;
  • 垂直拆分则倾向于表重构,按照业务维度进行数据切割。

上文讲了大表背景下导致的种种问题,基于上述原因,我们团队决定趁着重构的机会,进行一次大表垂直拆分:大字段迁移。

经过和 DBA 的一起分析,发现该表存在一个 LONGTEXT 的字段,它占用了几乎整个表体积空间的 60%以上。

在处理这个大表的问题上,我们有考虑过水平拆分的手段。

按照某种策略(基于项目 id,基于用户 id,基于冷热项目等),但始终不能较好的将数据均匀平摊到每个分表,甚至会因为热点项目再次带来大表问题,因此并不采纳这个方案。

我们最终选择垂直拆分的方案。

原因是这个大字段,本身就是一个结构化的对象数据,结构化对象最终可以抽象成一张表。通过将这个大字段拆分到一个新表,随后完成旧表的数据迁移和清理。

4、解决方案

制定了 DB 变更方案之后,我们要按照真实环境部署来完善方案细节。

1、新表创建:这类 SQL 操作,我们都会提单给 DBA 评估执行。

2、数据迁移(存量数据):这里我们用定时任务来完成。

如果简单使用 UPDATE 务,会带来表锁的开销,这会直接影响线上业务;我们是不停服变更,因此绝对不能影响正常业务。

定时任务逻辑很简单:查出一条老数据,插入一条新数据。这里建议直接设定一个区间,按照主键 ID 来遍历;否则通过任何索引+分页的手段,最后都会面临深度分页带来的性能问题,属于是本末倒置了。

3、开启双写(增量数据):正常业务是会源源不断产生增量数据的,此时要确保数据在新旧表都有一份,这样才能完全兼容业务。

4、兼容 API数据迁移是需要切换时间的,这个缓冲期需要保持对 API 的兼容,包括对新表 or 旧表的读操作,其他依赖业务的读操作等。

5、关闭双写:数据迁移完成后,老表的字段不需要再写入数据,因此可以修改 Insert 的 SQL,停止该字段写入。

6、清理旧表:确认线上业务不依赖旧表之后,DBA 可以进行磁盘碎片回收。

5、总结与思考

DB 变更操作是一个高风险动作,我们前期评估一定要充分考虑到以下场景,否则容易引发生产事故:

  1. 存量数据迁移
    1. 系统的老逻辑也要保持兼容
  2. 增量数据双写
    1. 注意灰度情况的监控,及时修复双写的业务漏洞
  3. 迁移过程可能引发的性能危机
    1. 甚至有可能依赖业务接口,这样可能导致接口并发量上去
    2. 适当设置线程休眠,可以缓解带来的性能问题
  4. 迁移数据里程碑
    1. 因为迁移过程是一端长期而缓慢,要记录好时间节点,避免漏同步或者重复同步的问题

标签:DB,业务,上云,拆分,亿级,迁移,数据,大表
From: https://www.cnblogs.com/sexintercourse/p/18354739

相关文章

  • 上云避坑指南
    我在之前的文章《云计算-虚拟化-OpenStack》里聊过,云计算的本质是一种IT资源通过虚拟化进行的共享,是一种更高维度的服务。云计算的本质就俩词:共享、服务。1、建议企业上云作为一个IT行业14余年的老杆子,亲自主导过几个公司的中大型系统从IDC机房迁移上云。上云这个事情,是必然趋势......
  • 《亿级流量系统架构设计与实战》第一章 大型互联网公司的基础架构
    大型互联网公司的基础架构一、DNS1、域名服务器分类2、域名解析过程二、HTTPDNS1、DNS存在问题2、HTTPDNS解析流程3、HTTPDNS与DNS对比三、接入层技术演进1、Nginx(七层负载均衡器)2、LVS(四层负载均衡器)3、LVS+Nginx接入层架构四、数据存储1、MySQL2、Redis3、LSMTr......
  • 一个基于 vue 的强大表单和高性能表格组件,简洁API设计,支持虚拟树,列拖拽,懒加载,快捷
    前言在现代Web应用开发中,表单和表格是两个核心组件,它们对于数据展示和用户交互至关重要。然而,现有的解-决方案往往存在一些痛点,如不够灵活、性能问题、以及难以实现复杂功能等。这些问题限制了开发者的创造力,也影响了用户体验。为了解决这些痛点,开发者需要一款功能强大、灵活......
  • 秒懂斐波那契:算法优化实现21亿级速度突破
    针对斐波那契数列算法进行详细介绍和优化,从最简单的递归方法到更高效的迭代、缓存、动态规划、公式推导和矩阵解法,最终达到了时间复杂度为O(logn)的快速幂矩阵解法来感受算法的神奇之处,最后可以看到如何实现在输入n=2100000000(21亿)时仅耗时0.02毫秒的最佳效果。一、回顾斐波......
  • ElasticSearch第4篇(亿级中文数据量 ElasticSearch与Sphinx建索引速度、查询速度、并发
    经过实测:1.09亿的数据量进行中文检索。ElasticSearch单机的检索性能在0.005~5.6秒之间,此检索速度可满足95%的业务场景(注意:每条ES文档平均65个汉字,数据源取自几千本小说,大部分文档在15~300个汉字之间,不然字数太多索引太大电脑存不下)。前置文章由于本文章的前置操作强依赖于另一篇......
  • 高速上用到的视频上云网关现在市场上真的太卷了
      先看一个需求: 这个是最近的一个招标项目上对视频网关的需求,我看了以后,真的有点不知道该怎么说。两个问题:第一个问题,目前都在执行新标准了,部标目前是128K推送到标准了,这个招标文件中还是32K,看来设计公司这个项目时,还是去年上半年的时候,但这个标发出来前,难道不应该......
  • oracle大表性能优化
    1不修改表结构的优化1.1收缩表,降低高水位线ALTERTABLETESTENABLEROWMOVEMENT;ALTERTABLETESTSHRINKSPACE;1.2对表收集统计信息BEGINDBMS_STATS.GATHER_TABLE_STATS(ownname=>user,tabname=>'TEST');END;1.3使用oracle的并行查询功......
  • 大表关联 not exists 卡死问题
    检查是否有适当的索引:确保用于NOTEXISTS子查询的列上有索引,这样数据库可以快速确定是否存在符合条件的记录。 优化查询:减少返回的数据量:使用WHERE子句来限制需要检查的数据范围。分批处理:如果可能,将大的NOTEXISTS查询分解为多个小的查询,并且在可接受的时......
  • 记一次大库大表的治理过程
    一、背景部门中一核心应用,因为各种原因其依赖的MySQL数据库一直处于高水位运行,无论是硬件资源,还是磁盘使用率或者QPS等都处于较高水位,急需在大促前完成对应的治理,降低各项指标,以保障在大促期间平稳运行,以期更好的支撑前端业务。二、基本情况2.1、数据库目前该数据库是一主两从......
  • 阿里云 ROS 助力开发者高效上云 一键部署高端简约的个人主页
    目录介绍资源架构体验ROS一键部署演示图片ROS有什么优势?结语介绍在当今数字化飞速发展的时代,云计算的浪潮汹涌澎湃,企业和个人开发者纷纷将项目迁移至云平台,以追求更可靠和高效的服务。就在最近,我有幸参加了阿里云的“开源上云,寻找云上创造者”活动,深切感受到了这一变......