hadoop-06

  1. 1. Hadoop2.0改进与提升
  2. 2. YARN资源管理框架
    1. 2.1. YARN体系结构
      1. 2.1.1. ResourceManager
      2. 2.1.2. ApplicationMaster
      3. 2.1.3. NodeManager
    2. 2.2. YARN工作流程
      1. 2.2.1. 作业提交全过程
      2. 2.2.2. 资源调度器
      3. 2.2.3. -
  3. 3. HDFS的高可用
    1. 3.1. HDFS的高可用架构
  4. 4. NoSQL
    1. 4.1. NoSQL兴起的原因
    2. 4.2. 传统数据库缺点
    3. 4.3. 比较
    4. 4.4. 总结
  5. 5. 键值数据库
  6. 6. 列族数据库
  7. 7. 文档数据库
  8. 8. 图形数据库
  9. 9. 不同类型数据库比较分析
  10. 10. 云数据库的特性

Hadoop2.0改进与提升

相比Hadoop1.0版本,Hadoop2.0的优化改良主要体现在两个方面:一方面是Hadoop自身核心组件架构设计的改进,另一方面是Hadoop集群性能的改进,通过这些优化和提升,Hadoop可以支持更多的应用场景,提高资源利用率。

Hadoop1.0的核心组件(仅指MapReduce和HDFS,不包括Hadoop生态系统内的Pig、Hive、HBase等其他组件),主要存在以下不足:

  • 抽象层次低,需人工编码
  • 表达能力有限
  • 开发者自己管理作业(Job)之间的依赖关系
  • 难以看到程序整体逻辑
  • 执行迭代操作效率低
  • 资源浪费(Map和Reduce分两阶段执行)
  • 实时性差(适合批处理,不支持实时交互式)

Hadoop的优化与发展主要体现在两个方面:

  • 一方面是Hadoop自身两大核心组件MapReduce和HDFS的架构设计改进
  • 另一方面是Hadoop生态系统其它组件的不断丰富,加入了Pig、Tez、Spark和Kafka等新组件
组件 Hadoop1.0的问题 Hadoop2.0的改进
HDFS 单一名称节点,存在单点失效问题 设计了HDFS HA,提供名称节点热备机制
HDFS 单一命名空间,无法实现资源隔离 设计了HDFS Federation,管理多个命名空间
MapReduce 资源管理效率低 设计了新的资源管理框架YARN
组件 功能 解决Hadoop中存在的问题
Pig 处理大规模数据的脚本语言,用户只需要编写几条简单的语句,系统会自动转换为MapReduce作业 抽象层次低,需要手工编写大量代码
Spark 基于内存的分布式并行编程框架,具有较高的实时性,并且较好支持迭代计算 延迟高,而且不适合执行迭代计算
Oozie 工作流和协作服务引擎,协调Hadoop上运行的不同任务 没有提供作业(Job)之间依赖关系管理机制,需要用户自己处理作业之间依赖关系
Tez 支持DAG作业的计算框架,对作业的操作进行重新分解和组合,形成一个大的DAG作业,减少不必要操作 不同的MapReduce任务之间存在重复操作,降低了效率
Kafka 分布式发布订阅消息系统,一般作为企业大数据分析平台的数据交换枢纽,不同类型的分布式系统可以统一接入到Kafka,实现和Hadoop各个组件之间的不同类型数据的实时高效交换 Hadoop生态系统中各个组件和其他产品之间缺乏统一的、高效的数据交换中介

YARN资源管理框架

YARN体系结构

YARN(Yet Another Resource Negotiator,另一种资源协调者)是一个通用的资源管理系统和调度平台,它的基本设计思想是将MRv1(Hadoop1.0中MapReduce)中的JobTracker拆分为两个独立任务,这两个任务分别是全局的资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。

  • MapReduce1.0既是一个计算框架,也是一个资源管理调度框架
  • 到了Hadoop2.0以后,MapReduce1.0中的资源管理调度功能,被单独分离出来形成了YARN,它是一个纯粹的资源管理调度框架,而不是一个计算框架
  • 被剥离了资源管理调度功能的MapReduce 框架就变成了MapReduce2.0,它是运行在YARN之上的一个纯粹的计算框架,不再自己负责资源调度管理服务,而是由YARN为其提供资源管理调度服务

