思行合一,体验实现

律政俏佳人2这部多年前看过片子我已经记不清其中的情节了,但是这么多年来让我记在心中的是片尾Elle在国会的演讲里剪头发那个比喻。嫌头发剪的不好看?经常发生的情况是你就坐在那里,眼睁睁的看着发生的事,就让它发生了。生活工作中何尝不是常见此场景,抱怨不断,但是什么都没做,只是眼睁睁就看着它发生了,为什么不行动起来,做点什么呢?

多年后再读一遍全文,有更多的感受。

Elle Woods’ Speech:

      Thank you, congress madam.

      Hello everyone! My name is Elle Woods, and I’m here to speak to you today about a piece of legislation called Bruiser’s bill.

      But you know, today is supposed to be by education. So instead I wanna tell you about the education you all have given to me of the past 3 months. See one day, I came to Washington to help my dog Bruiser and someone along the way I’ve learned a really unexpective lesson. I know you were thinking, Who is this girl? And what could this simple small town girl from Barelare have to say to all of us? Well, I’ll tell you. It’s about something that bigger than me or any single active legislation, this is about a matter that should be of the highest importance to every America- My hair.

      You see there is a salon in Barbalyhouse, it’s really fancy and beautiful, but it’s impossible to get an appointment, I mean unless you join your robots so one of the girls is your friends or you can just forget it. But one day, they called me, they had an opening, so I was gonna finally to get a chance to sit in one of those secret beauty chairs, I was so excited. Then the colorist give me breathlessly brazen instead of hair-look honey, the shampoo girl, wash my hair with perm solution instead of color intensive moisture strengthen conditioning shampoo, finally the stylist give me a bob, with bangs. Suppose to say, I was just wrong, all wrong, for me, you know? First I was angry, and then I realize my anger was complete misrouted, I mean, this wasn’t the salon’s fault, I had sat there and witness this injustice, and I just let it happen. I didn’t get involved in the process. I forgot to use my voice. I forgot to believe in myself. But now I know better. I know that one honest voice can be louder than a crow, I know that if we lose our voice, or we let those who speak on our behalf compromise our voice, well then this country, this country is infer a really bad hair cut. So speak up America, speak up! Speak up for the home of the brave; speak up for the land has the free gifts with purchase, Speak up America, Speak up!

       And remember, you are beautiful!

      Thank you.

谢谢你们,国会的女士
各位好!我是ELLE WOODS,我今天来这里是讲述给大家被称为Bruiser’s bill的一条法规。
各位知道,今天的社会是通过教育实现的.所以我想给各位讲述过去3个月你们给我的教育.
一天,我来华盛顿帮助我的狗狗Bruiser和我学到的没有预料到的一课.
我知道你们一定正在想,这个女孩是谁呢?这个来自BARELARE小镇的女孩会对我们说什么呢?
好的,我来告诉大家,它是关于比我或是任何单一积极的法规大许多,这是有关对每个美国人都最为重要的一件事情.
你们知道在BARBALYHOUSE有一个沙龙,它是非常有魔力的,不过要预约到他们的服务是很难的,除非你加入到明星们的行列中或是你能够忘记它。
然而有一天,他们对我开放了,我最终能得到机会坐到这些秘密而漂亮的椅子上,我异常兴奋。
接下来理发师把我的头发弄成屏息状以及黄铜色的头发,而不是我头发真正的蜂蜜颜色。洗头的女孩用烫发洗液为我洗头发而不是用护发素,最后发型师给我剪了一头短发,像邦士一般可笑。
我猜想,我错了,完全错了,你们明白吗?首先我生气了,
然后我意识到我的气愤是被误导了,我明白了,这不是沙龙的错
我坐在那里,眼睁睁的看着发生的事,就让它发生了。
我没能身处其中,我忘了使用发言权,忘了自信。我知道一个诚实的声音要比咯咯笑更响亮,
我知道 如果我们丧失自己的声音,或是我们让那些代表我们发言的人使得我们的声音妥协,
那么这个国家,一定是糟糕的发型。所以 大声说 美国,大声点!为了勇敢的祖国,为了土地有购买礼物的自由,大声说 美国,大声说!
记住,你是最美丽的!
Thank you.

 

