云计算_02Google云计算原理与高级开发应用讲述.ppt

局部性群组（Locality groups） ?局部性群组(Locality Group) ?根据需要，将原本不存储在一起的数据，以列族为单位存储至单独的子表 ?有的用户可能只对网页内容感兴趣，那么它可以通过设置局部性群组（见下图）只看内容这一列；有的对诸如网页语言、网站排名等可以用于分析的信息比较感兴趣，他也可以将这些列设置到一个群组中 压缩 ?压缩 ?压缩可以有效地节省空间，Bigtable中的压缩被应用于很多场合 ?首先压缩可以被用在构成局部性群组的SSTable中，可以选择是否对个人的局部性群组的SSTable进行压缩。这种压缩是对每个局部性群组独立进行，虽然会浪费一些空间，但是在需要读时解压速度非常快 ?通常情况下，用户可以采用两步压缩的方式： ?第一步利用Bentley McIlroy方式（BMDiff）在大的扫描窗口将常见的长串进行压缩；第二步采取Zippy技术进行快速压缩，它在一个16KB大小的扫描窗口内寻找重复数据，这个过程非常快 ?压缩技术还可以提高子表的恢复速度，当某个子表服务器停止使用后，需要将上面所有的子表移至另一个子表服务器。转移前两次压缩：第一次压缩减少了提交日志中未压缩状态；文件正式转移前还要进行一次压缩，主要是将第一次压缩后遗留的未压缩空间进行压缩 布隆过滤器（Bloom Filter） ?布隆过滤器（Bloom Filter） ?巴顿·布隆在1970年提出的，实际上它是一个很长的二进制向量和一系列随机映射函数，在读操作中确定子表的位置时非常有用 ?优势：速度快，省空间。而且它有一个最大的好处是它绝不会将一个存在的子表判定为不存在 ?缺点：在某些情况下它会将不存在的子表判断为存在。不过这种情况出现的概率非常小，跟它带来的巨大好处相比这个缺点是可以忍受的 目前包括Google Analytics、Google Earth、个性化搜索、Orkut和RRS阅读器在内几十个项目都使用Bigtable。这些应用对Bigtable的要求以及使用的集群机器数量都各不相同，但从实际运行来看，Bigtable完全可以满足这些不同需求的应用，而这一切都得益于其优良的构架以及恰当的技术选择 谢 谢！ 《云计算（第二版）》购买网址： 当当网：/product.aspx?product_id京东商城：html * 《云计算（第二版）》购买网址： 当当网：/product.aspx?product_id京东商城：html * * * Chubby客户端与服务器端的通信过程 ?从左到右的水平方向表示时间在增加，斜向上的箭头表示一次KeepAlive请求，斜向下的箭头则是主服务器的一次回应 ? M1、M2、M3表示不同的主服务器租约期；C1、C2、C3则是客户端对主服务器租约期时长做出的一个估计 ? KeepAlive是周期发送的一种信息，它主要有两方面的功能：延迟租约的有效期和携带事件信息告诉用户更新 故障处理 客户端租约过期 ?客户端向主服务器发出一个KeepAlive请求（上图1） ?如果有需要通知的事件时则主服务器会立刻做出回应，否则等到客户端的租约期C1快结束的时候才做出回应（图2），并更新主服务器租约期为M2 ?客户端接到回应后认为该主服务器仍处于活跃状态，于是将租约期更新为C2并立刻发出新的KeepAlive请求（图3） ?宽限期内，客户端不会立刻断开其与服务器端的联系，而是不断地做探询，当它接到客户端的第一个KeepAlive请求（图4）时会拒绝（图5） ?客户端在主服务器拒绝后使用新纪元号来发送KeepAlive请求（图6） ?新的主服务器接受这个请求并立刻做出回应（图7） 如果客户端接收到这个回应的时间仍处于宽限期内，系统会恢复到安全状态，租约期更新为C3。如果在宽限期未接到主服务器的相关回应，客户端终止当前的会话 故障处理 主服务器出错 正常情况下旧的主服务器出现故障后系统会很快地选举出新的主服务器，新选举需要经历以下九个步骤： （1）产生一个新的纪元号以便今后客户端通信时使用，这能保证当前的主服务器不必处理针对旧的主服务器的请求 （2）只处理主服务器位置相关的信息，不处理会话相关的信息 （3）构建处理会话和锁所需的内部数据结构 （4）允许客户端发送KeepAlive请求，不处理其他会话相关的信息 （5）向每个会话发送一个故障事件，促使所有的客户端清空缓存 （6）等待直到所有的会话都收到故障事件或会话终止 （7）开始允许执行所有的操作 （8）如果客户端使用了旧的句柄则需要为其重新构建新的句柄 （9）一定时间段后（1分钟），删