第5章 数据拆分实现数据库能力线性扩展

第5章 数据拆分实现数据库能力线性扩展

本章介绍淘宝如何基于数据库分库分表方式, 利用分布式数据库平台解决数据瓶颈问题. 包括在进行数据库改造过程中如何进行数据分库分表设计的最佳实践

5.1 数据库瓶颈阻碍业务的持续发展

 共享服务体系改造过程中, 各服务中心拥有独立数据库方式, 采用数据垂直分区
 方式对业务数据进行分区
1. 解决了连接资源问题
2. 解决了表多, 资源多造成性能问题

首先采用读写分离

1. 主数据库处理事务性增, 删, 改操作
2. 从数据库处理查询操作
3. 数据库后台处理主从同步

2c87cf685a7b4d0882385d68b3e08236_image.png

 问题: 写入能力没法扩展

采用数据库分区思想

3ee8ab7d67de4fc6bb12e35012493f30_image.png

问题:  业务场景中跨表join, 事务操作, 数据统计, 排序等

数据库的运维管控提出更高要求

5.2 数据库分库分表实践

5.2.1 阿里巴巴分布式数据平台发展演变

TDDL（Taobao Distributed Data Layer，外号：头都大了）

c6749d08e32f4ea3bd1f2b2bb0266ea1_image.png

Matrix层（TDataSource）实现分库分表逻辑，底下持有多个GroupDs实例

Group层（TGroupDataSource）实现数据库的主备/读写分离逻辑，底下持有多个AtomDs实例

Atom层（TAtomDataSource）实现数据库连接（ip、port、password、connec-tionProperties）等信息的动态推送，持有原子的数据源

47b864bee42141549ae452fd6d09a83d_image.png

5.2.2 数据尽可能平均拆分

8da8747526f7455b8c14d7ee6b9c932a_image.png

1. 按照订单id取模拆分

2. 通过卖家用户id hash取模拆分
   有些卖家交易量很大, 数据不均衡

5.2.3 尽量减少事务边界

277a6b2708a74faa96874835109cdc8c_image.png

不带分表键查询

bdaa3b9f134044ec8c1436f1cd70871b_image.png

事务边界: 单个sql在后端数据库上同时执行行的数量

事务边界大(全表扫描)会带来一下弊端
1. 系统锁冲突概率越来越高
2. 系统约难以扩展(负载能力)
3. 整体性能越低

5.2.4 异构索引降低全表扫描频率

9019f9c672da4a3b861728a280acc309_image.png

按照订单id取模, 卖家查看自己的订单

21c913d4137f4ed18d59e6cf144c8aff_image.png

为什么不把订单完整数据按照卖家id进行一次分库分表?

这就是异构索引表全复制

避免多一次的数据库访问

实现异步索引创建方式

1. 数据库层采用数据复制的方式

   
   671bbad5c01d40a3a9c676652481daa1_image.png

ff0aab94979740b8b7ad8b07be55e963_image.png

2. 应用层实现

5.2.5 将多条件频繁查询引入搜索引擎

调用频繁的全部扫描操作, 只能走搜索引擎品台

94d8032c851a4c4b98b5e1e118484078_image.png

5.2.6 简单就是美

尽量减少事务边界 和 数据尽可能平均拆分 之间优先数据尽可能平均

实际中, 我们仅针对在80%情况下访问的那20%的场景进行数据的异构索引处理

对其他80%偶尔出现的跨库join, 全表扫描场景, 采用最简单直接的方式往往就是最有效方式