google云计算体系架构课件.pptVIP

文件系统中文件的权限 文件系统中文件操作的权限有哪些？ 这些权限之间的互斥关系是怎样的？ Chubby系统本质上就是一个分布式的、存储大量小文件的文件系统 Chubby中的锁就是文件 在GFS的例子中，创建文件就是进行“加锁”操作，创建文件成功的那个server其实就是抢占到了“锁” 用户通过打开、关闭和存取文件，获取共享锁或者独占锁；并且通过通信机制，向用户发送更新信息 * Chubby文件系统 * Client与Chubby的通信协议 主节点选举 独占锁 共享锁 数据存取应用 获取GFS ChunkServer信息 元数据存储 …… * Chubby的应用 Goolge的云计算 分布式数据表BigTable * 为什么需要设计BigTable？ Google需要存储的数据种类繁多 网页，地图数据，邮件…… 如何使用统一的方式存储各类数据？ 海量的服务请求 如何快速地从海量信息中寻找需要的数据？ BigTable：基于GFS和Chubby的分布式存储系统 对数据进行结构化存储和管理 与GFS的联系 * BigTable 数据存储可靠性 高速数据检索与读取 存储海量的记录（若干TB） 可以保存记录的多个版本 * Google的需求 与写操作相比，数据记录读操作占绝大多数工作负载 单个节点故障损坏是常见的 磁盘是廉价的 可以不提供标准接口 Google既能控制数据库设计，又能进行应用系统设计 * 假设 具有广泛的适应性 支持Google系列产品的存储需求 具有很强的可扩展性 根据需要随时加入或撤销服务器 应对不断增多的访问请求 高可用性 单个节点易损，但要确保几乎所有的情况下系统都可用 简单性 简单的底层系统可减少系统出错概率，为上层开发带来便利 * 设计目标 总体上，与关系数据库中的表类似 * 逻辑视图 Row Key Time Stamp Column Contents Column Anchor Column “mime” my.look.ca “n.www” T9 CNN T8 CNN.COM T6 “html.. “ Text/html T5 “html.. “ t3 “html.. “ 关系数据库中的表是什么样的？有什么特征？ 关系数据库中的表设计需要遵循什么原则？ 行 每行数据有一个可排序的关键字和任意列项 字符串、整数、二进制串甚至可串行化的结构都可以作为行键 表按照行键的“逐字节排序”顺序对行进行有序化处理 表内数据非常‘稀疏’，不同的行的列的数完全目可以大不相同 URL是较为常见的行键，存储时需要倒排 统一地址域的网页连续存储，便于查找、分析和压缩 * 数据模型 /index.asp→/index.asp 列 特定含义的数据的集合，如图片、链接等 可将多个列归并为一组，称为族（family） 采用 族:限定词 的语法规则进行定义 fileattr:owning_group”, “fileattr:owning_user”, etc 同一个族的数据被压缩在一起保存 族是必须的，是BigTable中访问控制的基本单元 * 数据模型 时间戳 保存不同时期的数据，如“网页快照” “A big table” 表中的列可以不受限制地增长 表中的数据几乎可以无限地增加 * 数据模型 通过(row, col, timestamp)查询 通过(row, col, MOST_RECENT)查询 无数据校验 每行都可存储任意数目的列 BigTable不对列的最少数目进行约束 任意类型的数据均可存储 BigTable将所有数据均看作为字符串 数据的有效性校验由构建于其上的应用系统完成 一致性 针对同一行的多个操作可以分组合并 不支持对多行进行修改的操作符 * 数据模型 * 物理视图 Row Key Time Stamp Column: Contents Cn.www T6 “html..” T5 “html..” T3 “html..” Row Key Time Stamp Column: Anchor Cn.www T9 Anchor: CNN T5 Anchor:my.look.ca CNN.COM Row Key Time Stamp Column: mime Cn.www T6 text/html Row Key Time Stamp Column Contents Column Anchor Column “mime” my.look.ca “n.www” T9 CNN T8 CNN.COM T6 “html.. “ Text/html T5 “html.. “ t3 “html.. “ 逻辑上的“表”被划分为若干子表（Tablet） 每个Tablet由多个SSTable文件组成