国产列式数据库GBASE 8a 集群版评测(2)

上一篇介绍了GBASE 8a 的技术特点,本篇主要介绍其安装及使用。

首先这个安装需求就有点蛋疼,

同一网段?大规模的集群系统还真是没见过有这种要求的,同一网段应该还是出于进行机器间广播通信的考虑?但是要求同一网段就事实上限制了集群的规模,对集群的扩展和维护造成麻烦。

同样的操作系统??这个和集群有何关系?应该是要求集群上各台机器应用程序版本一致吧。如果安装包和操作系统版本相关,应提示用户根据系统版本选择不同的安装包,更妥当的是安装程序根据操作系统版本自动选择。

各台机器的root密码一致,这个更晕,如果是使用动态密码等的肿么办,业界上也只是要求各个用户配好机器间信任,做好无密码互访即可,貌似是出于方便用户的考虑,提供root密码就可以自动安装,但是实际部署中还是会遇到问题。

要求各节点关闭防火墙??与其这样不如公布需要开放的端口,关闭防火墙是对企业安全策略的彻底挑战,如此设计其实也体现了对数据安全问题的不重视。

要求节点上不存在gbase用户??程序还绑定用户名,不允许自定义安装用户??程序里面写死了?但是其实在后面的安装步骤中,gbase的用户又是可配置的,文档又出现不一致。

上面这些问题看着都不大,但是魔鬼总在细节中,这些细节就体现了产品的开发风格,而且现在总写文档是低级的事情,都是让初级人员写,但是注意细节也是实力的体现。

安装很简单,设置好配置文件,我打算安装在3台机器上。

[root@RHELDN1 gcinstall]# cat demo.options

authkey_file_name = authkey.demo

gcluster_dba_group = gbase

gcluster_dba_user = gbase

gcluster_dba_user_password = gbase

hosts = 172.16.130.227,172.16.130.223,172.16.130.231

mcast_addr = 226.94.1.99

mcast_port = 5479

root_password = root123

source = 172.16.130.227

skip_network_test = true

然后执行 ./gcinstall.py –silent=demo.options 就开始安装了。过程很简单,等着就好。

安装完后发现配置系统内核参数的/etc/sysctl.conf 被整个替换了,我原先的内核参数配置全没了,这个真是有点狂汗。重要的系统内核参数必须让用户来修改,用户的是生产系统,而且很可能是与其他服务共用的服务器。如果内核参数不满足需求可以提示用户修改,整个文件用安装包中的无声无息覆盖的做法这个就有点过度了。而且文档中或者安装过程中没有任何的说明或者警告,要不是我看见了,就要等到其他应用莫名报错才知道了。

节点安装完毕后,下一步是建立safegroup,因为安全组之内的服务器为主备,所以我打算3个节点,分成3个安全组。这样比较能发挥出性能的优势。

 gcadmin addsg –nodes 172.16.130.227 –names node1

gcadmin addsg –nodes 172.16.130.231 –names node2

gcadmin addsg –nodes 172.16.130.223 –names node3

 

ok,3个节点,3个safegourp,服务一切正常,现在可以开始使用数据库啦。

使用gbase用户,执行一下命令就可以登录到数据库

/opt/gcluster/server/bin/gbase -ugbase -pgbase20110531 -h127.0.0.1 -P5258

文档中特地注明,用户名固定为gbase,密码固定为gbase20110531,在安装的时候不让人设置用户名和密码就算了,居然连密码都不让改,头一次见。翻遍文档也没看见改密码说明,这是赤裸裸的数据不设防啊。数据安全如何保证??

界面看着很眼熟?没错,这就是mysql的界面,只是mysql替换成gbase了,再看看下面两张图,熟悉mysql的同志一看就明白哈。

言归正传,不管gbase与mysql渊源如何,还是回到我们测试上,下一步是建立用户自己的database pocdb,并建立一张分布表,先熟悉下操作。

 

gbase> create database pocdb;

