大数据存储系统学习笔记（一）

1. NFS

1. 设计目标：服务器出现故障，可以简单快速地恢复

2. NFS Server不保持任何状态，每个操作都是无状态的

3. 如果NFS崩了，只用重启，什么额外操作都不用，因为每个操作无状态

4. NFSv2 对于 Cache Consistency 的解决方法

   • 在文件关闭时，必须把缓存的已修改的文件数据，写回NFS Server
   • 发送GETATTR请求，获得最新的文件属性；比较文件修改时间

   缺点：1. 大量的GETATTR（即使文件只被一个client缓存） 2. 关闭文件时写回文件

2. AFS

1. 设计目标：一个服务器支持尽可能多的客户端；解决NFS polling状态的问题

2. 解决 polling 状态的问题：

   • Client 获得一个文件时，在server上登记
   • 当server发现文件修改时，向已登记的client发一个callback
   • Client收到callback，则删除缓存的文件

   优点：有效地避免了polling的代价，减轻了Server的负担

3. AFS vs NFSv2:

   • AFS缓存整个文件,而NFS是以数据页为单位的，AFS open: 将把整个文件从Server读到Client，多次操作：就像本地文件一样，单次对一个大文件进行随机读/写：比较慢
   • AFS缓存在本地硬盘中，而NFS的缓存是在内存中的，所以AFS可以缓存大文件

3. HDFS/GFS 系统架构(只能append)

• Name Node：存储文件的metadata(元数据) 文件名，长度，分成多少数据块，每个数据块分布在哪些Data Node上

• Data Node: 存储数据块

• 文件切分成定长的数据块（默认为64MB大小的数据块）

• 每个数据块独立地分布存储在Data Node上

• 默认每个数据块存储3份，在3个不同的data node上
  

• 打开文件时，与Name Node通信一次

• 之后的读操作，直接与Data Node通信，绕过了Name Node

• 可以从多个副本中选择最佳的Data Node读取数据

• 优点：可以支持很多并发的读请求

• Name Node决定应该写到哪些Data Nodes：3个副本：本机、本机柜、其它机柜

• 收到写命令时才进行真正地写操作

• 把缓存的数据写到文件系统中

• 如果一个写操作跨了两个数据块：那么就被分解成为两个独立的写数据块操作，完全没有任何关于两个独立数据块写顺序的规定

4. HDFS/GFS 小结

• 分布式文件系统
• 很好的顺序读性能:为大块数据的顺序读优化
• 不支持并行的写操作：不需要distributed transaction
• 支持并行的append

5. No‐SQL

​ 简化RDBMS的能力：不支持（完全的）SQL，不支持（完全的）ACID，支持非关系的数据模型

1. Dynamo 数据模型和操作：

   • 最简单的<key, value>：key = primary key：唯一地确定这个记录，value：大小通常小于1MB
   • 只有put和get操作
   • 没有Transaction概念，仅支持单个<key,value>操作的一致性

2. Dynamo 系统结构：

• 多个nodes互连形成分布式系统

• 每个node上由local storage engine + dynamo软件层组成

• 一致性哈希(p2p 的关键技术)：https://blog.csdn.net/weixin_42200347/article/details/124572825

• 一致性哈希备份（三副本备份）：

• Put到Node j上的数据，要备份到Node j+1和Node j+2上

• 在这种设置下，Node j上实际存储的数据是$(u_{j-3},u_j]$

• Consistent Hashing: 减少一个 node:

• 改变Node5的区间，拷贝数据

• Consistent Hashing: 增加一个 node:

• 给新node赋值,改变区间，拷贝数据,对Node 6与node 7有类似修改

• Quorum机制：高效+读写一致性：多个副本可能存储同一个Key的不同的Value版本，怎么能够读到最新数据？

• Quorum (N, W, R)：有N个副本，写：保证>=W个副本的写完成，读：读>=R个副本，选出其中最新版本，如果满足R+W>N，那么一定读到了最新的数据

• R小，那么读的效率就高；W小，那么写的效率就高

• Put操作并没有等待所有N个节点写完：1. 可以提高写效率 2. 可以避免访问出错/下线的节点，提高系统可用性

• 系统总会最终保证每个<key,value>的N个副本都写成功，都变得一致：1. 但并不保证能够在短时间内达到一致 2. 最终可能需要很长时间才能达到 这种“最终”达到的一致性就是eventual consistency

3. Dynamo 小结：

   • 最简单的<key,value>模型，get/put操作
   • 单节点上存储由外部存储系统实现
   • 多节点间的数据分布：一致性哈希、Quorum (N, W, R)、Eventual consistency

6. Hbase

1. 数据模型

• Key包括row key与column两个部分，所有row key是按顺序存储的

• 其中column又有column family前缀，具体存储时，每个column family将分开存储

• 简单<key, value>可以对应为一个两列的Table

• <row key, column family: column key, value> 每个column family可以对应为一个3列的Table

2. 内部存储如何找到 Tablet：

   • 内部是三层的B+‐Tree，每个叶子节点是一个Tablet
   • 内部节点是特殊的MetaData Tablet，MetaData Tablet 包含Tablet位置信息

3. 单个Tablet内部的存储结构：

   • B+‐Tree：每一次Insertion都导致一次随机写
   • LSM‐Tree目标：减少随机写

4. LSM‐Tree vs. B+‐Tree：

   • B+‐Tree：Insert/delete/update：随机写、Search：性能好、Scan：访问一组叶子节点
   • LSM‐Tree：Insert/delete/update：顺序读写、Search：多次访问、Scan：归并多个层次

7. Bigtable / Hbase 小结

1. Key包含了row key, column key的结构
2. 除了Get/Put，还提供Scan(范围扫描操作) 按照row key有序存储
3. 底层存储采用了分布式文件系统
4. Master与Tablet Server
5. Tablet Server的内部结构：1. LSM‐Tree 2. MemTable, SSTable, 和log