2013华东数据库技术大会 数据库系统设计漫谈 2013年5月18日 演讲嘉宾：童家旺@阿里集团数据库架构师

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

数据库基本问题调查 大家都使用过哪些数据库？ 哪些内容是数据库系统的关键点？

常见的数据存储 传统的数据库系统 分布式数据库 缓存服务器 ＆ KeyValue Store Oracle DB2、SQL Server MySQL、PosgreSQL 分布式数据库 Google Spanner & BigTable & MegaStore OceanBase、Hbase 缓存服务器 ＆ KeyValue Store Tair MemcacheD Redis

数据库的主要特性 ACID Relation ＆ SQL 原子性（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 一手交钱、一手交货（Atomicity） 不会出现库存为负，也不会出现资金为负的情况 （Consistency） 可同时与多人进行交易（Isolation） 离柜概不负责（Durability） Atomicity 要么全部成功，要么全不成功

ACID的基础概念 Consistency Isolation Durability 写入数据库的数据必须满足所有定义的约束规则（主键、 唯一键、外键等约束） Isolation 确保并发执行的事务就如同串行执行的事务一样，保证系 统状态（state）的一致性。 Durability 一旦提交，哪怕出现掉电、Crash也不会丢数据

几个基础概念 Write-Ahead Log Redo Undo 事务槽－事务标识 SCN – 系统变更统一时间戳（逻辑时钟） Logical Physical Physiological Undo 事务槽－事务标识 SCN – 系统变更统一时间戳（逻辑时钟）

如何实现原子性 一个简单购物场景 A卖一件衣服给B A的衣服库存-1 A的资金+N B的衣服库存+1 B的资金-N

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

数据库中如何保证C 通过Read Dirty与锁来解决PK/UK 通过Ref检查来解决FK的问题（需要Index） 通过PreCommit trigger来做Null以及Check

数据库中如何保证I 锁控制 MVCC 差别在于读取哪个时间点的Snapshot 不同粒度的锁（表级、块级、记录级） 不同维度的锁（数据相关锁，内存相关锁） 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对应不同的代价 不同的Durability级别 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 反范式化的投入产出 除非你希望节约存储空间 考虑范式化 Vs 反范式化的投入产出 为什么很多IT新人喜欢Normalization 那是因为他们的老师告诉他们需要 Ali的实际情况 适度的使用 关键在于判断业务之间的耦合性

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

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

解决扩展性的根本途径

数据库的扩展性问题 做数据库架构、系统架构与上图差别在于： 检索问题 并发问题 一致性问题 速度问题 如何满足如下的要求 Relation Isolation Consistency(UK) 一致性问题 速度问题 Performance，Durability+Isolation

数据库检索问题 如何从班级的联系方式中找到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的定义 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数据变更频率 业务对一致性的要求 使用何种缓存策略 商品信息？库存信息？用户信息？账户余额？ 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简介 http://code.taobao.org/p/tair/wiki/intro/

Tair主要技术点 主要定位为 Data Server的具体实现 Config Server的实现 分布式Key/Value 缓存 Memory Engine的实现类似于MemCached Config Server的实现 基于Consistent Hash实现集群的数据分布 基于此做Replication 做节点的故障检测与剔除 新加入节点时需要基于CHash做节点Rebalance

Tair mdb内存结构 Hashmap Slab List http://ishare.iask.sina.com.cn/f/20773253.html  宗岱-Tair-分布式KV系统.pptx

Consistent Hash简介 http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html

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

OceanBase简介 UpdateServer负责所有的写入 ChunkServer理论上可以无限扩展 查询操作需要合并US+CS的结果 本质上是一个读写分离的技术 对实时更新数据的查询可以在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) 读扩展能力 写扩展能力 扩展复杂度 软件成本 读/写性能，可以认为是简单的基于主键的查询效率，也即Key/Value查询的效率。其它复杂场景的比较过于复杂。 一致性，与前面的数据库状态机分类一致，可以认为a. 对uk/fk的支持，b.数据的一致性要求，c. 是否能支持MVCC以及Serializable Isolation 数据保护，是否有较好的方案确保系统不出现数据丢失，哪怕是在出现单机极端故障的情况下。Oracle通过同时写双份Redo 日志来保障，OceanBase与Hbase通过同时通过网络写多份来提高数据保护能力，MySQL可以通过Semi-sync方式来提高数据保护能力. 多维查询，即此数据存储是否能较好的支持Secondary Index，能否支持有一定复杂度的表关联查询。 备库，大部分数据存储都通过备库来提高数据保护、保障能力，但各自备库的实现方式有较大差异，对于备库需要考虑2点：机制设计上是否能够保证有效的备库，是否有有效的方式来验证备库与主库的一致性。 读/写扩展能力，在业务的读写规模出现增长时，是否能够支持。支持的复杂度如何，是通过简单的增加主机？增加节点的复杂度如何？增加节点的风险如何？减少节点呢？ 软件成本，这里只有Oracle有软件成本，不同的配置、选项有不同的成本。

友情提示 2013年11月16日于上海举办华东架构师大会 已确定的架构师大会主题及演讲嘉宾 去哪儿 唐娟 海量数据的搜集和实时分析架构设计与实践 江游科技 时继江 网络游戏一键开服的架构设计与实践 金山网络 毛剑 异构数据库的实时数据同步架构设计 会议网址：http://atcc.mysqlops.com/ 新浪微博：@mysqlops

联系方式 联 系 人（一）：会议组织者 姓 名：金 官 丁 联系电话：136 6166 8096 联 系 人（一）：会议组织者 姓 名：金 官 丁 联系电话：136 6166 8096 邮箱地址：mysqlops@sina.com 即时通信：172010148（QQ），@mysqlops（新浪微博） 联 系 人（二）：会议秘书 姓 名：朱 颖 丹 联系电话：136 5197 9898 邮箱地址：vera_zhuyd@163.com 即时通信： 378091820 （QQ）， @戆小囡猪猪（新浪微博）

2013华东数据库技术大会

2013华东数据库技术大会

2013华东数据库技术大会

2013华东数据库技术大会

感谢您的一路相随，我们一起携手走向未来！ 2013华东数据库技术大会 感谢您的一路相随，我们一起携手走向未来！