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

本文链接：https://blog.csdn.net/qq_36152792/article/details/103981387

大规模分布式存储系统原理解析与架构实战-读书笔记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 返回成功或失败
需要先写入磁盘操作日志的原因是，如果先修改内存中的数据，用户就立即能读取到修改后的数据，一旦在完成内存修改和写入日志之间发生故障，那么最近的操作无法恢复，而用户已经读到了修改后的数据，就出问题了。