NoSQL选型及HBase案例详解(转)

从 NOSQL的类型到 常用的产品，我们已经做过很多关于NoSQL的文章，今天我们从国内著名的互联网公司及科研机构的实战谈一下NoSQL数据库。
　　NoSQL一定程度上是基于一个很重要的原理—— CAP原理提出来的。传统的SQL数据库（关系型数据库）都具有ACID属性，对一致性要求很高，因此降低了A（availability）和P（partition tolerance）。为了提高系统性能和可扩展性，必须牺牲C（consistency）。

Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性 

 

关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区：
Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成。
Consistency一致性. 在事务开始或结束时，数据库应该在一致状态。
Isolation隔离层. 事务将假定只有它自己在操作数据库，彼此不知晓。
Durability. 一旦事务完成，就不能返回。

 

　　依据CAP理论，从应用的需求不同，数据库的选择可从三方面考虑：
　　考虑CA，这就是传统上的关系型数据库(RDBMS)。
　　考虑CP，主要是一些Key-Value数据库，典型代表为Google的Big Table，将各列数据进行排序存储。数据值按范围分布在多台机器，数据更新操作有严格的一致性保证。
　　考虑AP，主要是一些面向文档的适用于分布式系统的数据库，如Amazon的Dynamo，Dynamo将数据按key进行Hash存储。其数据分片模型有比较强的容灾性，因此它实现的是相对松散的弱一致性——最终一致性。
　　SurDoc是书生公司自主创新的电子文档云服务平台，它支持云服务和移动终端，基于国际标准UOML，是目前全球唯一能让用户无需安装Office、PDF或其他软件就能阅读所有格式文档的产品。书生网北京书生软件公司副总裁兼CTO金友兵介绍了SurDoc开发过程中数据库的NoSQL选型及使用经验。
　　首先，金友兵认为数据模型是数据库选型中首先要考虑的问题，SurDoc中主要有三类数据：
　　用户自己上传的文档，采用分布式文件系统存储
　　用户自己的文档信息库，采用关系数据库MySQL。
　　文档本身的基本信息、分片信息及存储位置等，采用NoSQL数据库。这部分数据的主要特点是数据量大并且数据结构比较简单。这部分数据要保证CAP原理中的AP。
　　NoSQL数据库的选型需要考虑以下几方面：
　　数据模型及操作模型：应用层数据模型是行、对象还是文档型的呢？系统是否能支持统计工作？
　　可靠性：更新数据时，新的数据是否立刻写到持久化存储中去了？新的数据是否同步到多台机器上了？
　　扩展性：你的数据量有多大，单机是否能容下？读写量要求单机是否能支持？
　　分区策略：考虑对扩展性，可用性或者持久性的要求，是否需要一份数据被存在多台机器上？是否需要知道数据在哪台机器上。
　　一致性：数据是否被复制到了多台机器上，这些分布在不同点的数据如何保证一致性？
　　事务机制：业务是否需要ACID的事务机制？
　　单机性能：如果持久化将数据存在磁盘上，需求是读多还是写多？写操作是否会成为磁盘瓶颈？
　　负载可评估：是否支持负载监控？
　　初期MemcacheDB实践
　　优点：
　　MemcacheDB利用Berkeley DB的持久化存储机制和异步主辅复制机制，使memcached具备了事务恢复能力、持久化能力和分布式复制能力，
　　非常适合于需要超高性能读写速度，但是不需要严格事务约束，能够被持久化保存的应用场景。
　　吞吐量大，读写速度优秀，兼容memcached接口
　　缺点：
　　只支持单向的主从复制方式，可用性差。由于存在命中率问题，有时无法正确读，横向扩展比较困难。
　　Redis实践
　　数据库也具有类似于MemcacheDB的问题，新浪微博采用的NoSQL数据库是Redis，Redis的优点是性能很高。
　　TokyoTyrant实践
　　优点：
　　读写速度和并发性能比较优秀，支持Memcached协议，而且支持通过双主复制实现高可用性。
　　缺点：
　　需要通过客户端实现数据分布，增删节点时的数据重分布较难实现。与Surdoc采用的分布式文件系统不能很好的配合，不太适合互联网应用。
　　CouchBase实践
　　优点：
　　吞吐量极高，读写速度极快，支持memcached协议
　　实测三个Couchbase节点可以达到12000以上的ops
　　缺点：
　　采用缓存全部key的策略，需要大量内存；节点宕机时failover过程有不可用时间，并且有部分数据丢失的可能；在高负载系统上有假死现象
　　设计过程中应该尽量减少Key的位数，实际运营了一段时间，出现故障的概率较高。
　　最终选择——Amazon Dynamo的开源实现Riak
　　优点：
　　完全的Dynamo实现，数据总是可写
　　高可用：设计上天然没有单点，每个实例由一组节点组成，从应用的角度看，实例提供I/O 能力。一个实例上的节点可能位于不同的数据中心内，这样一个数据中心出问题也不会导致数据丢失。
　　可通过增加节点提高集群吞吐量
　　后端存储采用levelDB，不需要大量内存
　　实测三个Couchbase节点可以达到5000左右的ops
　　缺点：
　　不支持memcached协议，需要修改现有代码；没有完善的监控系统，需要自行实现
　　Riak技术要点：
　　数据定位使用一致性哈希
　　Vector lock，允许数据的多个备份存在多个版本，提高写操作的可用性（用弱一致性来换取高的可用性）
　　容错：Sloppy Quorum, hinted handoff, Merkletree
　　网络互联: Gossip-based membership protocol ，一种通讯协议，目标是让节点与节点之间通信，实现去中心化
　　此外，Riak还具有执行Mapreduce操作的能力：
　　Map过程在各个物理节点上并行的执行
　　Reduce过程在提交MapReduce的节点上并行执行
　　支持以Javascript和Erlang代码编写MapReduce过程
　　基于SurDoc系统的数据模型及各种应用场景，金友兵介绍的NoSQL数据库大多数保证CAP原理中的AP，我们上面已经提到还有另一类以Big Table为代表的NoSQL数据库，人人游戏大数据研究组数据科学家林述民为我们介绍了Big Table的开源实现——HBase。
　　首先，根据官方定义，HBase并不是一个数据库：
　　Apache HBase? is the Hadoop database, a distributed, scalable, big data store.
　　它是BigTable的开源实现，HBase用了大量的词汇替代以前Google论文中的设计理念或者是设计概念，如果想深入了解HBase工作原理，一定要把这些词从原文上找到出处或者是意义。以下是一些对应关系：