Query OK, 0 rows affected (Elapsed: 00:00:00.18)

gbase> use pocdb;

Query OK, 0 rows affected (Elapsed: 00:00:00.01)

gbase> CREATE TABLE hive_test (id int, name varchar(200)) DISTRIBUTED BY(‘id’);

Query OK, 0 rows affected (Elapsed: 00:00:00.16)

gbase> exit

Bye

下面准备利用自带的工具进行文本入库,按照文档要去建立了配置文件

[test_t]

disp_server=172.16.130.227:6666

file_list=/home/gbase/part-m-00000

format=0

node_list=node1,node2,node3

disp_type=1

hash=CRC32

hash_column=0

db_user=gbase

db_name=demodb

table_name=hive_test

delimiter=’\001′

socket=/tmp/gbase_8a_5050.sock

extra_loader_args=–parallel=3

我最近在做hadoop测试的时候生成了一个文本,刚好拿来做测试,字段的分隔符是hive的默认分隔符\001 也就是ctrl+A那个符号。在加载前需要先启动分发服务器

./dispserver –log-file=/root/gb8a/dispatch_server.log –port=6666

这个又有个蛋疼的地方,端口不可修改。。。软件的一切设置都需要配置化,这个不是很基本的要求么?动不动就写死的做法是在不可取。

[gbase@RHELDN1 ~]$ ./dispcli t.tpl

[2012-09-26 14:33:36] ERROR: “disp_type” is NOT a valid argument! (/home/gbase/dispserver/dispcli/dispcli_app.cpp:114)

刚一执行就报错,我很确信我没写错,我是copy过来的。。

  #分发类型:0 为复制;1 为分布

disp_type=1 #

这个有点囧,既然报不认识自家参数,那我就注释掉这个好了。注释后继续执行。。

[gbase@RHELDN1 ~]$ ./dispcli t.tpl

Start mission [test_t] in dispatch mode…

[172.16.130.223] [START TIME: 1970-01-01 7:0:0] [100.00%] [RATE: 0.00/s] [ERROR] [BAD REC: 0] [ETA: 0 sec] [ELAPSED: 15609 days 6 hours 38 min 6 secs]

[172.16.130.227] [START TIME: 1970-01-01 7:0:0] [100.00%] [RATE: 0.00/s] [ERROR] [BAD REC: 0] [ETA: 0 sec] [ELAPSED: 15609 days 6 hours 38 min 6 secs]base/disp

[172.16.130.231] [START TIME: 1970-01-01 7:0:0] [100.00%] [RATE: 0.00/s] [ERROR] [BAD REC: 0] [ETA: 0 sec] [ELAPSED: 15609 days 6 hours 38 min 6 secs]

[gbase@RHELDN1 ~]$ echo $?

0

两G多的文件,不到5秒钟就完了,而且这个提示,看看开始时间,和耗时。。。瀑布汗啊,中间闪过一个提示说出错了,需要看gbloader的日志,日志在哪???路径也没提示,而且程序退出的时候连那个出错提示都没了?屏幕上的那日期是怎么回事,而且程序报错了程序的返回码还是0?这让作业调度程序情何以堪。去数据库看了看,果然,文件没有加载进去。

哪报错了,为什么,完全没头绪,当前文件下是空的,没有任何日志文件,/var/log下面也没有,后来在/tmp下找到一个日志文件dispcli.log,

2012-09-26 14:38:02 INFO: DONE (/home/gbase/dispserver/dispcli/loader_agent.cpp:252) 2012-09-26 14:38:03 Sending 37 : get_progress dispatch_id=8 vfile_id=0 (/home/gbase/dispserver/dispcli/disp_server_agent.cpp:556)

2012-09-26 14:38:03 Received 4 : +OK  (/home/gbase/dispserver/dispcli/disp_server_agent.cpp:603)

2012-09-26 14:38:04 Sending 37 : get_progress dispatch_id=8 vfile_id=0 (/home/gbase/dispserver/dispcli/disp_server_agent.cpp:556)

