为什么说hbase是一个面向列的数据库

为什么说hbase是一个面向列的数据库,第1张

在说HBase之前,我想再唠叨几句。做互联网应用的哥们儿应该都清楚,互联网应用这东西,你没办法预测你的系统什么时候会被多少人访问,你面临的用户到底有多少,说不定今天你的用户还少,明天系统用户就变多了,结果您的系统应付不过来了了,不干了,这岂不是咱哥几个的悲哀,说时髦点就叫“杯具啊”。\x0d\\x0d\其实说白了,这些就是事先没有认清楚互联网应用什么才是最重要的。从系统架构的角度来说,互联网应用更加看重系统性能以及伸缩性,而传统企业级应用都是比较看重数据完整性和数据安全性。那么我们就来说说互联网应用伸缩性这事儿对于伸缩性这事儿,哥们儿我也写了几篇博文,想看的兄弟可以参考我以前的博文,对于web server,app server的伸缩性,我在这里先不说了,因为这部分的伸缩性相对来说比较容易一点,我主要来回顾一些一个慢慢变大的互联网应用如何应对数据库这一层的伸缩。\x0d\\x0d\首先刚开始,人不多,压力也不大,搞一台数据库服务器就搞定了,此时所有的东东都塞进一个Server里,包括web server,app server,db server,但是随着人越来越多,系统压力越来越多,这个时候可能你把web server,app server和db server分离了,好歹这样可以应付一阵子,但是随着用户量的不断增加,你会发现,数据库这哥们不行了,速度老慢了,有时候还会宕掉,所以这个时候,你得给数据库这哥们找几个伴,这个时候Master-Salve就出现了,这个时候有一个Master Server专门负责接收写 *** 作,另外的几个Salve Server专门进行读取,这样Master这哥们终于不抱怨了,总算读写分离了,压力总算轻点了,这个时候其实主要是对读取 *** 作进行了水平扩张,通过增加多个Salve来克服查询时CPU瓶颈。一般这样下来,你的系统可以应付一定的压力,但是随着用户数量的增多,压力的不断增加,你会发现Master server这哥们的写压力还是变的太大,没办法,这个时候怎么办呢?你就得切分啊,俗话说“只有切分了,才会有伸缩性嘛”,所以啊,这个时候只能分库了,这也是我们常说的数据库“垂直切分”,比如将一些不关联的数据存放到不同的库中,分开部署,这样终于可以带走一部分的读取和写入压力了,Master又可以轻松一点了,但是随着数据的不断增多,你的数据库表中的数据又变的非常的大,这样查询效率非常低,这个时候就需要进行“水平分区”了,比如通过将User表中的数据按照10W来划分,这样每张表不会超过10W了。\x0d\\x0d\综上所述,一般一个流行的web站点都会经历一个从单台DB,到主从复制,到垂直分区再到水平分区的痛苦的过程。其实数据库切分这事儿,看起来原理貌似很简单,如果真正做起来,我想凡是sharding过数据库的哥们儿都深受其苦啊。对于数据库伸缩的文章,哥们儿可以看看后面的参考资料介绍。\x0d\\x0d\好了,从上面的那一堆废话中,我们也发现数据库存储水平扩张scale out是多么痛苦的一件事情,不过幸好技术在进步,业界的其它弟兄也在努力,09年这一年出现了非常多的NoSQL数据库,更准确的应该说是No relation数据库,这些数据库多数都会对非结构化的数据提供透明的水平扩张能力,大大减轻了哥们儿设计时候的压力。下面我就拿Hbase这分布式列存储系统来说说。\x0d\\x0d\一 Hbase是个啥东东? \x0d\在说Hase是个啥家伙之前,首先我们来看看两个概念,面向行存储和面向列存储。面向行存储,我相信大伙儿应该都清楚,我们熟悉的RDBMS就是此种类型的,面向行存储的数据库主要适合于事务性要求严格场合,或者说面向行存储的存储系统适合OLTP,但是根据CAP理论,传统的RDBMS,为了实现强一致性,通过严格的ACID事务来进行同步,这就造成了系统的可用性和伸缩性方面大大折扣,而目前的很多NoSQL产品,包括Hbase,它们都是一种最终一致性的系统,它们为了高的可用性牺牲了一部分的一致性。好像,我上面说了面向列存储,那么到底什么是面向列存储呢?Hbase,Casandra,Bigtable都属于面向列存储的分布式存储系统。看到这里,如果您不明白Hbase是个啥东东,不要紧,我再总结一下下:\x0d\\x0d\Hbase是一个面向列存储的分布式存储系统,它的优点在于可以实现高性能的并发读写 *** 作,同时Hbase还会对数据进行透明的切分,这样就使得存储本身具有了水平伸缩性。\x0d\\x0d\二 Hbase数据模型 \x0d\HBase,Cassandra的数据模型非常类似,他们的思想都是来源于Google的Bigtable,因此这三者的数据模型非常类似,唯一不同的就是Cassandra具有Super cloumn family的概念,而Hbase目前我没发现。好了,废话少说,我们来看看Hbase的数据模型到底是个啥东东。\x0d\\x0d\在Hbase里面有以下两个主要的概念,Row key,Column Family,我们首先来看看Column family,Column family中文又名“列族”,Column family是在系统启动之前预先定义好的,每一个Column Family都可以根据“限定符”有多个column下面我们来举个例子就会非常的清晰了。\x0d\\x0d\假如系统中有一个User表,如果按照传统的RDBMS的话,User表中的列是固定的,比如schema 定义了name,age,sex等属性,User的属性是不能动态增加的。但是如果采用列存储系统,比如Hbase,那么我们可以定义User表,然后定义info 列族,User的数据可以分为:info:name = zhangsan,info:age=30,info:sex=male等,如果后来你又想增加另外的属性,这样很方便只需要info:newProperty就可以了。\x0d\\x0d\也许前面的这个例子还不够清晰,我们再举个例子来解释一下,熟悉SNS的朋友,应该都知道有好友Feed,一般设计Feed,我们都是按照“某人在某时做了标题为某某的事情”,但是同时一般我们也会预留一下关键字,比如有时候feed也许需要url,feed需要image属性等,这样来说,feed本身的属性是不确定的,因此如果采用传统的关系数据库将非常麻烦,况且关系数据库会造成一些为null的单元浪费,而列存储就不会出现这个问题,在Hbase里,如果每一个column 单元没有值,那么是占用空间的。下面我们通过两张图来形象的表示这种关系:\x0d\\x0d\上图是传统的RDBMS设计的Feed表,我们可以看出feed有多少列是固定的,不能增加,并且为null的列浪费了空间。但是我们再看看下图,下图为Hbase,Cassandra,Bigtable的数据模型图,从下图可以看出,Feed表的列可以动态的增加,并且为空的列是不存储的,这就大大节约了空间,关键是Feed这东西随着系统的运行,各种各样的Feed会出现,我们事先没办法预测有多少种Feed,那么我们也就没有办法确定Feed表有多少列,因此Hbase,Cassandra,Bigtable的基于列存储的数据模型就非常适合此场景。说到这里,采用Hbase的这种方式,还有一个非常重要的好处就是Feed会自动切分,当Feed表中的数据超过某一个阀值以后,Hbase会自动为我们切分数据,这样的话,查询就具有了伸缩性,而再加上Hbase的弱事务性的特性,对Hbase的写入 *** 作也将变得非常快。\x0d\\x0d\上面说了Column family,那么我之前说的Row key是啥东东,其实你可以理解row key为RDBMS中的某一个行的主键,但是因为Hbase不支持条件查询以及Order by等查询,因此Row key的设计就要根据你系统的查询需求来设计了额。我还拿刚才那个Feed的列子来说,我们一般是查询某个人最新的一些Feed,因此我们Feed的Row key可以有以下三个部分构成,这样以来当我们要查询某个人的最进的Feed就可以指定Start Rowkey为,End Rowkey为来查询了,同时因为Hbase中的记录是按照rowkey来排序的,这样就使得查询变得非常快。\x0d\\x0d\三 Hbase的优缺点 \x0d\1 列的可以动态增加,并且列为空就不存储数据,节省存储空间\x0d\\x0d\2 Hbase自动切分数据,使得数据存储自动具有水平scalability\x0d\\x0d\3 Hbase可以提供高并发读写 *** 作的支持\x0d\\x0d\Hbase的缺点:\x0d\\x0d\1 不能支持条件查询,只支持按照Row key来查询\x0d\\x0d\2 暂时不能支持Master server的故障切换,当Master宕机后,整个存储系统就会挂掉\x0d\\x0d\四补充\x0d\1数据类型,HBase只有简单的字符类型,所有的类型都是交由用户自己处理,它只保存字符串。而关系数据库有丰富的类型和存储方式。\x0d\2数据 *** 作:HBase只有很简单的插入、查询、删除、清空等 *** 作,表和表之间是分离的,没有复杂的表和表之间的关系,而传统数据库通常有各式各样的函数和连接 *** 作。 \x0d\3存储模式:HBase是基于列存储的,每个列族都由几个文件保存,不同的列族的文件时分离的。而传统的关系型数据库是基于表格结构和行模式保存的 \x0d\4数据维护,HBase的更新 *** 作不应该叫更新,它实际上是插入了新的数据,而传统数据库是替换修改\x0d\5可伸缩性,Hbase这类分布式数据库就是为了这个目的而开发出来的,所以它能够轻松增加或减少硬件的数量,并且对错误的兼容性比较高。而传统数据库通常需要增加中间层才能实现类似的功能

