国产列式数据库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 集群版评测(2)”的一个回复

  1. 😯 我看的有点目瞪口呆了,gbase是在mysql的代码基础上改的?还是说是继承了mysql的部分代码?比如那个客户端的交互界面和mysql如此相像。虽然看到gbase的测试还有诸多问题,不过oracle刚出来的时候,用户体验也不理想啊。博主对gbase的整天看法是什么?求分享!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据