数据库发展

简单来说，数据库的发展是跟随数据量的发展来发展的，最开始的时候LAMP已经足够使用，当海量大数据出现后，如何存储和查询这些数据就成了人们考虑的问题，这时候人们自然想到从两方面入手：

硬件

1. 增加单机性能，加CPU加内存，也就是垂直扩展，但是提升有限
2. 改用主备，增加读性能，写性能存在同步锁问题
3. 分库分表，也就是水平扩展

软件

1. 优化索引，减少查询
2. 缓存查询结果
3. 反范式，快速查询

这些手段在一段时间内满足了要求，但是扩展性、易用性、性能等诸多方面都存在较大问题，这时候人们开始思考关系数据库的本质和提升的可能。

关系数据库(RDBMS)需要如下四点要求(ACID):

原子性(Atomicity A)

事务操作的成功失败标准，比如汇钱，一个账号取钱另一个账号收钱，整个过程是最小化单元，不能中断

一致性(Consistency C)

不同用户同一时刻看到的数据一致，也就是事务操作前后的逻辑不能变，比如两个人的总余额固定，转账过程中的中间结果别人是看不到的，能看到的只有一致性的数据

独立性(Isolation I)

事务操作过程中，不同事务的操作中间和结果如何相关影响，这涉及到不同的隔离级别，比如常见的读已提交和重复读

持久性(Durability D)

事务修改保存在磁盘上，宕机也不会丢失

ACID主要依赖事务，这就带来了诸多限制，比如多行事务原子性保证涉及到整个分布式集群锁住的问题，这完全丧失了分布式的优点，因此分布式可扩展数据库可从如下两个方面入手：

NoSQL

NoSQL，指的是非关系型的数据库。NoSQL有时也称作Not Only SQL的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称。
NoSQL其实就是弱化了了ACID的一些特性，来获得其他方面的提升，需要满足CAP理论：

一致性(Consistency) (不同机器访问一致，即所有节点在同一时间具有相同的数据)
可用性(Availability) (客户端总是可以读写，即保证每个请求不管成功或者失败都有响应)
分隔容忍(Partition tolerance) (分到多个机器形成多个分区，即使网络故障依然可以工作，即系统中任意信息的丢失或失败不会影响系统的继续运作)

对应关系数据库的事务级别，这里的一致性也分为几个等级：

严格一致性必须更新主节点时锁定副本
因果一致性因果相关操作必须串行化
弱一致性(最终一致性) 更新最终会传播到所有节点，中间会出现不同步

CAP指出一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。因此，根据CAP原理将NoSQL数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类：

CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
简单来说，实际使用中我们可以通过适当降低一个特性来增加强其他特性，如下：

这里CA也就是对应传统关系数据库，网络发生分裂时，主节点被剥离，无法正常工作。NoSQL常用的是实际P固定，可选C或A。

可以看到这里，Cassandar强调AP，因此一致性没那么好，满足最终一致性，但是写入性能非常高，常用和Spark等配合实施写入，目前国外NoSQL排名第一；MongoDB/HBase/Redis等强调CP，因此相对来说写入性能没那么好(相对来说，比关系数据库还是高很多)，但是一致性非常好，对于消息系统、订单系统等场合是必须的。

Sharding-nothing

原则就是按照一定的规则将数据分片互不相干的部分，这样减少资源访问的冲突，加快速度，基本上分布式的数据库都要使用这种原则，比如Hbase/Cassandra的Rowkey，MongoDB的分片等等，常用的分片原则如下：

1.功能或特性，比如博客的文章、评论、点赞分别管理
2.键值拆分，比如hash值或时间
3.一个统一的管理节点或目录，通过查表快速定位数据

基于这个原则，人们还对传统的关系数据库进行改造，最有名的就是基于PostgreSQL改造的GreenPlum，依赖MPP架构(即大规模并行处理-Massively Parallel Processor)，通过多个Segmen并行工作，达到极高的查询速度。

存储选型

有了前面的历史背景描述，再来看大数据存储选型会简单很多，主要从如下几个方面展开：

数据存储空间和存储记录数
并发访问量
写入、查询速度
分析的复杂程度(对二级索引、事务、join的支持)
成本