int sa[M][N];

存储顺序是

| sa[0][0] | sa[0][1] | sa[0][2] | | sa[0][N-1]|

| sa[1][0] | sa[1][1] sa[1][N-1]|

|sa[M-1][0] | sa[M-1][N-1]|

关系型数据库,是指采用了关系模型来组织数据的数据库,其以行和列的形式存储数据,以便于用户理解,关系型数据库这一系列的行和列被称为表,一组表组成了数据库。

用户通过查询来检索数据库中的数据,而查询是一个用于限定数据库中某些区域的执行代码。

关系模型可以简单理解为二维表格模型,而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组织。

扩展资料:

关系型数据库特点:

1、存储方式:传统的关系型数据库采用表格的储存方式,数据以行和列的方式进行存储,要读取和查询都十分方便。

2、存储结构:关系型数据库按照结构化的方法存储数据,每个数据表都必须对各个字段定义好,再根据表的结构存入数据,这样做的好处就是由于数据的形式和内容在存入数据之前就已经定义好了,所以整个数据表的可靠性和稳定性都比较高。

3、存储规范:关系型数据库为了避免重复、规范化数据以及充分利用好存储空间,把数据按照最小关系表的形式进行存储,这样数据管理的就可以变得很清晰、一目了然,当然这主要是一张数据表的情况。

