小米集团：2020年智能手机营收1522亿元，同比增长24.6%
06-17
背景我们以电商为例，分享业务视角。业务初期，数据库基本都是单库单表实现的，这样可以快速支撑业务。
可以通过反复试验将资源成本控制在最低限度。但随着业务的不断发展，数据量将会呈指数级增长。
最终会发现单库单表无法支撑业务的快速发展，需要对现有的数据库架构进行改造。升级。
从技术角度来说，根据以往的经验，单表最多可以支持W左右的数据。如果数据量持续增长，会影响读写效率，需要将单库单表改造为分库表。
单库单表的问题： 性能瓶颈：随着数据量的增加，数据库的读、写、查询性能会逐渐下降。尤其是当表中的数据行数达到百万甚至更多时，即使是简单的查询操作也可能变得非常慢。
数据热点：所有数据操作都集中在数据库中的一张表上，很容易形成数据热点，导致某些数据行被频繁访问，成为性能瓶颈。高可用和容灾问题：单库单表架构很难实现高可用和容灾。
一旦数据库出现故障，整个应用都会受到影响。而且数据恢复时间较长，影响业务的正常运行。
扩展性问题：随着业务的发展，数据量和访问量不断增加，单库单表的架构很难通过简单的扩展来满足需求。水平扩展（添加更多服务器）和垂直扩展（升级现有服务器硬件）都有局限性。
事务管理和锁竞争：在高并发的情况下，大量的事务和数据库操作会引起锁竞争问题，影响数据库的处理能力。备份和维护难度：随着数据量的增加，备份和维护数据库的难度和时间成本也会大幅增加。
架构升级流程参考：数据库架构演进流程。这里我们直接一步完成流程，从单库单表到数据库的垂直拆解、水平分表、迁移过程场景总结、新旧数据、读写旧数据、旧数据，是的，是的，迁移步骤实现新数据的读写能力，实现旧数据到新数据的同步（通过监控binlog），实现新数据和旧数据的同步（通过监控binlog）。
开始新数据的灰度读取。读取全量新数据后，关闭旧数据。
开始读取数据。新数据的灰度写入。
新数据写满后，旧数据的写入线关闭。稳定运行一段时间后，新旧数据关闭，旧数据同时归档。
旧数据已离线。迁移前、迁移中、迁移后。
概括。至此完成了数据库架构的升级。
在整个迁移过程中，我们秉承对业务影响最小的战略理念，最终实现数据和功能向新数据库架构的平滑迁移。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-06
06-17
06-18
06-18
06-18
06-17
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用