　　在整个Hadoop生态系统中，它位于HDFS的上层。

　　上图是整个HBase的总体架构图，大概分为三个层次：最上面就是访问HBase的一个客户端，中间相当于RegionServer，可以管理最下层的分布式文件系统，标准的配置是HDFS。三个层次之间是解耦的，好多人对此存在一些误区。
　　Rowkey设计是使用HBase时最重要的一个环节，接下来林述民以通过对比NoSQL数据库和关系型数据库，说明了HBase的Rowkey设计会怎样影响系统的性能。
　　例1：稀疏矩阵结构
　　比如我国的省市结构是一个典型的树型结构：中国下面有北京、上海直辖市，还有广州、山东这样一些省，省下面还有市。采用传统的关系型数据库存储是以下的方式：

　　用HBase设计这样的存储结构是这样做的：

　　可能还是用这个主键标识一个地区，那边还是有两个列，但不再用打逗号的方式来存它的父节点或者子节点。因为HBase中的列可以在生产过程中定义，不需要预先定义好。对于一些稀疏的矩阵结构，这种存储方式的优势很明显。
　　例2：多对多关系
　　比如学校的选课系统，一个学生可以选很多门课程，同时每门课程也可以有好多学生去选，是一个典型的多对多关系。传统的关系型数据库存储：

　　HBase存储方式：

　　这样设计，可以实现每条记录的动态扩展，很匹配真实的业务场景。
　　例3：Key代替索引
　　比如人人的广告系统，一天就有十亿条记录。这些记录怎样存储下来呢？一种方式就是直接放到文件系统，包括用户ID是什么，名字是什么，什么时候做了什么事。为了便于查询，就必须要做索引，会降低性能。
　　在HBase中是这样设计的：