首先数据规模限制了如何存储的问题，海量数据关系数据库肯定存不下，常见的数据库和对应的数据量级简单列如下:

Mysql 百GB
PostgreSQL TB
MongoDB TB
GreenPlum 百TB
Hbase、Cassandra 千TB~PB

再就是考虑并发量和速度，这其实也和查询复杂度相关，总之记住大数据组件肯定都是牺牲某一方面的特性来满足其他特性的提升，整个是一个取舍的问题，常见的几个大数据存储特征如下：

MongoDB 并发量和速度和传统mysql没区别，也支持ACID(支持复杂查询)，但是存储量限制在那，得益于无模式和自动扩容的设计，常用做项目前期替代mysql做快速迭代
Hbase/Cassandra，并发访问都可达千万QPS，速度也非常快，适合OLTP，但是基于行键的设计没法支持复杂查询，当然有各种各样的针对此的解决方法，但是那只是为了处理需求来设计的，并不是他们擅长的
GreenPlum 对于海量数据分析非常快，非常适合做OLAP，但是MPP的架构压力都在Master上，并发访问无法提升，可以和HBase/Cassandra配合使用

原创，转载请注明来自

博客https://blog.csdn.net/wenzhou1219
个人网站http://jimwen.net/

1.大数据存储选型——何时用hbase相关推荐

云时代的大数据存储-云HBase
纵观数据库发展的几十年,从网状数据库.层次数据库到RDBMS数据库,在最近几年的NewSQL的兴起,加上开源的运动,再加上云的特性,可以说是日新月异.在20世纪80年代后,大部分的业务确定了使用RDB ...
基于HBase的大数据存储在京东的应用场景
引言 HBase是一个高可靠性.高性能.面向列.可伸缩的分布式存储系统,适用于结构化的存储,底层依赖于Hadoop的HDFS,利用HBase技术可在廉价PCServer上搭建起大规模结构化存储集群.因 ...
三、大数据存储——HBase
目录一.NOSQL引入 1.1.NoSQL数据库简介 1.2.混合持久化 1.3.数据模型的转变 2.HBASE 2.1.Hbase是什么 2.2.Hbase实践 2.3.HBase列式存储模型 2 ...
大数据架构选型与设计
大数据架构选型与设计 1.1 如何构建大数据平台? 1.1.1 数据库与ER建模 1.1.1.1 数据库(DataBase) 数据库是按照数据结构来组织.存储和管理数据的仓库,是一个长期存储在计算机内 ...
深入浅出大数据存储架构，如何设计才能满足需求？
"与数据同行"开通了微信群,现已汇聚了4000位小伙伴了,加我为微信好友(微信号:fuyipingmnb)申请入群,让我们共建一个数据社区,<与数据同行>致力于为您提供 ...
大数据数据库选型：NoSQL数据库入门
大数据处理,涉及到从数据获取到数据存储.数据计算的诸多环节,各个环节需要解决的问题不同,相关岗位要求的技能也不同.在数据存储阶段,对数据库选型是非常重要的一项工作.今天的大数据数据库培训分享,我们就来 ...
万亿级日志与行为数据存储查询技术剖析——Hbase系预聚合方案、Dremel系parquet列存储、预聚合系、Lucene系...
转自:http://www.infoq.com/cn/articles/trillion-log-and-data-storage-query-techniques?utm_source=infoq& ...
面向智能电网的电力大数据存储与分析应用
面向智能电网的电力大数据存储与分析应用崔立真1, 史玉良1, 刘磊1, 赵卓峰2, 毕艳冰3 1. 山东大学计算机科学与技术学院,山东济南 250101 2. 北方工业大学云计算研究中心,北京 1 ...
【2022持续更新】大数据最全知识点整理-HBase篇
大数据最全知识点整理-HBase篇基础问题: 1.Hbase是什么 2.Hbase架构 3.Hbase数据模型 4.Hbase和hive的区别 5.Hbase特点 6.数据同样存在HDFS,为什么H ...

1.大数据存储选型——何时用hbase

数据库发展

NoSQL

Sharding-nothing

存储选型

1.大数据存储选型——何时用hbase相关推荐

最新文章

热门文章