Downloaded 86 times
Uploaded byjames tong
数据库系统设计漫谈
本讲座由阿里集团数据库架构师童家旺主讲，涵盖了数据库系统设计的基本问题、ACID特性、范式解析及扩展性分析，回顾了多种数据库系统。讨论了关系数据库的业务场景和事务处理的核心概念，以及数据库在性能和一致性等方面的挑战。讲座还介绍了传统关系数据库与分布式数据库的特性及其在实际应用中的经济性及维护复杂度。
数据库系统设计漫谈
- 1.
- 2. 主题 数据库基本问题调查 关系数据库的基本背景 ACID基本概念解析 范式问题解析（Normalization） 数据库的扩展性浅析 常见数据库系统回顾
- 3.
- 4. 常见的数据存储 传统的数据库系统 Oracle DB2、SQL Server MySQL、PosgreSQL 分布式数据库 Google Spanner & BigTable & MegaStore OceanBase、Hbase 缓存服务器 ＆ KeyValue Store Tair MemcacheD Redis
- 5. 数据库的主要特性 ACID 原子性（Atomicity） 完整性（Consistency） 隔离性 （Isolation） 持久性 （Durability） Relation ＆ SQL Structured Query Language （即SQL） A Relational Model of Data for Large Shared Data Banks （By Edgar Codd）
- 6. RDBMS之前的数据库的问题 不支持数据独立性 数据库与应用系统之间的强耦合 应用系统的复杂度 应用系统本身的规模较小（性价比？）
- 7. 关系数据库的主要业务场景 Billing （记账类业务，电信、银行） Booking （订票类业务，航空） Inventory （库存管理，零售） 这些业务的共同特征是什么啊？
- 8.
- 9. ACID的基础概念 Transaction的概念借自Contract Law 一手交钱、一手交货（Atomicity） 不会出现库存为负，也不会出现资金为负的情况（Consistency） 可同时与多人进行交易（Isolation） 离柜概不负责（Durability） Atomicity 要么全部成功，要么全不成功 Consistency 写入数据库的数据必须满足所有定义的约束规则（主键、唯一键、外键等 约束） Isolation 确保并发执行的事务就如同串行执行的事务一样，保证系统状态 （state）的一致性。 Durability 一旦提交，哪怕出现掉电、Crash也不会丢数据
- 10. 几个基础概念 Write-Ahead Log Redo Logical Physical Physiological Undo 事务槽－事务标识 SCN – 系统变更统一时间戳（逻辑时钟）
- 11. 如何实现原子性 一个简单购物场景 A卖一件衣服给B A的衣服库存-1 A的资金+N B的衣服库存+1 B的资金-N
- 12.
- 13. 数据库中如何保证C 通过Read Dirty与锁来解决PK/UK 通过Ref检查来解决FK的问题（需要Index） 通过PreCommit trigger来做Null以及Check
- 14. 数据库中如何保证I 锁控制 不同粒度的锁（表级、块级、记录级） 不同维度的锁（数据相关锁，内存相关锁） MVCC Snapshot Isolation Block Image + SCN + Undo Image 判断 差别在于读取哪个时间点的Snapshot
- 15. 数据库中如何保证D Log beforeData LGWR before DBWn Flush Log on Commit Durability On Commit Checkpoint Before Redo Log File Reuse
- 16. ACID的代价 不同的Isolation对应不同的代价 Serialiazability Read Committed (Through Snapshot) Read Dirty ? （没有并发控制） 不同的Durability级别 Flush on Commit Flush on Timeout ( Time Range) Flush on Batch ( commits count?)
- 17. 主题 数据库基本问题调查 关系数据库的基本背景 ACID基本概念解析 范式问题解析（Normalization） 数据库的扩展性浅析 常见数据库系统回顾
- 18. Normalization 先做个小游戏 用笔记录下 学员名单、讲师名称、讲师简介、课程名称、课程 简介 调整下 讲师（童家旺金光丁）以及对应的讲师简介 再次调整下 课程 （数据库概论分布式数据库原理）＆简介
- 19. Normalization解决的问题 更新一个源头不会出现异常 每份数据只有一个源头 如何保证多份数据的一致性？ 一份数据有多少个源头？ 同一份数据被重复了多少次？ 对应的存储空间？ 为了存储耗费的其它资源？
- 20.
- 21. 如何权衡Normalization 尽量不要对静态数据做Normalization 除非你希望节约存储空间 考虑范式化 Vs 反范式化的投入产出 为什么很多IT新人喜欢Normalization 那是因为他们的老师告诉他们需要 Ali的实际情况 适度的使用 关键在于判断业务之间的耦合性
- 22. 主题 数据库基本问题调查 关系数据库的基本背景 ACID基本概念解析 范式问题解析（Normalization） 数据库的扩展性浅析 常见数据库系统回顾
- 23. 一个小实验 如何将2个人从这里送到杨浦？ 如何将5个人从这里送到杨浦？ 如何将50个人从这里送到杨浦？ 如何将500个人从这里送到杨浦？ 如何将5000个人从这里送到杨浦？ 如何将50000个人从这里送到杨浦？
- 24.
- 25. 数据库的扩展性问题 做数据库架构、系统架构与上图差别在于： 如何满足如下的要求 检索问题 Relation 并发问题 Isolation Consistency(UK) 一致性问题 Isolation 速度问题 Performance,Durability+Isolation
- 26. 数据库检索问题 如何从班级的联系方式中找到XX的电话号码？ 如何从公司的联系方式中找到XX的电话号码？ 如何从移动公司的系统中找到XX的电话号码？ 如何从移动、电信、联通的数据库找到XX的电 话号码？
- 27. 数据库的并发问题 同时有多个人要购买手机号？ 如何保证大家购买的不是同一个手机号？ 如何支持几百、几千、几万人同时购买手机号？
- 28. 数据库的一致性问题 如何保证大家看到的库存有效？ 如何保证读取的信息是准确的？ 库存的变更如何实时的提供给 每一个人看到？
- 29. 数据库的性能问题？ 如何快速的让1个人买 到号码？ 有多快？ 如何快速的让10个人 买到号码？ 要不要排队？ 一个服务员？ 一个营业厅？
- 30. Performance Vs Scalability 1.当只有一个人访问时，速度如何？ 2.当有很多人访问时，速度如何？ 大家都同样快？ 如果满足1 表示Performance很好？ 如何能较好的满足2 表示系统有较好的Scalability
- 31. 一致性问题再探讨 新浪发的微薄需要强一致吗？ ITPUB的论坛需要强一致吗？ 当当的图书描述信息需要强一致吗？ 12306的火车票库存信息需要强一致吗？ 支付宝/财付通的账户余额需要强一致吗？ 中行信用卡/招商银行卡的账户信息需要强一致 吗?
- 32. 数据状态机的分类 何谓状态机 简单的理解是，计算机中会发生变化的数据都是状态机， 这个数据的值不同可能会带来不同的后果。 分类：按照三个维度：时间、信息含金量、变更频率 持续时间 信息含金量 变更频繁度 例子 瞬时 高 少 Shopping Card Session（分） 瞬时 低 少 Login Cookie（分） 中等时长 高 少 Ecommerce Billing(天) 中等时长 中 少 Product Catalog(年) 中等时长 高 多 Flight/Train Inventory (月) 无限时长 中 少 User Profile（年) 无限时长 高 多 Bank Account Balance（年)）
- 33. Cache的基本概念 Cache的定义 Cachingis 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
- 34. Cache的设计考虑 缓存的一致性维护问题 数据的具体读写比 商品信息？库存信息？用户信息？账户余额？ Backend数据变更频率 业务对一致性的要求 使用何种缓存策略 Write Through Vs Write Back Vs Write Back with Compensate
- 35. Memcached是Cache吗？ It Depends 如果内容有Backend？是！ 如果内容没有Backend？否！ 案例 新浪微博的计数器？ 淘宝、当当的记录在缓存中的购物车信息？
- 36. 主题 数据库基本问题调查 关系数据库的基本背景 ACID基本概念解析 范式问题解析（Normalization） 数据库的扩展性浅析 常见数据库系统回顾
- 37. 数据存储的基本需求 存储数据 读写的性能（Hash查找、B*Tree查找） 数据的可靠性（Durability）支持 如何避免单点故障带来的数据丢失（数据保护） 是否支持多维查询（基于关系的查询） 对Replication的支持如何？ 支撑Scalability的复杂度
- 38. MySQL (Innodb) &Oracle 传统的关系数据库 支持多维索引 Oracle的支持较好 MySQL要到5.6才比较好的支持Index内Filter 较好的支持数据的一致性 成熟的MVCC设计 成熟的Replication设计 简单查询的效率略低于Memcached B*Tree的成本 MVCC带来的额外成本
- 39. MySQL & Oracle 在进行数据库扩展时 只能依赖于应用层的拆分（即：Sharding） 目前Sharding支持由TDDL实现 维护成本会相对较高 维护复杂度也比较高 软件的成本 Oracle为商业软件，有License费用 MySQL为开源软件，没有软件本身的费用
- 40.
- 41. Tair主要技术点 主要定位为 分布式Key/Value缓存 Data Server的具体实现 Memory Engine的实现类似于MemCached Config Server的实现 基于Consistent Hash实现集群的数据分布 基于此做Replication 做节点的故障检测与剔除 新加入节点时需要基于CHash做节点Rebalance
- 42.
- 43.
- 44. OceanBase系统架构 44 主控服务器RootServer：主+备，数据定位/全局Schema/机器管理… 动态数据服务器UpdateServer：主+备，实时修改(内存+SSD) 静态数据服务器ChunkServer：多台，静态数据存储 (磁盘或SSD) 动态数据不断地被合并到静态ChunkServer中实现分布式存储 JavaClient ChunkServer ChunkServer ChunkServer ChunkServer RootServer/ UpdateServer (主) RootServer/ UpdateServer (备)
- 45. OceanBase简介 UpdateServer负责所有的写入 本质上是一个读写分离的技术 对实时更新数据的查询可以在US的备库进行 ChunkServer理论上可以无限扩展 查询操作需要合并US+CS的结果 Root Server的职责类似于Tair的Config Server 相对于Tair的优势 可以进行Full Table扫描 可以进行范围数据查询 更好的ACID支持（目前支持MVCC） 不支持外键+唯一键（FK+UK）
- 46. 集团现有数据库特性粗略比较 Oracle MySQL TairOceanBase HBase 读性能 高 高 高 中 中 写性能 高 中 高 高 高 一致性 高 高 低 高-（除FK/UK） 中 数据保护 高（双份存储） 中+(单机故障) 低 高－(网络提交) 高－ 多维查询 高 中（索引稍弱） 无 无 无 备库 高(Physical) 高-(Logical) 低(Logical) 高-(Logical) 中+(Logical) 读扩展能力 中 高 高 高 高 写扩展能力 低 低 高 中 高 扩展复杂度 高 中 低 低 低 软件成本 高 无 研发费用 研发费用 无