HBase储备知识一：相关基本信息

一.维度

　　1.数据模型

　　　　数据有多种存储的方式，包括键值对【相似Map】、半结构化的列式存储和文档结构存储。

　　2.存储模型

　　　　内存仍是磁盘持久化能够和RDBMS进行比较，它们一般持久化存储数据到磁盘中。即便须要的是纯粹内存模式，也仍旧有其余方案。一旦考虑持久化存储，就须要考虑选择的方案是否影响到访问模式。

　　3.一致性模型

　　　　严格一致性仍是最终一致性？问题在于存储系统如何实现它的目标：是否必须下降一致性要求?虽然这种问题很粗浅，可是在特定的场景中会产生巨大影响。由于一致性可能会影响操做延迟，即系统响应读写请求的速度。这须要权衡投入和产出后获得一个折中结果。

　　4.物理模型

　　　　分布式模式仍是单机模式？这种架构看起来像什么？是仅仅运行在单个机器上，仍是分布在多台机器上，但分布及扩展规则由客户端管理，换句话说，由用户本身的代码管理？也许分布式模式仅仅是个过后的工做，而且只会在用户须要扩展系统时产生问题。若是系统提供了必定的扩展性，那么须要用户采起特定的操做吗？最简单的解决方案就是一次增长一台机器，而且设置好分区（这点对于不支持虚拟分区的系统很是重要），设置时须要考虑同时提升每一个分区的处理能力，由于系统的每一个部分都须要提供均衡的性能。

　　5.读/写性能

　　　　用户必须了解本身的应用程序的访问模式。是读多写少仍是读写至关，或者是写多读少。是用范围扫描数据好，仍是用随机读请求数据更好？有些系统仅仅对这些中的一种支持的很是好，有些系统则对各类状况都提供了很好的支持。

　　6.辅助索引

　　　　辅助索引支持用户按不一样的字段和排序方式来访问表。这个维度覆盖了某些彻底没有辅助索引支持且不保证数据排序的系统（相似于HashMap，及用户须要知道数据对应键的值），到某些可能经过外部手段简单支持这些功能的系统。若是存储系统不提供这项功能，用户的应用应该能够应对或本身模拟辅助索引。

　　7.故障处理

　　　　机器会崩溃是一个客观存在的问题，须要有一套数据迁移方案来应对这种状况。每一个数据存储如何进行服务器故障处理？故障处理完毕以后是否能够正常工做？这与一致性模式维度有关系，由于失去一台服务器可能会形成数据存储的空洞。甚至使整个数据存储不可用。若是替换故障服务器，那么恢复100%服务的难度有多大？从一个正在提供服务的集群中卸载一台服务器时，也会遇到相似的问题。

　　8.压缩

　　　　当用户须要存储TB级的数据时，尤为当这些数据差别很小或由可读性文本组成时，压缩会带来很是好的效果，即能节省大量原始数据存储。有些压缩算法能够将此类的数据压缩到原始文件大小的十分之一。有可选择的压缩组件，有哪些压缩算法可用。

　　9.负载均衡

　　　　假如用户有高读写吞吐量的需求，就要考虑配置一套可以随着负载变化自动均衡处理能力的系统。虽然这样不能彻底解决该问题，可是也能够帮助用户设计高读写吞吐量的程序。

　　10.原子操做的读-修改-写

　　　　RDBMS提供了不少这类的操做（由于它是一个集中式的面向单服务器的系统），但这些操做在分布式系统中较难实现，这些操做能够帮助用户避免多线程形成的资源竞争，也能够帮助用户完成无共享应用服务器的设计。有了这些比较并交换操做，或者说检查并设置操做，在设计系统的时候能够有效地下降客户端的复杂度。

　　11.加锁、等待和死锁

　　　　众所周知，复杂的事务处理，如两阶段提交，会增长多个客户端竞争同一个资源资源的可能性。最糟糕的状况就是死锁，这种状况也很难解决。用户须要支持的系统采用哪一种模型？这种锁模型可否避免等待和死锁。

二.可扩展性

　　RDBMS很是适合事务性操做，但不见长于超大规模的数据分析处理，由于超大规模的查询须要进行大规模的数据记录扫描或全表扫描。分析型数据库能够存储数百或数千TB的数据，在一台服务器上作查询工做的响应时间，会远远超过用户可接受的合理响应时间。垂直扩展服务器性能，即增长CPU核数和磁盘数目，也并不能很好地解决该问题。

　　更糟糕的是，RDBMS的等待和死锁的出现频率，与事务和并发的增长并非线性关系，准确地说，与并发数目的平方以及事务规模的3次方甚至5次方相关。分区一般是一个不切实际的解决方案，由于它须要客户端采用很是复杂的方式和较高的代价来维护分区信息。

　　一些商业RDBMS也解决过相似的问题，但它们每每只是特定地解决了问题的某几个方面，更重要的是，它们很是的昂贵。而一些开源的RDBMS解决方案中，每每放弃了其中的一些甚至所有的关系型特性，如辅助索引，来换取更高的性能拓展能力。

　　问题是，为了性能而一直放弃以上关系型特征是否值得？用户能够反范式化数据模型来避免等待，而且能够经过下降锁粒度的方式来尽可能避免死锁。数据增加时，无需从新分区迁移数据并内嵌水平扩展性的方法。最后，用户还要面对容错和数据可用性问题，采用提升扩展性的机制，用户最终会获得一个NoSQL的解决方案，更确切地说，HBase能够知足这些需求。

三.数据库的范式化和反范式化

　　不一样的规模，常常须要设计不一样的系统结构，对这种原则的最佳描述是：反范式化、复制和智能的主键。这就须要从新思考在相似BigTable的存储系统中如何才能高效合理地存储数据。

　　部分原则是采用反范式化模式，例如将数据以前存放在多张表中的数据存储在一张表中，这样在读取的时候就不须要从多张表中聚合数据。或者预先物化所需的视图，一次优化从而避免进一步的处理来提升读取性能。

　　有很是多的方法来转换一对1、一对多、多对多的关系，以适应HBase的底层架构。用户须要充分理解HBase存储设计的潜在能力，而后深思熟虑地决定用哪种实现方式。对稀疏矩阵、宽表、列式存储的支持使得数据在存储的时候无需规范化，同时也能够避免查询时采用开销很大的JOIN操做聚合数据。使用智能的主键能够控制数据怎样去存储以及存储在什么位置。因为可使用行键的部份内容进行范围检索，行键做为组合键设计时，与字典序左部分为头的索引效果类似。所以，正确的设计可以使性能不会由于数据的增加而降低，例如，当数据从10条增长到1000万条时，系统仍旧能够保持相同的读写性能【只限少许数据的rowkey读写】。