2012-09-26 14:38:04 Received 4 : +OK  (/home/gbase/dispserver/dispcli/disp_server_agent.cpp:603) 2012-09-26 14:38:04 We read from 172.16.130.227 [STDERR]: (/home/gbase/dispserver/dispcli/loader_agent.cpp:347)

2012-09-26 14:38:04 Parameter error. Delimiter input error.  (/home/gbase/dispserver/dispcli/loader_agent.cpp:348)

我截取了日志文件中的一段,这个日志应该是给开发人员调试看的,完全不像一个产品面向用户的日志。里面都是一些对终端用户毫无价值的东西。终于从其中的(Parameter error. Delimiter input error. )看出点门道,应该是分隔符的问题,估计是不支持ctrl+a这种特殊字符转义。把文本改成逗号分隔,修改配置文件后重新开始。

[gbase@RHELDN1 ~]$ ./dispcli t.tpl

Start mission [test_t] in dispatch mode…

[172.16.130.223] [START TIME: 2012-09-26 14:52:34] [N/A] [RATE: 1.83M/s] [LOADING] [BAD REC: 0] [ETA: N/A] [ELAPSED: 45 secs]

[172.16.130.227] [START TIME: 2012-09-26 14:52:34] [N/A] [RATE: 4.13M/s] [LOADING] [BAD REC: 0] [ETA: N/A] [ELAPSED: 45 secs]

[172.16.130.231] [START TIME: 2012-09-26 14:52:34] [N/A] [RATE: 2.34M/s] [LOADING] [BAD REC: 0] [ETA: N/A] [ELAPSED: 45 secs]

[gbase@RHELDN1 ~]$ ./dispcli t.tpl

[2012-09-26 14:53:50] ERROR: Can’t start load while anchor offline. (/home/gbase/dispserver/dispcli/dispcli_app.cpp:341)

开始加载以后我发现拷过来的数据文件不完整,ctrl+c中断,而后继续执行,然后发现运行不了了,出错的错误完全看不懂。。。。日志不光是给开发人员看的,一个运维友好的日志会同时写出问题可能的原因和简要处理方法。尝试重启dispatch server ,还是不行。用gcadmin看看服务器状态,有点晕,怎么宕机了一台

我在node1上按了下ctrl+c把node3的服务搞挂了?去223上面找日志看看。没找到原因,corosync的进程没了,日志里面没有任何记录。不琢磨了,先手工重启223上面的服务吧。重启后正常了。

 2.6G的文件,5分多加载完毕。大约8MB/s。应该说还是没达到预期,文件是存储在227上面,本地节点加载速度不受网络限制,2个外部节点网络占用也才2MB多。但是这个性能不好比较,一个是我们测试机器不太好,网络也是百兆的网络。我用oracle单机sqlldr加载耗时 6m15.485s。也是通过百兆网络加载。

加载完以后到各台服务器/opt/gnode/userdata/gbase/pocdb/sys_tablespace/hive_test_n[1-3]的目录下看。

每台机上大约780MB的数据,3台机加起来就有2.3G,相对与我2.6G的文件大小,压缩比不算高,oracle未压缩的表存储用了2.4G,两者相差不大,几乎相当于没压缩??

再用greenplum试试,greenplum只有两个节点,对比下有点不太公平。greenplum也使用列式存储并开启压缩。

 gpfdist -d /home/gpadmin -p 8081 >> gpfdist.log 2>&1 &

