MySQL扩展

扩展立方体

• x轴：集群（整个系统/库进行复制）
  • 数据复制：主从、备份、高可用、读写分离
• y轴：业务拆分（解耦不同业务功能，方便各自的复制）
  • 业务分类数据：垂直分库分表、分布式服务化、微服务
• z轴：数据分片（拆分数据进行扩展）
  • 任意数据进行拆分：水平分库分表、分布式结构、任意扩容

垂直分库分表演进

• --> 分布式服务化 --> 微服务架构
• 需求来源
  • 服务不能复用（依赖jar包的方式，升级维护代价过大）
  • MySQL服务端连接数不够用（BIO）
• 拆分示例
  • 用户、商品、订单
• 方式-垂直拆库
  • 对业务系统有极大影响
    • 关联查询失效，改动sql与程序
    • 梳理出所有的表，数据量基本达到拆分效果，同时改造风险可控
• 方式-垂直拆表
  • 过多列的主表（也影响到java内存不必要的消耗过大，整个业务生命周期内GC不掉），拆分成多个子表
  • 尽量少用这种方法，对线上正在运作的系统来说，手术太大，这个应该是在系统初始设计阶段就预估到并解决的。
• 垂直拆分的一般做法
  • 1、梳理清楚拆分范围和影响范围
  • 2、评估影响到的服务功能
    • 调整的过程中，可以有一些防腐层（Adapter），与外层功能隔离
  • 3、准备新的数据库集群复制数据
    • 数据迁移注意事项
  • 4、修改系统配置并发布新版上线
  • 思考：先拆服务还是先拆库
• 垂直拆分的优缺点分析
  • 优点
    • 单库（单表）变小，便于管理与维护
    • 提升：性能、容量
    • 系统复杂度、数据复杂度降低
    • 可以作为微服务改造的基础
  • 缺点
    • 库增多，管理变复杂
    • 对业务系统有较强的侵入性
    • 改造过程复杂，容易出故障
    • 拆分到一定程度就无法继续拆分

水平分库分表演进

• 按主键分库分表
  • 订单表，按用户ID（模32）分库，再按订单ID（模32）分表
    • 索引层级表小，整体数量级少了3个数量级，查询效率提升
• 按时间分库分表
  • 具有时间属性的数据，按照时间维度来查询数据 
• 强制按条件指定分库分表
  • 配置规则
  • 场景：新老数据、vip用户数据
• 自定义方式分库分表
  • 业务规则
  • 分布式数据库中间件支持
• 思考：有些DBA不建议分表，只建议分库（一些中间件也只支持分库不支持分表），为什么呢
  • 磁盘IO、网络IO的瓶颈不会改变
• 优缺点
  • 优点
    • 解决容量问题
    • 比垂直拆分对系统影响小
    • 部分提升性能与稳定性
  • 缺点
    • 集群规模大，管理复杂
    • 复杂SQL支持问题（业务侵入性、性能）
    • 数据迁移问题（扩容、缩容）
    • 数据一致性问题（分布式事务）

使用中间件Apache ShardingSphere

• 官网文档：概览 :: ShardingSphere（ShardingSphere-jdbc、ShardingSphere-proxy两种方式）
• 配置：server.ymal
• 配置：config-sharding.yaml
  • schemaName 虚拟出来的逻辑数据库的名字
• 启动ShardingSphere-proxy，如果没有指定端口号，默认3307

一些命令

• show databases;
• create schema
• drop schema
• create table [if not exist]（会按照分库分表的规则，自动帮我们创建）
• use [schema name];
• show tables;
• show create table
• mysql -h 127.0.0.1 -P 3307 -uusername -upassword
• mysql -h 127.0.0.1 -P 3307 -uusername -upassword -A

数据的分类管理

• 分类处理，提升数据管理能力
• 订单数据，一致性要求最高，不能丢数据。
• 日志数据、一些计算的中间数据，不要那么高的一致性，丢了可以不要，或者可以重新计算出来
• 同样是订单数据，也可以采用不同策略。无效订单如果比较多，可以定期清除或者转移。
• 如果没有无效订单，那么如何进一步优化呢
  • 比如最新一周下单未支付的数据，作为热数据。（时间再长的未支付订单，可以取消掉。）
    • 优化：同时放到数据库与内存。
  • 比如最近3个月下单的数据，被在线重复查询和系统统计的可能性最大。
    • 仅放在数据库，作为温数据（大多已经是终态），提供正常的数据库查询操作。
  • 比如超过3个月、3年以内的数据，可以不提供在线查询的方式，由运营平台来查询。（即冷热业务入口控制）
    • 优化：冷数据。从数据库删除，归档到一些便宜的磁盘，用压缩的方式存储（比如MySQL的tokuDB引擎，可以压缩到几十分之一）。邮件、工单等形式查询，数据导出后发给用户。
  • 比如3年以上的数据，可以直接不提供任何方式的查询。（当然，归档还是有的。）
    • 冰数据。仅存档。不能用来查询，但有数据可供还原。
• 优化心得：数据库、应用，一切皆在必要时再优化，比如前者量到达一定的级别，才值得花上这些维护成本。但是时刻准备着，对这些思想、手段，要有概念。