数据库系统设计漫谈

讲师：童家旺 , 阿里集团数据库架构师

主题 数据库基本问题调查 关系数据库的基本背景 ACID 基本概念解析 范式问题解析（ Normalization ） 数据库的扩展性浅析 常见数据库系统回顾

数据库基本问题调查

大家都使用过哪些数据库？

哪些内容是数据库系统的关键点？

常见的数据存储 传统的数据库系统

Oracle DB2 、 SQL Server MySQL 、 PosgreSQL

分布式数据库 Google Spanner & BigTable & MegaStore OceanBase 、 Hbase

缓存服务器 ＆ KeyValue Store Tair MemcacheD Redis

数据库的主要特性

ACID 原子性（ Atomicity ） 完整性（ Consistency ） 隔离性 （ Isolation ） 持久性 （ Durability ）

Relation ＆ SQL Structured Query Language （即 SQL ） A Relational Model of Data for Large Shared

Data Banks （ By Edgar Codd ）

RDBMS 之前的数据库的问题 不支持数据独立性 数据库与应用系统之间的强耦合 应用系统的复杂度 应用系统本身的规模较小（性价比？）

关系数据库的主要业务场景

Billing （记账类业务，电信、银行） Booking （订票类业务，航空） Inventory （库存管理，零售）

这些业务的共同特征是什么啊？

关系数据库的关系来自哪里？ 这是关系的一个来源 另一个来源是 Normalization

ACID 的基础概念 Transaction 的概念借自 Contract Law

一手交钱、一手交货（ Atomicity ） 不会出现库存为负，也不会出现资金为负的情况（ Consistency ） 可同时与多人进行交易（ Isolation ） 离柜概不负责（ Durability ）

Atomicity 要么全部成功，要么全不成功

Consistency 写入数据库的数据必须满足所有定义的约束规则（主键、唯一键、外键等约

束） Isolation

确保并发执行的事务就如同串行执行的事务一样，保证系统状态（ state ）的一致性。

Durability 一旦提交，哪怕出现掉电、 Crash 也不会丢数据

几个基础概念 Write-Ahead Log Redo

Logical Physical Physiological

Undo 事务槽－事务标识 SCN – 系统变更统一时间戳（逻辑时钟）

如何实现原子性 一个简单购物场景

A 卖一件衣服给 B A 的衣服库存 -1 A 的资金 +N B 的衣服库存 +1 B 的资金 -N

如何实现原子性（ 2 ） 事务槽为变更入口，单一入口（原子） 每个变更的记录都包含事务槽信息

数据库中如何保证 C

通过 Read Dirty 与锁来解决 PK/UK 通过 Ref 检查来解决 FK 的问题（需要

Index ） 通过 PreCommit trigger 来做 Null 以及

Check

数据库中如何保证 I

锁控制 不同粒度的锁（表级、块级、记录级） 不同维度的锁（数据相关锁，内存相关锁）

MVCC Snapshot Isolation Block Image + SCN + Undo Image 判断

差别在于读取哪个时间点的 Snapshot

数据库中如何保证 D

Log before Data LGWR before DBWn Flush Log on Commit

Durability On Commit Checkpoint Before Redo Log File

Reuse

ACID 的代价 不同的 Isolation 对应不同的代价

Serialiazability Read Committed (Through Snapshot) Read Dirty ? （没有并发控制）

不同的 Durability 级别 Flush on Commit Flush on Timeout ( Time Range) Flush on Batch ( commits count?)

主题 数据库基本问题调查 关系数据库的基本背景 ACID 基本概念解析 范式问题解析（Normalization） 数据库的扩展性浅析 常见数据库系统回顾

Normalization

先做个小游戏

用笔记录下 学员名单、讲师名称、讲师简介、课程名称、课程

简介 调整下

讲师（童家旺金光丁）以及对应的讲师简介 再次调整下

课程 （数据库概论分布式数据库原理）＆简介

