Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

数据库系统设计漫谈

3,715 views

Published on

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

Published in: Technology
  • Be the first to comment

数据库系统设计漫谈

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

×