ResourceManager

  • 处理客户端请求
  • 启动/监控ApplicationMaster
  • 监控NodeManager
  • 资源分配与调度

NodeManager

  • 单个节点上的资源管理
  • 处理来自ResourceManger的命令
  • 处理来自ApplicationMaster的命令

ApplicationMaster

  • 为应用程序申请资源,并分配给内部任务
  • 任务调度、监控与容错

ResourceManager

  • ResourceManager(RM)是一个全局的资源管理器,负责整个系统的资源管理和分配,主要包括两个组件,即调度器(Scheduler)和应用程序管理器(Applications Manager)
  • 调度器接收来自ApplicationMaster的应用程序资源请求,把集群中的资源以“容器”的形式分配给提出申请的应用程序,容器的选择通常会考虑应用程序所要处理的数据的位置,进行就近选择,从而实现“计算向数据靠拢”
  • 容器(Container)作为动态资源分配单位,每个容器中都封装了一定数量的CPU、内存、磁盘等资源,从而限定每个应用程序可以使用的资源量
  • 调度器被设计成是一个可插拔的组件,YARN不仅自身提供了许多种直接可用的调度器,也允许用户根据自己的需求重新设计调度器
  • 应用程序管理器(Applications Manager)负责系统中所有应用程序的管理工作,主要包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等

ApplicationMaster

ResourceManager接收用户提交的作业,按照作业的上下文信息以及从NodeManager收集来的容器状态信息,启动调度过程,为用户作业启动一个ApplicationMaster

ApplicationMaster的主要功能是:
(1)当用户作业提交时,ApplicationMaster与ResourceManager协商获取资源,ResourceManager会以容器的形式为ApplicationMaster分配资源;
(2)把获得的资源进一步分配给内部的各个任务(Map任务或Reduce任务),实现资源的“二次分配”;
(3)与NodeManager保持交互通信进行应用程序的启动、运行、监控和停止,监控申请到的资源的使用情况,对所有任务的执行进度和状态进行监控,并在任务发生失败时执行失败恢复(即重新申请资源重启任务);
(4)定时向ResourceManager发送“心跳”消息,报告资源的使用情况和应用的进度信息;
(5)当作业完成时,ApplicationMaster向ResourceManager注销容器,执行周期完成。

NodeManager

NodeManager是驻留在一个YARN集群中的每个节点上的代理,主要负责:

  • 容器生命周期管理
  • 监控每个容器的资源(CPU、内存等)使用情况
  • 跟踪节点健康状况
  • 以“心跳”的方式与ResourceManager保持通信
  • 向ResourceManager汇报作业的资源使用情况和每个容器的运行状态
  • 接收来自ApplicationMaster的启动/停止容器的各种请求

需要说明的是,NodeManager主要负责管理抽象的容器,只处理与容器相关的事情,而不具体负责每个任务(Map任务或Reduce任务)自身状态的管理,因为这些管理工作是由ApplicationMaster完成的,ApplicationMaster会通过不断与NodeManager通信来掌握各个任务的执行状态

在集群部署方面,YARN的各个组件是和Hadoop集群中的其他组件进行统一部署的

YARN工作流程

  1. MR程序提交到客户端所在的节点。
  2. YarnRunner向ResourceManager申请一个Application。
  3. RM将该应用程序的资源路径返回给YarnRunner。
  4. 该程序将运行所需资源提交到HDFS上。
  5. 程序资源提交完毕后,申请运行mrAppMaster。
  6. RM将用户的请求初始化成一个Task。
  7. 其中一个NodeManager领取到Task任务。
  8. 该NodeManager创建容器Container,并产生MRAppmaster。
  9. Container从HDFS上拷贝资源到本地。
  10. MRAppmaster向RM 申请运行MapTask资源。
  11. RM将运行MapTask任务分配给另外两个NodeManager,另两个NodeManager分别领取任务并创建容器。
  12. MR向两个接收到任务的NodeManager发送程序启动脚本,这两个NodeManager分别启动MapTask,MapTask对数据分区排序。
  13. MrAppMaster等待所有MapTask运行完毕后,向RM申请容器,运行ReduceTask。
  14. ReduceTask向MapTask获取相应分区的数据。
  15. 程序运行完毕后,MR会向RM申请注销自己。

