数据库系统设计漫谈
Upcoming SlideShare
Loading in...5
×
 

数据库系统设计漫谈

on

  • 2,550 views

从关系数据库的起因开始介绍,深入解析关系数据库的ACID、Relation、Normalization等概念,解析数据库Scalability的复杂度,CAP的基本权衡与选择,缓存的概念...

从关系数据库的起因开始介绍,深入解析关系数据库的ACID、Relation、Normalization等概念,解析数据库Scalability的复杂度,CAP的基本权衡与选择,缓存的概念与设计、权衡。

Statistics

Views

Total Views
2,550
Views on SlideShare
2,148
Embed Views
402

Actions

Likes
9
Downloads
62
Comments
0

7 Embeds 402

http://www.dbthink.com 360
http://xianguo.com 24
http://feeds.feedburner.com 7
http://digg.com 6
http://cloud.feedly.com 2
http://feedly.com 2
http://it.zhans.org 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    数据库系统设计漫谈 数据库系统设计漫谈 Presentation Transcript

    • 数据库系统设计漫谈讲师:童家旺,阿里集团数据库架构师
    • 主题 数据库基本问题调查 关系数据库的基本背景 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 DataBanks (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 (datathat I need it frequently) as the original data isexpensive 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 withCompensate
    • 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
    • HashmapSlab ListTair mdb内存结构
    • Consistent Hash简介
    • OceanBase系统架构44 主控服务器RootServer:主+备,数据定位/全局Schema/机器管理… 动态数据服务器UpdateServer:主+备,实时修改(内存+SSD) 静态数据服务器ChunkServer:多台,静态数据存储 (磁盘或SSD) 动态数据不断地被合并到静态ChunkServer中实现分布式存储JavaClientChunkServer ChunkServer ChunkServer ChunkServerRootServer/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)读扩展能力 中 高 高 高 高写扩展能力 低 低 高 中 高扩展复杂度 高 中 低 低 低软件成本 高 无 研发费用 研发费用 无