Normalization 解决的问题 更新一个源头不会出现异常 每份数据只有一个源头

如何保证多份数据的一致性？ 一份数据有多少个源头？

同一份数据被重复了多少次？ 对应的存储空间？ 为了存储耗费的其它资源？

Normalization带来的问题 表之间的依赖（关系依赖，耦合） 表关联的成本（关联开销，可能的 IO开销） 系统扩展的复杂度（解耦合）

如何权衡 Normalization

尽量不要对静态数据做 Normalization 除非你希望节约存储空间

考虑范式化 Vs 反范式化的投入产出 为什么很多 IT新人喜欢 Normalization

那是因为他们的老师告诉他们需要 Ali 的实际情况

适度的使用 关键在于判断业务之间的耦合性

主题 数据库基本问题调查 关系数据库的基本背景 ACID 基本概念解析 范式问题解析（ Normalization ） 数据库的扩展性浅析 常见数据库系统回顾

一个小实验 如何将 2 个人从这里送到杨浦？ 如何将 5 个人从这里送到杨浦？ 如何将 50 个人从这里送到杨浦？ 如何将 500 个人从这里送到杨浦？ 如何将 5000 个人从这里送到杨浦？ 如何将 50000 个人从这里送到杨浦？

解决扩展性的根本途径

数据库的扩展性问题 做数据库架构、系统架构与上图差别在于：

如何满足如下的要求 检索问题

Relation 并发问题

Isolation Consistency(UK)

一致性问题 Isolation

速度问题 Performance,Durability+Isolation

数据库检索问题 如何从班级的联系方式中找到 XX 的电话号码？ 如何从公司的联系方式中找到 XX 的电话号码？ 如何从移动公司的系统中找到 XX 的电话号码？ 如何从移动、电信、联通的数据库找到 XX 的

电话号码？

数据库的并发问题 同时有多个人要购买手机号？ 如何保证大家购买的不是同一个手机号？ 如何支持几百、几千、几万人同时购买手机号？

数据库的一致性问题 如何保证大家看到的库存有效？ 如何保证读取的信息是准确的？ 库存的变更如何实时的提供给

每一个人看到？

数据库的性能问题？ 如何快速的让 1 个人买到号码？ 有多快？

如何快速的让 10 个人买到号码？ 要不要排队？ 一个服务员？ 一个营业厅？

Performance Vs Scalability

1.当只有一个人访问时，速度如何？ 2.当有很多人访问时，速度如何？

大家都同样快？ 如果满足 1

表示 Performance很好？ 如何能较好的满足 2

表示系统有较好的 Scalability

一致性问题再探讨新浪发的微薄需要强一致吗？ ITPUB 的论坛需要强一致吗？ 当当的图书描述信息需要强一致吗？ 12306 的火车票库存信息需要强一致吗？ 支付宝 /财付通的账户余额需要强一致吗？ 中行信用卡 /招商银行卡的账户信息需要强一

致吗 ?

数据状态机的分类

何谓状态机 简单的理解是，计算机中会发生变化的数据都是状态机，

这个数据的值不同可能会带来不同的后果。 分类：按照三个维度：时间、信息含金量、变更频率

持续时间 信息含金量 变更频繁度 例子瞬时 高 少 Shopping Card Session

（分）瞬时 低 少 Login Cookie （分）中等时长 高 少 Ecommerce Billing(天 )中等时长 中 少 Product Catalog(年 )中等时长 高 多 Flight/Train Inventory

(月 )无限时长 中 少 User Profile （年 )无限时长 高 多 Bank Account Balance

（年 ) ）

Cache 的基本概念 Cache 的定义

Caching is a temp location where I store data in (data that I need it frequently) as the original data is expensive to be fetched, so I can retrieve it faster. 台湾的翻译为“快取”，大陆为“缓存”

Cache 的特征 有 Backend 的内容 处理的效率比走Backend 要快 与 Backend 的内容之间可能会不一致