作业提交全过程

作业提交全过程详解
(1)作业提交
第1步:Client调用job.waitForCompletion方法,向整个集群提交MapReduce作业。
第2步:Client向RM申请一个作业id。
第3步:RM给Client返回该job资源的提交路径和作业id。
第4步:Client提交jar包、切片信息和配置文件到指定的资源提交路径。
第5步:Client提交完资源后,向RM申请运行MrAppMaster。
(2)作业初始化
第6步:当RM收到Client的请求后,将该job添加到容量调度器中。
第7步:某一个空闲的NM领取到该Job。
第8步:该NM创建Container,并产生MRAppmaster。
第9步:下载Client提交的资源到本地。
(3)任务分配
第10步:MrAppMaster向RM申请运行多个MapTask任务资源。
第11步:RM将运行MapTask任务分配给另外两个NodeManager,另两个NodeManager分别领取任务并创建容器。
(4)任务运行
第12步:MR向两个接收到任务的NodeManager发送程序启动脚本,这两个NodeManager分别启动MapTask,MapTask对数据分区排序。
第13步:MrAppMaster等待所有MapTask运行完毕后,向RM申请容器,运行ReduceTask。
第14步:ReduceTask向MapTask获取相应分区的数据。
第15步:程序运行完毕后,MR会向RM申请注销自己。
(5)进度和状态更新
YARN中的任务将其进度和状态(包括counter)返回给应用管理器, 客户端每秒(通过mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更新, 展示给用户。
(6)作业完成
除了向应用管理器请求作业进度外, 客户端每5秒都会通过调用waitForCompletion()来检查作业是否完成。时间间隔可以通过mapreduce.client.completion.pollinterval来设置。作业完成之后, 应用管理器和Container会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。

资源调度器

FIFO

容量

公平

-

从MapReduce1.0框架发展到YARN框架,客户端并没有发生变化,其大部分调用API及接口都保持兼容,因此,原来针对Hadoop1.0开发的代码不用做大的改动,就可以直接放到Hadoop2.0平台上运行

  • 总体而言,YARN相对于MapReduce1.0来说具有以下优势:
    大大减少了承担中心服务功能的ResourceManager的资源消耗
    • ApplicationMaster来完成需要大量资源消耗的任务调度和监控
    • 多个作业对应多个ApplicationMaster,实现了监控分布化
  • MapReduce1.0既是一个计算框架,又是一个资源管理调度框架,但是,只能支持MapReduce编程模型。而YARN则是一个纯粹的资源调度管理框架,在它上面可以运行包括MapReduce在内的不同类型的计算框架,只要编程实现相应的ApplicationMaster
  • YARN中的资源管理比MapReduce1.0更加高效
    • 以容器为单位,而不是以slot为单位

YARN的目标就是实现“一个集群多个框架”,为什么?

  • 一个企业当中同时存在各种不同的业务应用场景,需要采用不同的计算框架

    • MapReduce实现离线批处理
    • 使用Impala实现实时交互式查询分析
    • 使用Storm实现流式数据实时分析
    • 使用Spark实现迭代计算
  • 这些产品通常来自不同的开发团队,具有各自的资源调度管理机制
    为了避免不同类型应用之间互相干扰,企业就需要把内部的服务器拆分成多个集群,分别安装运行不同的计算框架,即“一个框架一个集群”

  • 导致问题

    • 集群资源利用率低
    • 数据无法共享
    • 维护代价高
  • YARN的目标就是实现“一个集群多个框架”,即在一个集群上部署一个统一的资源调度管理框架YARN,在YARN之上可以部署其他各种计算框架

  • 由YARN为这些计算框架提供统一的资源调度管理服务,并且能够根据各种计算框架的负载需求,调整各自占用的资源,实现集群资源共享和资源弹性收缩

  • 可以实现一个集群上的不同应用负载混搭,有效提高了集群的利用率

  • 不同计算框架可以共享底层存储,避免了数据集跨集群移动

HDFS的高可用

HDFS的高可用架构

HDFS 1.0存在单点故障问题
第二名称节点(SecondaryNameNode)无法解决单点故障问题
SecondaryNameNode会定期和NameNode通信
从NameNode上获取到FsImage和EditLog文件,并下载到本地的相应目录下
执行EditLog和FsImage文件合并
将新的FsImage文件发送到NameNode节点上
NameNode使用新的FsImage和EditLog(缩小了)
第二名称节点用途:
不是热备份
主要是防止日志文件EditLog过大,导致名称节点失败恢复时消耗过多时间
附带起到冷备份功能

HDFS HA(High Availability)是为了解决单点故障问题
HA集群设置两个名称节点,“活跃(Active)”和“待命(Standby)”
两种名称节点的状态同步,可以借助于一个共享存储系统来实现
一旦活跃名称节点出现故障,就可以立即切换到待命名称节点
Zookeeper确保一个名称节点在对外服务
名称节点维护映射信息,数据节点同时向两个名称节点汇报信息

HDFS Federation架构

  1. HDFS1.0中存在的问题
    单点故障问题
    • 不可以水平扩展(是否可以通过纵向扩展来解决?)
    • 系统整体性能受限于单个名称节点的吞吐量
    • 单个名称节点难以提供不同程序之间的隔离性
    • HDFS HA是热备份,提供高可用性,但是无法解决可扩展性、系统性能和隔离性
  2. HDFS Federation的设计
    • 在HDFS Federation中,设计了多个相互独立的名称节点,使得HDFS的命名服务能够水平扩展,这些名称节点分别进行各自命名空间和块的管理,相互之间是联盟(Federation)关系,不需要彼此协调。并且向后兼容
    • HDFS Federation中,所有名称节点会共享底层的数据节点存储资源,数据节点向所有名称节点汇报
    • 属于同一个命名空间的块构成一个“块池”
  3. HDFS Federation的访问方式
    • 对于Federation中的多个命名空间,可以采用客户端挂载表(Client Side Mount Table)方式进行数据共享和访问
    • 客户可以访问不同的挂载点来访问不同的子命名空间
    • 把各个命名空间挂载到全局“挂载表”(mount-table)中,实现数据全局共享
    • 同样的命名空间挂载到个人的挂载表中,就成为应用程序可见的命名空间
  4. HDFS Federation相对于HDFS1.0的优势
    HDFS Federation设计可解决单名称节点存在的以下几个问题:
    (1)HDFS集群扩展性。多个名称节点各自分管一部分目录,使得一个集群可以扩展到更多节点,不再像HDFS1.0中那样由于内存的限制制约文件存储数目
    (2)性能更高效。多个名称节点管理不同的数据,且同时对外提供服务,将为用户提供更高的读写吞吐率
    (3)良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理,这样不同业务之间影响很小

需要注意的,HDFS Federation并不能解决单点故障问题,也就是说,每个名称节点都存在在单点故障问题,需要为每个名称节点部署一个后备名称节点,以应对名称节点挂掉对业务产生的影响

NoSQL

NoSQL兴起的原因

通常,NoSQL数据库具有以下几个特点:

  • 灵活的可扩展性
  • 灵活的数据模型
  • 与云计算紧密融合

“One size fits all”模式很难适用于截然不同的业务场景

  • 关系模型作为统一的数据模型既被用于数据分析,也被用于在线业务。但这两者一个强调高吞吐,一个强调低延时,已经演化出完全不同的架构。用同一套模型来抽象显然是不合适的
  • Hadoop就是针对数据分析
  • MongoDB、Redis等是针对在线业务,两者都抛弃了关系模型

关系数据库的关键特性包括完善的事务机制和高效的查询机制。但是,关系数据库引以为傲的两个关键特性,到了Web2.0时代却成了鸡肋,主要表现在以下几个方面:
(1)Web2.0网站系统通常不要求严格的数据库事务
(2)Web2.0并不要求严格的读写实时性
(3)Web2.0通常不包含大量复杂的SQL查询(去结构化,存储空间换取更好的查询性能)

传统数据库缺点

传统数据库缺点:

  • 大数据场景下I/O较高
    因为数据是按行存储,即使只针对其中某一列进行运算,关系型数据库也会将整行数 据从存储设备中读入内存,导致I/O较高
  • 存储的是行记录,无法存储数据结构
  • 表结构schema扩展不方便
    如要需要修改表结构,需要执行执行DDL(data definition language),语句修改,修改 期间会导致锁表,部分服务不可用
  • 全文搜索功能较弱
    关系型数据库下只能够进行子字符串的匹配查询,当表的数据逐渐变大的时候,like查 询的匹配会非常慢,即使在有索引的情况下。况且关系型数据库也不应该对文本字段 进行索引
  • 存储和处理复杂关系型数据功能较弱

关系数据库已经无法满足Web2.0的需求。主要表现在以下几个方面:

  • 无法满足海量数据的管理需求

  • 无法满足数据高并发的需求

  • 无法满足高可扩展性和高可用性的需求

  • 复杂性:部署、管理、配置很复杂

  • 数据库复制:MySQL主备之间采用复制方式,只能是异步复制,当主库压力较大时可能产生较大延迟,主备切换可能会丢失最后一部分更新事务,这时往往需要人工介入,备份和恢复不方便

  • 扩容问题:如果系统压力过大需要增加新的机器,这个过程涉及数据重新划分,整个过程比较复杂,且容易出错
    动态数据迁移问题:如果某个数据库组压力过大,需要将其中部分数据迁移出去,迁移过程需要总控节点整体协调,以及数据库节点的配合。这个过程很难做到自动化

比较

比较标准 RDBMS NoSQL 备注
数据库原理 完全支持 部分支持 RDBMS有关系代数理论作为基础 NoSQL没有统一的理论基础
数据规模 超大 RDBMS很难实现横向扩展,纵向扩展的空间也比较有限,性能会随着数据规模的增大而降低 NoSQL可以很容易通过添加更多设备来支持更大规模的数据
数据库模式 固定 灵活 RDBMS需要定义数据库模式,严格遵守数据定义和相关约束条件 NoSQL不存在数据库模式,可以自由灵活定义并存储各种不同类型的数据
查询效率 可以实现高效的简单查询,但是不具备高度结构化查询等特性,复杂查询的性能不尽人意 RDBMS借助于索引机制可以实现快速查询(包括记录查询和范围查询) 很多NoSQL数据库没有面向复杂查询的索引,虽然NoSQL可以使用MapReduce来加速查询,但是,在复杂查询方面的性能仍然不如RDBMS
一致性 强一致性 弱一致性 RDBMS严格遵守事务ACID模型,可以保证事务强一致性 很多NoSQL数据库放松了对事务ACID四性的要求,而是遵守BASE模型,只能保证最终一致性
数据完整性 容易实现 很难实现 任何一个RDBMS都可以很容易实现数据完整性,比如通过主键或者非空约束来实现实体完整性,通过主键、外键来实现参照完整性,通过约束或者触发器来实现用户自定义完整性 但是,在NoSQL数据库却无法实现
扩展性 一般 RDBMS很难实现横向扩展,纵向扩展的空间也比较有限 NoSQL在设计之初就充分考虑了横向扩展的需求,可以很容易通过添加廉价设备实现扩展
可用性 很好 RDBMS在任何时候都以保证数据一致性为优先目标,其次才是优化系统性能,随着数据规模的增大,RDBMS为了保证严格的一致性,只能提供相对较弱的可用性 大多数NoSQL都能提供较高的可用性
标准化 RDBMS已经标准化(SQL) NoSQL还没有行业标准,不同的NoSQL数据库都有自己的查询语言,很难规范应用程序接口 StoneBraker认为:NoSQL缺乏统一查询语言,将会拖慢NoSQL发展
技术支持 RDBMS经过几十年的发展,已经非常成熟,Oracle等大型厂商都可以提供很好的技术支持 NoSQL在技术支持方面仍然处于起步阶段,还不成熟,缺乏有力的技术支持
可维护性 复杂 复杂 RDBMS需要专门的数据库管理员(DBA)维护 NoSQL数据库虽然没有DBMS复杂,也难以维护

总结

(1)关系数据库
优势:以完善的关系代数理论作为基础,有严格的标准,支持事务ACID四性,借助索引机制可以实现高效的查询,技术成熟,有专业公司的技术支持
劣势:可扩展性较差,无法较好支持海量数据存储,数据模型过于死板、无法较好支持Web2.0应用,事务机制影响了系统的整体性能等

(2)NoSQL数据库
优势:可以支持超大规模数据存储,灵活的数据模型可以很好地支持Web2.0应用,具有强大的横向扩展能力等
劣势:缺乏数学理论基础,复杂查询性能不高,大都不能实现事务强一致性,很难实现数据完整性,技术尚不成熟,缺乏专业团队的技术支持,维护较困难等

关系数据库和NoSQL数据库各有优缺点,彼此无法取代
关系数据库应用场景:电信、银行等领域的关键业务系统,需要保证强事务一致性
NoSQL数据库应用场景:互联网企业、传统企业的非关键业务(比如数据分析)

NoSQL数据库虽然数量众多,但是,归结起来,典型的NoSQL数据库通常包括键值数据库、列族数据库、文档数据库和图形数据库

键值数据库

相关产品 Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached
数据模型 键/值对 键是一个字符串对象 值可以是任意类型的数据,比如整型、字符型、数组、列表、集合等
典型应用 涉及频繁读写、拥有简单数据模型的应用 内容缓存,比如会话、配置文件、参数、购物车等 存储配置和用户数据信息的移动应用
优点 扩展性好,灵活性好,大量写操作时性能高
缺点 无法存储结构化信息,条件查询效率较低
不适用情形 不是通过键而是通过值来查:键值数据库根本没有通过值查询的途径 需要存储数据之间的关系:在键值数据库中,不能通过两个或两个以上的键来关联数据 需要事务的支持:在一些键值数据库中,产生故障时,不可以回滚
使用者 百度云数据库(Redis)、GitHub(Riak)、BestBuy(Riak)、Twitter(Redis和Memcached)、StackOverFlow(Redis)、Instagram (Redis)、Youtube(Memcached)、Wikipedia(Memcached)

列族数据库

查询效率高

读取多条数据的同一列效率高,因为这些列都是存储在一起的,一次磁盘操作可以数据的指定列全部读取到内存中。

缺点如下:

  • 不适合扫描小量数据
  • 不适合随机的更新
  • 不适合做含有删除和更新的实时操作
  • 单行的数据是ACID的,多行的事务时,不支持事务的正常回滚,支持 I(Isolation)隔离性(事务串行提交),D(Durability)持久性,不能保证 A(Atomicity)原子性, C(Consistency)一致性
相关产品 BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS
数据模型 列族
典型应用 分布式数据存储与管理 数据在地理上分布于多个数据中心的应用程序 可以容忍副本中存在短期不一致情况的应用程序 拥有动态字段的应用程序 拥有潜在大量数据的应用程序,大到几百TB的数据
优点 查找速度快,可扩展性强,容易进行分布式扩展,复杂性低
缺点 功能较少,大都不支持强事务一致性
不适用情形 需要ACID事务支持的情形,Cassandra等产品就不适用
使用者 Ebay(Cassandra)、Instagram(Cassandra)、NASA(Cassandra)、Twitter(Cassandra and HBase)、Facebook(HBase)、Yahoo!(HBase)

文档数据库

“文档”其实是一个数据记录,这个记录能够对包含的数据类型和内容进行“自我描述”。XML文档、HTML文档和JSON 文档就属于这一类。SequoiaDB就是使用JSON格式的文档数据库,它的存储的数据是这样的:

1
假设这有一个JSON

一个XML文档:

1
2
3
4
5
6
<configuration>
<property>
<name>hbase.rootdir</name>
<value>hdfs://localhost:9000/hbase</value>
</property>
</configuration>
  • 数据是不规则的,每一条记录包含了所有的有关“SequoiaDB”的信息而没有任何外部的引用,这条记录就是“自包含”的
  • 这使得记录很容易完全移动到其他服务器,因为这条记录的所有信息都包含在里面了,不需要考虑还有信息在别的表没有一起迁移走
  • 同时,因为在移动过程中,只有被移动的那一条记录(文档)需要操作,而不像关系型中每个有关联的表都需要锁住来保证一致性,这样一来ACID的保证就会变得更快速,读写的速度也会有很大的提升
相关产品 MongoDB、CouchDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit
数据模型 键/值 值(value)是版本化的文档
典型应用 存储、索引并管理面向文档的数据或者类似的半结构化数据 比如,用于后台具有大量读写操作的网站、使用JSON数据结构的应用、使用嵌套结构等非规范化数据的应用程序
优点 性能好(高并发),灵活性高,复杂性低,数据结构灵活 提供嵌入式文档功能,将经常查询的数据存储在同一个文档中 既可以根据键来构建索引,也可以根据内容构建索引
缺点 缺乏统一的查询语法
不适用情形 在不同的文档上添加事务。文档数据库并不支持文档间的事务,如果对这方面有需求则不应该选用这个解决方案
使用者 百度云数据库(MongoDB)、SAP (MongoDB)、Codecademy (MongoDB)、Foursquare (MongoDB)、NBC News (RavenDB)

图形数据库

相关产品 Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB
数据模型 图结构
典型应用 专门用于处理具有高度相互关联关系的数据,比较适合于社交网络、模式识别、依赖分析、推荐系统以及路径寻找等问题
优点 灵活性高,支持复杂的图形算法,可用于构建复杂的关系图谱
缺点 复杂性高,只能支持一定的数据规模
使用者 Adobe(Neo4J)、Cisco(Neo4J)、T-Mobile(Neo4J)

不同类型数据库比较分析

MySQL产生年代较早,而且随着LAMP大潮得以成熟。尽管其没有什么大的改进,但是新兴的互联网使用的最多的数据库

MongoDB是个新生事物,提供更灵活的数据模型、异步提交、地理位置索引等五花十色的功能

HBase依仗着Hadoop的生态环境,可以有很好的扩展性。需要Hadoop,才能驱使他

Redis是键值存储的代表,功能最简单。提供随机数据存储。但是也正是因此,它的伸缩性特别好。

云数据库的特性

云数据库具有以下特性:
(1)动态可扩展
(2)高可用性
(3)较低的使用代价
(4)易用性
(5)高性能
(6)免维护
(7)安全

企业类型不同,对于存储的需求也千差万别,而云数据库可以很好地满足不同企业的个性化存储需求:
首先,云数据库可以满足大企业的海量数据存储需求
其次,云数据库可以满足中小企业的低成本数据存储需求
另外,云数据库可以满足企业动态变化的数据存储需求

到底选择自建数据库还是选择云数据库,取决于企业自身的具体需求
对于一些大型企业,目前通常采用自建数据库
对于一些财力有限的中小企业而言,IT预算比较有限,云数据库这种前期零投入、后期免维护的数据库服务,可以很好满足它们的需求

从数据模型的角度来说,云数据库并非一种全新的数据库技术,而只是以服务的方式提供数据库功能
云数据库并没有专属于自己的数据模型,云数据库所采用的数据模型可以是关系数据库所使用的关系模型(微软的SQL Azure云数据库、阿里云RDS都采用了关系模型),也可以是NoSQL数据库所使用的非关系模型(Amazon Dynamo云数据库采用的是“键/值”存储)
同一个公司也可能提供采用不同数据模型的多种云数据库服务
许多公司在开发云数据库时,后端数据库都是直接使用现有的各种关系数据库或NoSQL数据库产品