Google云计算基本原理.pptVIP

Google云计算架构中GFS、MapReduce和BigTable中是否存在集群节点复用的情况？ 如何复用？ 节点复用的好处有哪些？ Google云计算架构的设计对你有哪些启发？有哪些收获？ Google App Engine * Google App Engine是隶属于PaaS类型的云服务 一个计算环境，支持Python和Java语言 可使用Google的基础服务，如BigTable和GFS等 用户仅需提供应用代码，无需服务器维护 应用程序可根据访问量和数据存储需要的增长轻松进行扩展 * 特性 动态网络服务功能，能够完全支持常用的网络技术 具有持久存储的空间，可支持查询、分类等基本操作 具有自主平衡网络和系统的负载、自动进行扩展的功能 可对用户的身份进行验证，并且支持使用Google账户发送邮件 具有一个功能完整的本地开发环境，开发人员可以在自身的计算机上模拟 Google App Engine环境 * 沙盒 一个虚拟环境 将开发者开发的应用程序隔离在自身的安全可靠的环境中，该环境和网络服务器的硬件、系统以及物理位置完全无关 仅提供开发人员对基础操作系统的有限访问权限 可以对开发人员进行更多的限制 只能通过网址抓取API和邮件服务API访问其他计算机 其他计算机只能通过HTTP或HTTPS与沙盒应用交互 应用程序无法对平台文件系统进行写入操作，只能读取代码文件 应用程序必须使用平台的Data Store来存储应用程序运行期间持续存在的数据 …… 通过隔离来保证平台和其他开发者的安全 * 图像操作API 开发人员可通过该API对JPEG和PNG图像进行缩放、裁剪、旋转和翻转等操作 邮件API 为开发人员开发的应用程序提供电子邮件发送服务 Memcache API 高性能的内存键值缓存，用户可使用应用程序访问该缓存 可提高应用程序的性能并减少数据库的负载 网址抓取API 可以使用HTTP或HTTPS等网址来对数据进行检索 * 用户API 使应用程序与Google帐号集成，支持Google帐号身份认证 数据库API 为用户提供查询引擎和事务存储服务 * print Content-Type: text/plain print print Hello, world! * Google云计算应用 MapReduce BigTable GFS Chubby Google云计算应用类型 * * 分布式数据表BigTable * 为什么需要设计BigTable？ Google需要存储的数据种类繁多 网页，地图数据，邮件…… 如何使用统一的方式存储各类数据？ 海量的服务请求 如何快速地从海量信息中寻找需要的数据？ BigTable：基于GFS和Chubby的分布式存储系统 对数据进行结构化存储和管理 与GFS的联系 * 数据存储可靠性 高速数据检索与读取 存储海量的记录（若干TB） 可以保存记录的多个版本 * 与写操作相比，数据记录读操作占绝大多数工作负载 单个节点故障损坏是常见的 磁盘是廉价的 可以不提供标准接口 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→com.baidu.mp3/index.asp * 列 特定含义的数据的集合，如图片、链接等 可将多个列归并为一组，称为族（family） 采用 族:限定词 的语法规则进行定义 fileattr:owning_group”, “fileattr:owning_user”, etc 同一个族的数据被压缩在一起保存 族是必须的，是BigTable中访问控制的基本单元 *