4、扩展方式:由于关系型数据库将数据存储在数据表中,数据 *** 作的瓶颈出现在多张数据表的 *** 作中,而且数据表越多这个问题越严重,如果要缓解这个问题,只能提高处理能力,也就是选择速度更快性能更高的计算机。

5、查询方式:关系型数据库采用结构化查询语言来对数据库进行查询,SQL早已获得了各个数据库厂商的支持,成为数据库行业的标准,它能够支持数据库的CRUD *** 作,具有非常强大的功能,SQL可以采用类似索引的方法来加快查询 *** 作。

6、规范化:在数据库的设计开发过程中开发人员通常会面对同时需要对一个或者多个数据实体进行 *** 作,这样在关系型数据库中,一个数据实体一般首先要分割成多个部分,然后再对分割的部分进行规范化,规范化以后再分别存入到多张关系型数据表中,这是一个复杂的过程。

7、事务性:关系型数据库强调ACID规则(原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)),可以满足对事务性要求较高或者需要进行复杂数据查询的数据 *** 作,而且可以充分满足数据库 *** 作的高性能和 *** 作稳定性的要求。

8、读写性能:关系型数据库十分强调数据的一致性,并为此降低读写性能付出了巨大的代价,虽然关系型数据库存储数据和处理数据的可靠性很不错,但一旦面对海量数据的处理的时候效率就会变得很差,特别是遇到高并发读写的时候性能就会下降的非常厉害。

9、授权方式:关系型数据库常见的有 Oracle,SQLServer,DB2,Mysql,除了Mysql大多数的关系型数据库如果要使用都需要支付一笔价格高昂的费用,即使是免费的Mysql性能也受到了诸多的限制。

二元表 关系数据库是指使用关系模型组织数据的数据库。它以行和列的形式存储数据,方便用户理解。关系数据库的一系列行和列称为表,一组表构成了数据库。用户通过查询来检索数据库中的数据,而查询是用来限制数据库中某些区域的执行代码。关系模型可以简单理解为二维表模型,关系数据库是由二维表及其关系组成的数据组织。主流的关系数据库有Oracle、DB2、MySQL、Microsoft SQL Server、Microsoft Access等,每个数据库在语法、功能、特点上都有自己的特点。甲骨文数据库由甲骨文公司开发,于1989年正式进入中国市场。Oracle虽然当时名不见经传,但是通过多年的发展积累了很多领先的数据库系统开发经验,在集群技术、高可用性、安全性、系统管理等方面都取得了不错的成绩。除了数据库系统,Oracle产品还包括应用系统和开发工具。在数据库 *** 作平台上,Oracle可以运行在所有的主流平台上,所以在稳定性高的 *** 作系统平台上运行可以提高整个数据库系统的稳定性。

以上就是关于为什么说hbase是一个面向列的数据库全部的内容,包括:为什么说hbase是一个面向列的数据库、数据结构,二维数组sa中,按行存放和按列存放的某元素地址的计算方法有什么不同,举个例子。、关系型数据库的常见功能等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9391300.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-27
下一篇 2023-04-27

发表评论

登录后才能评论

评论列表(0条)

保存