Cache 的本质 Through Relaxing Consistency to Improve Scalability

Cache 的设计考虑

缓存的一致性维护问题 数据的具体读写比

商品信息？库存信息？用户信息？账户余额？ Backend 数据变更频率 业务对一致性的要求 使用何种缓存策略

Write Through Vs Write Back Vs Write Back with Compensate

Memcached 是 Cache吗？ It Depends

如果内容有 Backend ？是！ 如果内容没有 Backend ？否！

案例 新浪微博的计数器？ 淘宝、当当的记录在缓存中的购物车信息？

主题 数据库基本问题调查 关系数据库的基本背景 ACID 基本概念解析 范式问题解析（ Normalization ） 数据库的扩展性浅析 常见数据库系统回顾

数据存储的基本需求 存储数据 读写的性能（ Hash 查找、 B*Tree 查找） 数据的可靠性（ Durability ）支持

如何避免单点故障带来的数据丢失（数据保护） 是否支持多维查询（基于关系的查询） 对 Replication 的支持如何？ 支撑 Scalability 的复杂度

MySQL (Innodb) & Oracle

传统的关系数据库 支持多维索引

Oracle 的支持较好 MySQL 要到 5.6才比较好的支持 Index 内 Filter

较好的支持数据的一致性 成熟的 MVCC 设计 成熟的 Replication 设计

简单查询的效率略低于 Memcached B*Tree 的成本 MVCC带来的额外成本

MySQL & Oracle

在进行数据库扩展时 只能依赖于应用层的拆分（即： Sharding ） 目前 Sharding 支持由 TDDL 实现 维护成本会相对较高 维护复杂度也比较高

软件的成本 Oracle 为商业软件，有 License费用 MySQL 为开源软件，没有软件本身的费用

Tair 简介

Tair 主要技术点 主要定位为

分布式 Key/Value 缓存 Data Server 的具体实现

Memory Engine 的实现类似于 MemCached Config Server 的实现

基于 Consistent Hash 实现集群的数据分布 基于此做 Replication 做节点的故障检测与剔除 新加入节点时需要基于 CHash 做节点 Rebalance

Hashmap

Slab List

Tair mdb 内存结构

Consistent Hash 简介

OceanBase 系统架构44

主控服务器 RootServer ：主 +备，数据定位 / 全局 Schema/机器管理… 动态数据服务器 UpdateServer ：主 +备，实时修改 ( 内存 +SSD) 静态数据服务器 ChunkServer ：多台，静态数据存储 (磁盘或 SSD) 动态数据不断地被合并到静态 ChunkServer 中实现分布式存储

JavaClient

ChunkServer

ChunkServer

ChunkServer

ChunkServer

RootServer/ UpdateServer

( 主 )

RootServer/ UpdateServer

(备 )

OceanBase 简介 UpdateServer 负责所有的写入

本质上是一个读写分离的技术 对实时更新数据的查询可以在 US 的备库进行

ChunkServer 理论上可以无限扩展 查询操作需要合并 US+CS 的结果 Root Server 的职责类似于 Tair 的 Config Server 相对于 Tair 的优势

可以进行 Full Table扫描 可以进行范围数据查询 更好的 ACID 支持（目前支持 MVCC ） 不支持外键 + 唯一键（ FK+UK ）

集团现有数据库特性粗略比较Oracle MySQL Tair OceanBase HBase

读性能 高 高 高 中 中

写性能 高 中 高 高 高

一致性 高 高 低 高 - （除 FK/

UK ）中

数据保护 高（双份存储）

中 +( 单机故障 )

低 高－ (网络提交 ) 高－

多维查询 高 中（索引稍弱）

无 无 无

备库 高(Physical)

高 -(Logical)

低 (Logical) 高 -(Logical) 中 +(Logical)

读扩展能力 中 高 高 高 高

写扩展能力 低 低 高 中 高

扩展复杂度 高 中 低 低 低

软件成本 高 无 研发费用 研发费用 无