CREATE EXTERNAL TABLE ext_hive_test ( id int, name varchar ) LOCATION (‘gpfdist://172.16.130.226:8081/*.txt’) FORMAT ‘TEXT’ (DELIMITER ‘,’) ;

CREATE TABLE hive_test (id int, name varchar )with (appendonly=true,orientation=row,compresstype=quicklz,COMPRESSLEVEL=1) DISTRIBUTED BY (id);

insert into hive_test select * from ext_hive_test;

耗时6分42秒数据加载完成。

做了下简单的测试,hive_test 是124,113,600行的数据,执行dc已经预先计算好(count,sum,avg,isnull,max,min)的操作时非常快。都在零点几秒就能返回结果。这个就不和oracle比了,绝对秒杀oracle。

尝试一下group by的性能

gbase> create table hive_t1 as select id,count(id) cnt from hive_test group by id;

ERROR 1707 (HY000): GCluster DML&DDL proxy error: gcluster DML error: EXECUTE FAILED [127.0.0.1:5258], I/O operation on ./pocdb/metadata/hive_t1.GED/table.des failed with error – No space left on device File name ./pocdb/metadata/hive_t1.GED/table.des

报错了,磁盘空间满,上面写着是127.0.0.1 也就是本机,可是df查看以后本机磁盘空间完全没问题,只好每台机找过去,原来是223那台机满了,错误提示里面写出具体主机名这个应该不难吧??这要是机器多了,真要每台机器找过去??清理完空间,继续。。

gbase> drop table hive_t1; Query OK, 0 rows affected (Elapsed: 00:00:00.26)

gbase> create table hive_t1 as select id,count(id) cnt from hive_test group by id; ERROR 1707 (HY000): GCluster DML&DDL proxy error: gcluster DML error: EXECUTE FAILED [127.0.0.1:5258], NODE(HOST(172.16.130.223:5050), USER(root), DB(pocdb)):[GNODE(172.16.130.223:5050) execute error: Can’t execute the given command because you have active locked tables or an active transaction]

又是错误。。退出gbase客户端,重新登录就又好了。

gbase> create table hive_t1 as select id,count(id) cnt from hive_test group by id;

Query OK, 124113600 rows affected (Elapsed: 00:01:54.84)

奇怪的是我在oracle上执行同样操作只花了57秒??当然我这个只是熟悉操作的例子,有点特例,数据只有两个字段,但是我只用了其中一个字段,按理gbase读取的数据量只有oracle的一半,两台机配置其实是大致相同的。测试的想起来,直接和oracle比有点不公平,gbase上数据是压缩的,而我oracle上没压缩,于是我启用的oracle上的表压缩。发现表只占了1.7G的空间??上文提到了GBASE是占了2.3G,是gbase的压缩没生效??还是3个节点上的780MB其实就是完整数据了?不需要乘以3 。那就可以理解,但是如果单节点上的就是完整副本的话,每个节点上的表的数据文件大小应该是完全一致的,可是实际上并不是。所以我只能理解为gbase的压缩根本就没生效。

将oracle表压缩后,oacle重新执行上文中的group by语句只花了44秒。相对于未压缩前有了13秒的提升,由于瓶颈一般还是在I/O上面。而压缩后数据从2.4G下降到1.7G。oracle的表现很正常。

greenplum 花了6分37秒,这有点让我没想到。当然还是不排除是机器或者配置未经调整的原因,虽然这三个数据库都是默认参数未调整。

对sql的操作的熟悉先简单到这里,具体复杂的案例评测放在下一篇。

GBASE系统介绍中提到safegroup的有个很重要的功能是failover,这也是任何系统必备的功能了。而我目前每个safegroup只有一台机,很明显没办法做这个测试了,上文中也提到,任意一台服务宕机会立刻导致集群不可用。所以打算在新增一台机器,加入到其中一个safegroup中,这样停掉safegroup中的一台机集群应该还是正常服务。

翻手册的时候又郁闷了,只有新增,或者删除整个safegroup,没有往已有的safegroup中新增或者删除节点的命令。删除整个safegroup,再重新创建?手册上又说删除后数据有丢失,重新创建也不一定能找回,那分布表的数据怎么在safegroup删除前转移?手册中无解。。。这个应该是实际运维中的合理需求吧?难道要手工改集群配置文件??这其实是研发项目的普遍问题,考虑问题的时候理想化,对实际运维考虑不足。

鉴于管理员手册中对此无解,我只好尝试删除掉一个safegroup,而后使用两个node进行重建,数据丢失也不管了,反正我只是在测试,大不了重新加载。

因为没机器,只是临时新建一台虚拟机,做HA的测试,测试完后恢复到每个safegroup单节点运行。

gcadmin removesg sg03

gcadmin addsg –nodes 172.16.130.223,172.16.130.226 –names node3,node4

再用gcadmin看看服务一切正常。不错,没有了恼人的错误,是个良好的开始,

gbase> SELECT count(id) FROM pocdb.hive_test;

+———–+

| count(id) |

+———–+

|  82725725 |

+———–+

1 row in set (Elapsed: 00:00:00.10)

糟糕,数据果然少三分之一,这个验证了两个事情,一是数据确实按照id均匀分布在3个safegroup了,二是重建safegroup的方法是不行地。没关系。咱什么场面没见过,哥重新加载。。重新加载的时候莫名报错,看看gcadmin的状态,有问题,223的datastate变成2了,2是什么意思?不知道。文档中说要执行gcadmin sync 命令进行数据同步,为什么不同步了?不知道。反正就按照文档上同步吧。

执行gcadmin sync 172.16.130.223 进行数据同步,好,继续加载。。还是报错,

说到gcadmin sync 这个命令,要多说一句,在sync的有个步骤是将safegroup上的数据文件用scp 复制到另外一台上,这如果文件上百GB以后,还是很耗时间的,再说有必要全量复制么?其中还有个步骤是将集群状态设为readonly,这个可以理解,使用scp的话不这么来数据无法保持一致,这又对集群可用性造成了影响,所以sync这个功能还是设计的不够优秀。作为生产运维管理员,你敢随便sync么?

[root@rhel231 /]# cat ./home/gbase/hive_test_n2.gbl_report

2012-09-26 22:52:12.926 Reading from the input file error: Resource temporarily unavailable

2012-09-26 22:52:12.948 Error: kill by signal.

2012-09-26 22:52:12.968 Loader error exit: Operation cannot be accomplished in current state

2012-09-26 22:52:12.968 rollback done…

这个报错是啥意思?增加了网络超时时间,还是不管用,我drop掉表,重建试试,如果还不行,我只好重建数据库了。结果重建表以后直接Segmentation fault 了。只好使出大招,重建数据库。

gbase> drop database pocdb;

ERROR 1707 (HY000): GCluster DML&DDL proxy error: gcluster database error: Cluster at risk, more than 2 safegroup the node number is equal to 1,EXECUTE FAILED [172.16.130.227:5258], gcluster database error: EXECUTE FAILED [127.0.0.1:5050], Unknown table ‘hive_test_n1’

gbase> show databases;

+——————–+

| Database           |

+——————–+

| information_schema |

| gbase              |

| gctmpdb            |

| pocdb              |

+——————–+

4 rows in set (Elapsed: 00:00:00.00)

gbase> drop database pocdb;

ERROR 1707 (HY000): GCluster DML&DDL proxy error: gcluster database error: Cluster at risk, more than 2 safegroup the node number is equal to 1,EXECUTE FAILED [172.16.130.223:5258], gcluster database error: EXECUTE FAILED [127.0.0.1:5050], Can’t drop database ‘pocdb’; database doesn’t exist

好了。熟悉的错误又来了,也懒得drop database了,直接创建个新的吧。结果新的还是报错,伤不起的测试。。。

注意到日志里面提示

2012-09-26 23:04:17.663 Reading from the input file error: Resource temporarily unavailable

根据经验应该是虚拟机的资源不够所致,我只是测试HA,于是减少了测试数据量,head 一万行出来加载入库。果然就成功了。但是count一下却有九千多万行,应该是之前加载报错的时候没有回滚所致,这个问题在生产上很可能就导致数据重复加载,处理起来就麻烦了。

而后我停掉safegroup3中的一台机223,却登录不上数据库了。

gbase> use pocdb2;

ERROR 1707 (HY000): GCluster DML&DDL proxy error: Can’t connect to GBase server on ‘172.16.130.223’ (115) gbase>

我启动223,关掉226,却又执行sql成功了??是223作为safegroup的主服务器?所以关掉226没关系,但是不能关223?单独启动223的时候执行sql正常,而后启动226,手工做数据同步,再次关掉223,再次出现同上错误,无法连接数据库。但是已经连接上的绘画还是可以执行一些select操作,但是无法进行ddl,

gbase>  create table pocdb2.t3 as select id,count(id) cnt from pocdb2.hive_test group by id;

ERROR 1708 (HY000): gcluster command error: Current operation is denied when the cluster is locked.

gcadmin命令显示集群状态为LOCKED

所以我觉得safegroup的failover还是不够完善,没有起到应有的作用。

本章节告一段落,对数据库的安装配置有了简单认识,下一篇将按照我们日常中实际应用编写测试案列分别在gbase,oracle,greenplum上运行,而后进行TPC-H 以及和datastage的集成测试。

 

 

 

 

 

 

 

国产列式数据库GBASE 8a 集群版评测(1)

这段时间在研究大数据,对列式数据库也有一些了解,老大发了邮件说了一个国产的列式数据库GBASE,号称比oracle快10-20倍。说实话,操作系统,数据库,这样的核心技术我不认为国内有这样的实力能完全国产化自主研发,有也是基于开源技术的重新包装,有了源代码就真能掌握其中原理?而开源技术的闭源实现生命力不会持久,例如国产的linux,国产的ophone,国产office,哪个最后也没有推广开,这方面不崇洋不行。虽说有疑虑,搞技术还是要数据说话,空谈无用。

前两周GBASE销售到公司对GBASE做了交流,先对技术特点作了介绍,并讲解了一些和oracle,Greenplum,Teradata,Sybase IQ的对比测试案例,因为主题大致也和我的目前工作相关,所以老大指定我来负责公司内部的GBASE学习。GBASE看起来听起来都不错。但是做技术的都知道,没有one thing for all的解决方案,所有的解决方案都是只有在特定场景,特定规模下才是最优的。有点很好,更要知道其局限性,才能在后续项目选型中使用。

 

先简单按交流上的内容介绍下GBASE 8a

真正的列存储RDBMS体系架构。 数据加载高效:装载数据速度大于1TB/小时。

可扩展性:单个集群可达到128个节点,PB级的数据库。

压缩优势:轻量级数据压缩,数据不膨胀,启动高级压缩可以达到1:10以上的综合压缩比,压缩状态下查询性能不下降。

并发优势:读写没有互斥,MVCC的支持,边入库边查询,并发用户大于2000。 支持海量数据存储、查询。 数据分布的灵活性:基于策略的数据加载模式。

集群架构优势:偏平架构,无SPOF,无master瓶颈,高扩展性。

集群调度优势:网络带宽需求小。

并行优势:充分利用现代多核CPU资源。

易用性:不用特殊索引,调优,物化视图等。

可靠性:支持全量,增量备份/恢复。

易于维护:支持集群在线扩展。

高可用:支持数据冗余,自动故障探测和管理,自动fail over,自动同步。

高效率:智能索引对统计分析的高效率。

安全,监控能力:支持用户权限管理,提供图形化管理诊断工具。

  1. GBASE是一个列式数据库,列式数据库的优缺点我就不在说了

列式数据库的压缩会比较好做,尤其是一些唯一值比较少的,可以通过系统内部生成的代码表进行对照替换,尽管原来列中可能是一些较长的字符,通过自动代码对照,可以变成类似0,1这样的简单存储.

但是列式数据库有个普遍的问题是,只有在读取,或者更新的列数和总列数占比较低的时候才有性能优势,如果操作的列数接近于总列数,性能很可能会低于行式数据库,在后面的提问时间我也有问道这个问题,gbase这个性能的拐点大约在总列数的70%左右。就会下降到大约与oracle一致。而目前的ETL工具基本根据主键全字段更新,这个就严重影响性能。这个我下篇会做个具体的评测。

2.另外一个比较有特色的地方就是所谓的智能索引

这个图有点不太好理解,实质就是存储的时候数据每64k形成一个data cell(dc) ,这个有点像oracle的data block,然后对这个dc的常见的一些统计信息例如(max,min,count,sum,avg,null)等在加载的时候就计算好,存储下来。有了这个重要的数据,在一些简单的max,min,count,sum,avg,null操作的时候就只需要读取实现计算好的索引数据,同时还有一个很重要的作用是在读取数据的时候根据每个dc的max和min值筛选dc,可以大大减少全表扫描的IO

 

这个只能索引的ideal不错,但是后来我查资料的时候看到mysql infobright的这几张图,仔细看着是不是很眼熟??只不过这边是data pack。Gbase其实是基于mysql的,这个下篇也会具体提到。

3.集群版设计

GBASE有所谓的safegroup ,每个safegroup内至少有2台机,不能多于3台,这样就实现的所谓数据多副本存储,听着有点像那个hadoop里面的3副本存储策略。细看了这个以后其实和hadoop的多副本存储策略完全不是一回事,首先safegroup内是主备关系,只有一个节点能对外服务,浪费了机器资源,而hadoop的3个数据副本都可以直接对外提供服务。hadoop在遇到故障的时候,会自动新增副本,以将副本数保持在3份。safegroup在遇到故障的就只能靠那最多3个节点的命运了,自求多福了。

文中提到的在线扩容倒是问题不大,在线缩容这个我有点疑问,文档中说safegroup在删除的时候上面的数据全部被删除,如果是复制表问题还不大,分布式的表就有点悲催了吧,原来存在上面的数据怎么办?这个在后续的具体评测中会测试这一点。

文中的网络用的是infiniband,当时有些疑问,infiniband相对高端,而我们一般测试环境,或者生产环境也就是千兆以太网,后来问下infiniband也不是必须的,我个人觉得ppt上使用infiniband宣传的意义更大于实用。

第一部分到此结束,第二部分将介绍安装配置及使用部分,第三部分则是具体性能评测。

软件又何妨拿来主义

今日听闻里云ODS与谷歌之争,还有核高基成了分账大会,大家争相申报课题来骗取国家巨额支持。操作系统,数据库,中间件都要有国内自主知识产权的产品。幸运的是,这三项都有对应成熟的开源成品,这也很快让我们有了所谓的自主研发产品。一个不变的定律是,一个开源版本的闭源分支最后一定会丧失活力,被淘汰,公司在强,也抵不过协作的力量。

要真想掌握相关的核心技术,还不如把人投入开源软件的自主研发和维护,不然想办法成为其的contributor,committer,mananger。从而引领开源界的发展,看你有没有实力,只要看程序发布清单中的贡献者大多是谁,那才是真正能服人的掌握核心科技。

有个说法说,国外一开源,我们就自主研发了,可悲的是我们一边宣传要有自己知识产权,却对知识产权好不重视,只看到开源软件的协议的破坏,抄袭。利用了开源软件,甚至最后都不承认,更别提对开源社区的回报了。协作是未来的主流,开源使得人们可以把精力集中在创造性的事情上,而不是大家各自重复做着同样的事情上。对于国内的软件交付企业来讲,自己辛苦投入研发的成果,开源出去,让别人吃白食,似乎没有这个道理。这点上Google也类似,google的很多论文影响了世界,但是请注意,他们的论文都是延时两三年发布的,等别人看到,将论文落地,已经落后google 四五年了。

软件不再是想过去那样埋头苦干了,当今的世界要求我们更能利用别人的成果,做事情之前先看看别人是否已经做过了,我们没有我们想象的那么独特,我们想到的,很可能别人早已经想到了,做到了,甚至比我们预想的更好。站在巨人的肩膀上开发吧,那样我们才能做的更好。

国产软件为什么这么难

今天上午GBASE的销售过来交流,主讲其列式数据库。 其中存储,压缩,索引上不少理念都有可取之处的,但是因为挂了个国产软件的名号,商业推广很是困难,大家普遍对国内厂商的技术实力表示质疑,也许真要在国外注册个公司,搞出口转内销才行。

国产软件普遍给人映像不好,认为技术实力弱,国内软件业的竞争环境相对比较恶劣,一个是计算机是国外发明,大家普遍有崇洋的心理,认为国外的东西总是先进,可靠的。另一个国内的软件这些年确实比较浮躁,耐心做研发的不多,普遍是买噱头,真真落到实处太少。