　　表中左列是Key，第一部分是用户标识，第二部分是用户操作时间，第三部分是事件ID（靠前的在检索时更有优势，在设计时可以利用这点进行优化）。检索的时候，首先找到这个Key在哪台服务器上，客户端再直接去那台服务器中做一个很小范围的检索。存的时候也通过这个ID存到不同服务器上面，所以吞吐量非常大。
　　例4：热点问题
　　用户的社交关系存储，大型互联网公司都会遇到这个问题。类似于前面的例子，在HBase中可以这样设计：

　　但是这种设计会存在热点问题，比如某个人可能有十万个好友，一旦查询到这个人，整个服务器就死掉了。所以这个设计可以改进一下，可以把friend那一列的内容也放到Key中，这张表就变成两两之间的关系，热点问题就可以解决了。
　　例5：关联概念
　　接下来是一个数据分析案例，业务场景是这样的：假设有一个搜索引擎每天采集用户大量的搜索数据，怎样知道用户总是把哪些概念放在一起搜索？在HBase中可以得到这样的逻辑关系，其中T(n)是搜索关键词：

　　这种逻辑关系在关系型数据库中是无法设计的，其存储优势在于列弹性，只有被一起检索过的关键词才会存储下来，这也是传统意义上列存储的优势。
　　通过这几个案例可以知道在HBase中需要注意以下几个问题：
　　避免热点问题，分布式就怕不均匀。
　　HBase有分割的概念。一台服务器如果存储数据量很大，会把大表或者小表分成两个更小的表，放在其他服务器上，所以尽量要减少这些分割。
　　珍惜每一个字节，可以节约资源，降低风险，而且可以减少I/O，使这个系统做到最佳。
　　HBase没有外键，也没有join和跨表的transaction。
　　接下来，中国科学院信息工程研究所副研究员王树鹏为我们分享了“新型NoSQL大数据管理系统（BDMS）开发和使用交流”。王树鹏介绍说他接触的项目多数是非互联网的应用，比如安全、交通行业。这些行业目前也面临着大数据的考验，但是当前很多流行的NoSQL数据库对于他们来说并不适用，所以他们自主研发了一个NoSQL数据库管理系统。
　　设计目标
　　系统具有高可扩展性：可通过增加节点线性
　　支持复杂数据类型统一存储管理：结构化数据、半结构化数据及非结构化数据；文本数据、多媒体数据；针对多种类型业务数据进行统一组织管理和处理
　　支持多样化的访问类型，访问接口标准化：检索、统计分析、关联处理及深入挖掘；需要对多种业务数据进行关联综合分析；提供标准的DDL、DML操作语法，支持JDBC、ODBC等操作接口；对数据检索、统计、分析处理的实时性要求很高；检索要求秒级响应；跨域检索访问

　　上图是整个系统的框架，其中数据库管理平台的结构如下：

　　其中，可以通过管理引擎实现跨越数据管理。对外可以提供相应的DDL接口、DML的接口以及开发接口。
　　系统主要特色
　　Share-Nothing的分布式存储和计算架构
　　异构多源数据的组织管理：实现了结构化数据、非结构化文本及非结构化多媒体的统一存储管理
　　支持异构数据的统一SQL查询：支持对于结构化数据、非结构化文本的检索和分析，该检索和分析操作都可以通过SQL进行实现
　　丰富的数据访问和处理模式
　　高效的检索机制
　　异构多副本存储和恢复机制
　　跨域数据管理和检索：支持跨域部署，可以在多个物理地点建立多个数据中心，在此之上可以支持数据在数据中心之间进行移动，并且可以支持对于位于不同地域的数据进行全局检索和访问
　　应用场景
　　海量结构化记录管理
　　处理海量小文档管理和处理
　　面向异构数据的智能搜索和挖掘系统
　　成功案例
　　王树鹏介绍说这个系统已经有了成功的应用案例，是国家某部委大数据管理项目。这个系统的主要需求是：
　　大量信息记录，每天产生约40亿条(约4TB)；
　　数据保留备份副本，记录数据保留半年；
　　可对数据进行精确、模糊查询及统计，结果秒级响应；
　　可批量导入结构化、非结构化数据；
　　最终达到的实施效果是：
　　采用分布式存储架构（3个元数据节点+115个存储节点）；
　　数据规模超过5000亿 ，查询响应时间为秒级；
　　数据保留2个副本，保证数据安全；
　　系统可用容量约2PB。