HBase权威指南分章笔记研讨.docx

HBase权威指南 第一章： 1) 特征 非关系型数据库中有很多共同的特征，与传统型数据库也有一些相同的特征。所以Nosql系统并不是真正的革新的技术，但是从engineering角度上讲是革新。 但是像memcached(分布式内存缓存系统)都归入到了Nosql范畴内，好像只要不是RDBMS就自动归类到NoSQL中，这可到导致某种意义上的错误划分，从而模糊这些技术能够能够的技术可能性。在NoSQL类型中，有很多维度上，你可以用来划分某个系统的特点。 1、数据模型 数据如何存储有很多不同点，包括key/value存储，半结构化存储，基于列存储及面向文档存储。你的应用如何访问数据，这些模型是否会返回改变？ 2、存储模型 内存还是磁盘？由于我们和RDBMS比较，很容易决定。 3、一致性 强制还是最终一致性？这个问题涉及到，存储系统的目标，是否弱化保证一致性？一致性在确定的用户实例中，造成所有的不同，特别是延迟的影响。 4、物理模型 分布式还是单个机器？系统架构是分布式机器还是单独机器（distributeion handled client-side）。这个模式对系统的扩展性有很大的影响。简单的方式，是每次增加一个机器，承担一个shared setups，但是对实时性要求高，而且每个分片都需要同样的计算能力。 5、读/写性能 必须理解你的应用的访问模式。主要读操作还是写操作，还是读写均衡？是否需要支持区域读，还是随机读？已有的系统可能对某一个特性有效，可能系统对所有的特点均支持。 6、secondary index(辅助索引) 辅助索引允许你根据不同的fields及已排序的序列进行排序及访问操作。这个特征肯定包括一定没有赋值索引及不保证排序。要想支持这个特征，需要额外添加模块。 7、故障处理 8、压缩 你可能需要存储TB级数据，因此压缩数据是需要的 9、负载均衡 考虑到高读写，你可能需要存储需要透明的均衡，这个特征可能不能解决你所有问题，但是能帮助你设计高吞吐量的应用设计 10、原子read-modify-write 11、locing,waits,and deadlocks 复杂的事务处理，像两阶段提交，可能使多客户端等待的资源成为可能性。在最坏的场景下，可能导致死锁，很难解决。系统是哪种锁模型,可能是free of waits，造成死锁？ 2）、数据库的标准化 有些情况下，需要我们设计这些不同的schema，可以用非规范化、副本及Intelligent Keys(DDI)。反思数据如何在BigTable存储系统中存储，怎样达到适当的方式。 下面是一个将典型的关系型数据库模型转为适合于列存储的HBase。HBase URL Shortener,Hush，将Long URLs转换为short URLS。下图是实体关系图： 缩短网址,存储在SHORTURL表中，点击时（onclick），随后就会打开全URL，每一次点击都会被记录在Click表中，包括点击的次数，及从何处点击，然后用于日常分析。USERS表中的用户可以使用HUSH创建自己的缩短网址，即添加描述，根据外键进行连接。系统也会再后台下载Linked page用于分析例如HTML中的TITLE。整个网页可以缓存下来，用于批处理或者分析，这些数据保存在URL表中。 下图是用HBase来存储相同的方案， 3) HBase构件 这个部分介绍HBase各个组成部分、数据模型及可用的API。 3.1 Tables、Rows、columns及cells 基本单位是列，一个或者多列构成一行，使用rowkey进行addressed。一些列的行数据，构成了一个表。每列都有多个版本值，存储在单独的单元中。很像传统的数据表，但是extra dimension允许每一个单元多个版本。所有的行按照rowkey的字典顺序就行排序。 行由多个列构成的列族构成，列族可以由语义或者topic boundaries来定义。列族保存在同一文件（HFILE）中。列族在定义表时就固定，不宜改动或者太多列族，当前一般不超过数十列族。列族的名字由printable charates组成。列族通常以family:qualifier来参考，列族内的列没有什么限制，对列存储的值也没有什么限制。下图是传统数据库表及HBase表的存储比较，You should think about rows and columns not being arranged like the classic spreadsheet model,but rather use a tag metaphor that is information is available under a specific tag。 所