大规模分布式存储系统原理解析与架构实战-读书笔记3-单机存储系统(2)

好久不见. 提交于 2020-01-18 04:53:34

大规模分布式存储系统原理解析与架构实战-读书笔记3-单机存储系统(2)

数据模型主要分为三类:文件,关系以及KV。

文件模型

文件系统以目录树的形式呈现。
对象模型和文件模型比较类似,用于存储视频,图片,文档等二进制数据块,典型的系统包括Amazon Simple Storage(S3),Taobao File System(TFS)

键值模型

Key-value模型简单,使用的场景有限,NoSQL中使用比较广泛的是表格模型,其弱化了关系模型中的多表关联,支持基于单表的简单操作,典型的是Google的BigTable和其Java实现的HBase

SQL和NoSQL

  • 事务:关系模型要求满足ACID,要么全部成功,要么全部失败。在分布式系统中,如果多个操作属于不同的服务器,满足原子性需要两阶段提交协议,而这个协议的性能很低,且不能容忍服务器故障,很难应用的海量数据场景。

并发控制

  • 数据库锁:允许加多个读锁,但只能有一个写锁。解决死锁的办法有两个:一个是给事务加超时时间,另一个是死锁检测。
  • 写时复制:因为读操作远远多于写操作,写时复制(Copy-On-Write)读操作不加锁,极大提高性能。
    1 拷贝:将从叶子节点到根节点路径上的所有点拷贝出来
    2 修改:对拷贝的节点执行修改。
    3 提交:原子地切换根节点的指针,使之指向新的根节点。
    多个写操作之间是互斥的,同一时刻只允许一个写操作
  • 多版本并发控制(MVCC Multi-version Concurrency Control)
    以InnoDB为例。每当一个事务开始时,都会给这个事务分配一个递增的事务号,对每一条语句,都会根据事务号执行相应的检查。
    MVCC读取数据不需要加锁。而且需要定期清理。

故障恢复

操作日志

操作日志分为回滚日志(UNDO LOG)重做日志(REDO LOG)以及UNDO/REDO LOG

  • 操作日志:为了保证数据库一致性,需要把数据持久化到磁盘,但是如果每次操作都随机更新磁盘中的数据块,性能会很差。所以使用操作日志记录操作并在内存中执行这些操作,再定期刷新到磁盘,就从随机写变成了顺序写。
    关系型数据库一般采用UNDO/REDO日志,可以将关系型数据库存储模型做一定简化:
    1 假设内存足够大,每次事务的修改操作都可以缓存在内存中
    2 每个事务只包含一个操作,即每个事务都必须立即提交(Auto Commit)

重做日志

存储模型如果使用REDO日志,流程如下:
1 将REDO日志以追加写的方式写入磁盘的日志文件中
2 将操作应用到内存中
3 返回成功或失败
需要先写入磁盘操作日志的原因是,如果先修改内存中的数据,用户就立即能读取到修改后的数据,一旦在完成内存修改和写入日志之间发生故障,那么最近的操作无法恢复,而用户已经读到了修改后的数据,就出问题了。

优化手段

  • 成组提交
  • 检查点
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!